YAGNI Principle and Clean Code
1 like767 views
The document discusses the principle of YAGNI (You Aren't Gonna Need It) in software development, emphasizing the importance of only implementing features when absolutely necessary to prevent wasted effort and increase productivity. It also highlights the significance of writing clean code, defined by readability and maintainability, and provides guidelines for naming variables, structuring functions and classes, as well as avoiding code duplication and unnecessary comments. Ultimately, adhering to these principles results in better quality software, easier debugging, and reduced maintenance costs.
YAGNI Principle and Clean Code
- 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