The document discusses several important topics for software development including unit testing, clean coding principles, design patterns, and useful development tools. It emphasizes that tests are important for preventing bugs and should be included in all projects. Clean coding principles like DRY, KISS and SRP help produce code that is easier to read, change and maintain. Design patterns provide solutions to common problems and a shared vocabulary for developers. Useful tools include IDEs, version control systems, code analysis tools and text editors which can help programmers work more efficiently if used properly.

1. Unit test
Clean Coding
Design Principles and Design Patterns
Tools
Tests are very important nowadays
and this is why they should be
present in your projects
Language and frameworks change but
clean coding will remains forever
Design principles represent a set of
guidelines that helps us to avoid having a
bad design. Design pattern is a well known
solution to a common problem.
Good tools can make you a better
programmer and help you to accomplish your
work in less time but you need to know how
use them.
Best practice agenda

2. With a positive attitude for any circumstances, I thrive on challenges in
both my professional and social life. I like to keep up to date in my field and
to maintain a good knowledge of other fields. I found that my passion for
programming extends to studying it in my spare time. I work very well in a
team and my main interest is to Create and Design quality software.
EUGENIO ROMANO
ENGINEER @
https://uk.linkedin.com/in/eugenio-romano-a28a4948
https://twitter.com/RomanoEugenio

3. Clean Coding Language and frameworks change but clean
coding will remains forever.
1

4. TIDY CODERS
OR MONKEY CODERS
Programmers communicate with other people through their code
so it's not enough to just instruct a machine to do something that
you need.
2

5. 3Common Pitfalls
Bad Comments (Good code is its own best documentation)1
Long Method/Class , not a single responsibility2
Code duplication3
Unused code4
Meaningless names5
Bad Formatting6
Magic Numbers7
When you add a comment ask yourself: how can I improve the code so that this comment isn’t needed?
Delete code that isn't being used. We have source control systems for unused code.
Don't Repeat Yourself. When you duplicate software, you often duplicate bugs.
Long Method/Class are difficult to maintain, read and debug. This kind of Method/Class often
contain too many responsibilities.
Names have to reveal intent. Choosing good names takes time but saves more time than it takes.
The team should agree to a single set of formatting and use an automated tool that can apply those
formatting rules for you. Code formatting is about communication.
Remember to communicate the intent of your code. Replace the magic numbers with Named Constants.

6. 2 Easy for other to read
3 Less time spent to read / more time spent to write
4 Less time spent to integrate a new programmer into the team
5 Broken window principle
Why should you do clean coding
1 Easy for others to change
4?
The only valid measurement
of code quality:
WTFs per minute
(Robert C Martin)
If you want your code to be easy to write, make it easy to read.
You are helping co-workers. You are reducing the cost of integrating a new
programmer into the application you are writing.
A badly designed piece of code is all it takes to start the decline. If you find yourself
working on a project with quite a few broken windows, it’s all too easy to slip into
the mindset of “All the rest of this code is crap, I’ll just follow suit.”
If you write clean code, you will spend less time on reading and debugging the
code to improve functionality or fix bugs.
When a piece of code is well written, it is really easy to find the right place
to add a new functionality.

7. You Can't Write Perfect Software, anyway Clean coding is something that
once learnt, will not let you write something unreadable. Also, if you are
in a rush, your code will be clean and you will be able to improve it in the
future.
So. Be smart. Be clean. Be simple. Ship! And keep a small roll of duct
tape at the ready, and don’t be afraid to use it. (Robert C Martin)
Fundamentalism doesn’t pay the bills 5
We are not here just to write code but we are here to deliver a product :
In every programmer ’s life, there will be a PM that will ask you on Friday to end a functionality
before the end of the week:
Define
Improve Review

8. Unit test
Tests are very important nowadays and this is
why they should be present in your projects
6

9. TEST ARE FOR GOOD PROGRAMMERS
NOT FOR BAD PROGRAMMERS
Anything that can't be measured doesn't exist.
Software features that can't be demonstrated by
automated tests simply don't exist (Kent Beck)
7

10. Unit test myths 8
Developing without Tests is fast1
It should not be written by developers2
Writing Tests is for dumb programmers3
It is difficult to add a Test to a project4
Bugs are present as well5
Why do Tests if I already have enough things to do?6
Once you have gotten used to testing, you will notice a reduction in the time spent
Debugging. You no longer spend an hour looking for a bug, you find it in minutes.
Developer write unit test is part of the codebase! Specially if you are using TDD, there is no
way to make a tester write a unit test for you. Tester have to write functional test and
automate it.
No
In my experience is very easy many times is just a mater of a couple of hours.
Test will make your life easy then never. You will never spend anymore a week end try to
solve a bug or chasing a release. Test is the name of the way to have more time to spend
on the right thing.
Nothing is perfect, but it is possible to try to get near is possible only with the test.

11. 2 Quick feedback every step
3 Less time spent for bug fixes and infinite debugging
4 It’s the only way to reach a better design
Why should you test it ?
1 Bug prevention/less regression
6 Unit Tests make you happy
9
People underestimate the time they spend debugging. When your Test fails, you know where the bug is.
With testing, you know straight away when you have added a bug. This lets you fix the bug immediately.
Unit Tests enable me to feel more confident in my code which I write faster and without stress. I can
clean up or upgrade the system and make sure the module still works correctly.
Tests ensure that behaviour is not accidentally changed. With the test we have the courage to refactor.
The definition of the best design is the simplest design that runs all the test cases.(Kent Beck).
The test suite will not allow you to add new functionality that destroy previous tested behavior.
5 Living documentation
Unit testing provides a sort of living documentation of the system.

12. Fast Tests Test should run quickly. When tests run slowly, you can’t run them frequently. If you don’t run
them frequently, you won’t find problems early enough to fix them easily.
Keep in mind F.I.R.S.T.
I
R
S
F
T
Timely Unit tests should be written just before the production code that makes them pass. If you write tests
after the production code, then you may find the production code to be hard to test.
Independent Tests should not depend on each other. You should be able to run each test independently.
When tests depend on each other, then the first one to fail causes a cascade of downstream failures, making
diagnosis difficult.
Repeatable Tests should be repeatable in any environment. You should be able to run the tests in production,
QA or your laptop.
Self-Validating Tests should have a Boolean output. Either they pass or fail.
10

13. FAIL
PASS
REFACTOR
Write failing test
Write code that make
the test green
Eliminate code duplication
and unused code
12
Repeat
1
23
TDD Life cycle

14. Design Principles and
Design Patterns
Design principles represent a set of guidelines
that helps us to avoid having a bad design.
Design pattern is a well known solution to a
common problem.
13

15. Would you use a bridge built by an architect who has never studied
Building Construction Techniques?
Pattern or anti-pattern
14

16. 15
Common problems of bad design
Rigidity1
Fragility2
Immobility3
Viscosity4
is the tendency for software to be difficult to change. Every change causes a cascade of
subsequent changes in dependent modules.
is the tendency of the software to break in many places every time it is changed. Often
the breakage occurs in areas that have no conceptual relationship with the area that was
changed.
is the inability to reuse software from other projects or from parts of the same project.
Viscosity of environment is when the development environment is slow and inefficient.
Viscosity of the design is when you find more than one way to make the change , one way
to preserve the design and others that do not. When the design preserving methods are
harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the
wrong thing, but hard to do the right thing.

17. 16
1
2
3
4
Everything is said once and only once.
Good style leads to easily replaceable objects. When concerns are well-separated,
individual sections can be reused and updated independently. Improve or modify one
section of code without having to know the details of other sections.
Complex software systems are difficulty to maintain. Keep the software simple to also
allow normal developers to evolve it.
Unnecessary functionality is not present.
Some principles to keep in mind
5
A class has only one reason to change.
6
Software entities should be open for extension but closed for modification.
DRY (Don't repeat yourself)
SOC (separation of concerns)
KISS (Keep it simple, stupid)
YAGNI (You aren't gonna need it)
SRP (Single responsibility principle)
OCP (Open/closed principle)

18. Why should you study design patterns? 17
The best way to use patterns is to learn them and recognize places in your
software where you can apply them.
Design Patterns give you a shared vocabulary with other developers. Once you’ve got the
vocabulary you can more easily communicate with other developers.
When following the principles described above to create object oriented
architectures, you find that you repeat the same structures over and over again.
These repeating structures of design and architecture are known as design
patterns.
Design Patterns
Design Principles

19. Tools
Good tools can make you a better programmer
and help you to accomplish your work in less time
but you need to know how use them.
18

20. LIGHT SABER
OR BASTARD SWORD
A good craftsman has good tools
19

21. 2 Continuous integration
3 Version control system
4 Static code analysis tools
5 Command Shells
Must have/must know development tools?
1 IDE Integrated development environment
7 Plain Text editor
20
Your IDE is your light saber, without it the everyday work could be more difficult. Learn it as best you can. Spend some
time every day to learn new functionality or shortcuts like a Jedi (or JIDE ).
Helping to make releases painless reduce the risk of having buggy software with the effect of increasing quality and
decreasing developing costs. With CI, a developer’s life improves. There are no more big bang releases but frequent
deliveries which give you rapid feedback that is easy to manage.
GUI environments are normally limited to the capabilities of their designers . Gain familiarity with the shell, and unlock
the real power of your environment. Furthermore, many servers don’t have a GUI so you sometimes don’t have a choice.
Sharing a project without a VCS is practically hell. Good VCS like Git are free and powerful nowadays. Firstly, use it in a
dummy project and learn how to recover the nasty stuff. VCS has big power but you know big power brings big
irresponsibility
In my experience, Static code analysis could be very good at finding code smell and bad practices but they need to be
configured in the right way because otherwise you will only find lots of useless warnings.
I know it sounds old school and VI is not my cup of tea either but this tool is present in every unix distribution and if you
know it, you will always have a last resort to solve your problems.

22. 51oXyW8WQwL._SX387_BO1,204,203,200_.jpg
Bibliography
1. Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
2. The Pragmatic Programmer by Andrew Hunt
3. Extreme Programming Explained: Embrace Change by Kent Beck
4. Coders At Work - Reflections on the Craft of Programming by Peter Seibel
5. Head First Design Patterns by Eric Freeman
6. Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
7. The Pragmatic Programmer by Andy Hunt and Dave Thomas
8. Continuous Delivery by By Jez Humble and David Farley