It was presented for students of Technical University of Wroclaw on 03/11/2015.

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

2. 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. 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
! DefiniQon
of
Done
/
DefiniQon
of
Ready
! Build
in
one
step
&
daily
builds

4. 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. 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.

6. 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-­‐Off-­‐With-­‐Your-­‐Inheritance.aspx
This is not OOP!

7. 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
modifica7on.
! 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. 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. 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
financial
debt
! incurs
interest
payments,
which
come
in
the
form
of
the
extra
effort
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!

10. • 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