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

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

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

1

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

3Common PitfallsBad 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.

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

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

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

6

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

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

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.

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

TTimely 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

FAIL

PASSREFACTOR

Write failing test

Write code that make the test green

Eliminate code duplication and unused code

12

Repeat

1

23

TDD Life cycle

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

Would you use a bridge built by an architect who has never studied Building Construction Techniques?

Pattern or anti-pattern

14

15Common problems of bad designRigidity1

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.

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)

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

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

LIGHT SABER OR BASTARD SWORD

A good craftsman has good tools

19

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.

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