Developer Job in Practice

Developer Job in Practice
Clean code rules • Code review • Refactoring
Kamil Kowalski
kamil.kowalski@blstream.com

2

Being a developer
!  You
need
to
follow
the
rules,
wheter

they
are

!  You should ask the questions –
especially in case of doubts
!  You should learn new things: all
the time, always and also from
others
!  ... till end (of time)
Developer’s job is not only about
developing the code
!  It
would
be
great
to
have
a
leader:

!  to
learn
from

!  to
follow

!  You
are
the
team
player

!  You
work
with
legacy
systems

3

Typical project setup
!  Waterfall,
Agile,
...

!  How project is run:
!  Scrum
!  Kanban
!  Programin Mother*ker
!  Developing the code
!  Code first
!  TDD
!  „Who needs unit tests” / „We don’t
test our code” ☺
There is no one!
Each single project has its own setup!
!  Tools:

!  IDE
–
Xcode,
VS,
IntelliJ,
...

!  Repository:
SVN,
Git,
...

!  CI
environment:
Hudson,

Jenkins,

CC.NET,...

!  Scripts:
Python,
MsBuild,
ANT,

NANT,
...

!  SupporQng
tools:
R#,
StyleCop

!  Review
Tool

!  Project
board,
back
trucking:
JIRA

!  Code
guide

!  DeﬁniQon
of
Done
/
DeﬁniQon
of

Ready

!  Build
in
one
step
&
daily
builds

4

Definition of Done / Definition of Ready
!  DoD / DoR says about the rules
you need to follow during daily
work
!  Each developer in team need to
follow DoD – no exceptions!
!  Each team member need to
follow DoR – no exceptions!
!  Each single project has its own
DoD / DoR
DoD / DoR is our contract! !  Sample DoD:
!  All unit tests passed
!  All integration tests passed
!  No warnings in code (also warnings
from StyleCop)
!  Code coverage over 91%
!  Max cyclomatic complexity below 12
!  Build passed on CI server
!  Sample DoR:
!  Functionality working (all AC’s met)
!  Unit test written
!  Code approved by 2 other developers
!  QA accepted
!  Functionality available on CI staging
environment
!  Documentation updated

5

Code smells
!  Duplicated Code
!  Long Method
!  Large Class
!  Long Parameter List / too many
of them
!  Switch Statement
!  Temporary Field
!  Magic numbers
!  Naming
!  Complex Conditionals
!  Dead code
If it stinks, change it! !  High quality code is:
!  Easy
to
read
and
understand

!  Impossible
to
hide
bugs

!  Easy
to
extend

!  Easy
to
change

!  Has
unit
tests

!  Always code as if the guy who
ends up maintaining your code
will be a violent psychopath who
knows where you live.

public
class
Record_Base

{

public
DateTime
RecordDateTime

{

get
{
return
_recordDateTime;
}

set

{

if
(this.GetType().Name
==
"Record_PartRegister")

_recordDateTime
=
value;

else

throw
new
ExcepQon("Cannot
call
set
on
RecordDateTime
for
table
"
+
this.GetType().Name);

}

}

}

hp://thedailyw].com/ArQcles/Making-‐Oﬀ-‐With-‐Your-‐Inheritance.aspx

This is not OOP!

KISS my DRY and SOLID code
7

Simple rules for
developers – how to
write the code
!  Keep It Simple -
Stupid
!  Don’t Repeat
Yorself
!  Uncle Bob Clean
Code(r)
!  SOLID
principles:

!  Single
Responsibility

Every
object
should
have
a
single
responsibility,
and
that

responsibility
should
be
en7rely
encapsulated
by
the
class.

!  Open
/
Closed
principle

So:ware
en77es
(classes,
modules,
func7ons,
etc.)
should
be
open

for
extension,
but
closed
for
modiﬁca7on.

!  Liskov
SubsQtuQon

Objects
in
a
program
should
be
replaceable
with
instances
of
their

subtypes
without
altering
the
correctness
of
that
program.

!  Interface
SegragaQon

Clients
should
not
be
forced
to
depend
on
methods
they
do
not
use.

!  Dependency
Inversion

Abstrac7ons
should
not
depend
on
details.

Details
should
depend
on

abstrac7ons.

8

Code reviews
!  Can
catch
up
to
60%
of
defects

!  EffecQve
code
reviews
are:

!  Short
–
don’t
waste
Qme

!  ConstrucQve

!  Avoid
emoQonally
draining
arguments

!  Code
review
rules
depend
on
project

you’re
working
on
-‐
samples:

!  Banking
system

-‐
SOLID,
security

!  NASA

!  Games
-‐
opQmizaQon
,
code
efficiency,
don’t

care
about
excepQons

!  Mobile
applicaQon
–
SOLID,
but
efficiency

Everybody reviews and everybody is
reviewed.
!  Rules:

!  Syntax
!

!  Code
Style
–
be
project
StyleCop

(naming)

!  Simplicity

!  DRY
violaQons

!  SOLID
violaQons

!  Security
–
buffers,
stack
overflow,
input

dfata
sanity
(trust
no
one),
cross

boarders
(SQL
injecQon,
XSS)

!  Memory
leaks

!  OpQmizaQon
-‐
code
efficiency

!  Strings
!

9

Why should I refactor?
!  Technical
what?!
-‐
is
a
metaphor:

!  doing
things
the
quick
and
dirty
way
sets
us
up

with
a
technical
debt,
which
is
similar
to
a

ﬁnancial
debt

!  incurs
interest
payments,
which
come
in
the

form
of
the
extra
eﬀort
that
we
have
to
do
in

future
development.

!  Refactoring
is
changing
the
structure,
but
not

the
funcQonality
of
your
applicaQon.

Refactoring is our way of paying off
our “Technical Debt”
!  How
Should
I
Refactor:

!  Ask
yourself
the
following
quesQons:

!  Is
my
code
readable?

!  Is
my
code
abstract?

!  Anything
more
is
rearranging
the
deck

chairs
on
the
Titanic:

!  It
gives
you
a
sense
of
doing
something

!  But
ulQmately
it’s
pointless

#

!  Follow
the
rules:

!  KISS
/
DRY
/
SOLID

!  Clean
code

!  Code
review
rules!

•  Refactoring
catalogs:

hp://www.refactoring.com/catalog/index.html

•  Refactoring
(book)

hp://www.amazon.co.uk/Refactoring-‐Improving-‐Design-‐
ExisQng-‐Technology/dp/0201485672/ref=sr_1_1?
ie=UTF8&s=books&qid=1246371771&sr=8-‐1

Resources

Developer Job in Practice

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à Developer Job in Practice

Similaire à Developer Job in Practice (20)

Plus de intive

Plus de intive (20)

Dernier

Dernier (20)

Developer Job in Practice