YAGNI = You Ain’t Gonna Need It Emerged as one of the key principles of Extreme Programming and says that you should do the simplest thing that could Possibly work!

1. YAGNI
You Ain’t Gonna Need It

2. YAGNI
YAGNI = You Ain’t Gonna Need It
Emerged as one of the key principles of Extreme Programming
“Always implement things when you actually need them, never when you just think that
you may need them”
Do the Simplest Thing That Could Possibly Work

4. YAGNI
Reasons why this principle exists:
● Prevents waste of time with unnecessary work
● Improves the developer productivity and product simplicity
● Remember: features are expensive, both to develop and maintain
● Product changes requirements, all the time!

5. YAGNI
“Every line of code we don’t write is dollars we didn’t spend, and time on the calendar
we get back for free.” – Tim Evans-Ariyeh
“The cheapest, fastest, and most reliable components of a computer system are those
that aren’t there.” – Gordon Bell

6. YAGNI
The cost of build: all the effort spent on analyzing, programming, and testing this now
useless feature.
● More code to compile
● More code to maintain
● More chances to cause bugs
● Confuse developers. What’s this code for?

7. YAGNI
The common reason why people build presumptive features is because they think it will
be cheaper to build it now rather than build it later.
Cost of delay: put a full storm risks feature into production and be generating revenue
only months earlier.
cost of carry: the presumptive feature adds some complexity to the software, this
complexity makes it harder to modify and debug that software, thus increasing the cost
of other features.

8. YAGNI
Yagni is only a viable strategy if the code is easy to change, so expending effort on
refactoring isn't a violation of yagni because refactoring makes the code more
malleable.
It actually requires malleable code.

9. Clean Code

10. Clean Code
Code that is easy to understand and easy to change
It is not enough for code to work!
"Any fool can write code that a computer can understand.
Good programmers write code that humans can understand."
- Martin Fowler

11. Robert C. Martin

12. Clean code
“You should name a variable using the same care with which you name a first-born
child.”
“It is not the language that makes programs appear simple. It is the programmer that
make the language appear simple!”
“Of course bad code can be cleaned up. But it’s very expensive.”
“Code, without tests, is not clean. No matter how elegant it is, no matter how readable
and accessible, if it hath not tests, it be unclean”
“If you're good at the debugger it means you spent a lot of time debugging. I don't want
you to be good at the debugger.”
Robert C. Martin

13. Clean code - Meaningful Names
Variables
int count; // elapsed time in days;
int = elapsedTimeInDays;
Classes
Represent "things" - should be nouns, avoid verbs
For example: Customer, WikiPage, Account, and AddressParser
Methods
Do things - should have verb or verb phrase names
For example: convert(), delete(), or save().

14. Clean code - Arguments
A function shouldn’t have more than 3 arguments. Keep it as low as possible.
How to solve it?
When a function seems to need more than two or three arguments, it is likely that some
of those arguments ought to be wrapped into a class of their own.
Reducing the number of arguments by creating objects out of them may seem like
cheating, but it’s not.

15. Clean code - Methods or functions
“The first rule of functions is that they should be small. The second rule of functions is
that they should be smaller than that” - Robert Martin
Do one thing!
● Methods should not have more than an average of 20 code lines
● If needed, extract it to another method with a proper name that does a single thing
It's always better read one method containing 20 lines calling 10 different methods,
than method containing 400 lines unnamed logic and twisted commentary.

16. Clean code - Classes
Rather than count lines, count responsibilities - Single Responsibility Principle
Many small classes is better
Large, multipurpose classes force us to scroll through code that we don’t need to know
about right now.
OCP, Open Close Principle
Classes should be open for extension but closed for modifications
Ideally, we add new functionality by extending the system, not modifying the existing code.

17. Clean code - Classes
Classes should have a small number of instance variables
High cohesion is when you have a class that does a well defined job. Low cohesion is when a class does a lot of
jobs that don't have much in common.
Methods should affect as many variables in the class as possible to achieve “high
cohesion”
When variables aren’t used by many methods, those are probably begging for a new
class
When classes lose cohesion, it’s time to split them up.

18. Clean code - DRY principle
Dont Repeat Yourself (DRY)
Write Every Time (WET)
The biggest benefit of using DRY is maintainability.
● Readability
● Reuse
● Cost
● Testing

19. Clean code - Comments
If you are writing comments to prove your point, you are doing mistake!
Our code should explain everything. Be DRY
Correct naming can prevent comments.
Comments tend to be obsolete
*Legal and copyright comments are a different situation, they are necessary

20. Conclusion
Clean code means benefits: pleasant work, less stress, unit tests, easy debugging
and better quality.
You are reducing the cost of maintenance of the application you are writing.
You are making it easier to estimate the time needed for new features.
You are making it easier to fix bugs.
Essentially you are making the life easier for everyone involved in the project.

21. Thank you!
luanmalaguti@gmail.com
www.linkedin.com/in/luanmalaguti
Luan Malaguti Reffatti
Java Developer