my five mantras to write better software
TRANSCRIPT
My five mantras to write better Software
Raúl Ávila
Mantra
• “a sound, word, or phrase that is repeated by someone who is praying or meditating
• “a word or phrase that is repeated often or that expresses someone’s basic beliefs”
(Merrian-Webster)
Two questions
We have to pay maximum attention to our code
Improving the way we write code
1. Pair programming
2. Code reviews
3. Reading books
• Embrace main ideas as mantras
• Apply them consistently
• On a daily basis
1
Broken window theory
• “When a community tolerates minor examples of disorder (…) such as broken windows (…) people are more likely to commit more serious crimes”
Source: http://bit.ly/2ebQEgR
1. “Don’t leave broken windows”
As soon as you see a broken window…fix it!
But we have to deliver!
Two levels
1. Stop the world!
2. Next iteration
Examples
Inconsistent naming conventions
TODO comments
Unclear code formatting style
Commented out code
• Dead code
• Unused imports
• Ignored tests
• Unused dependencies
• Several dependencies to do the same thing
• No README file
• Unclear Git strategy
• Manual steps in deployments
• Unstable CI
Delivery practices
2
2. “Extract till you drop”
Short term memory
Between 5 and 9 items
Extract variables
Extract functions
Benefits• Extracting increases readability
• Indentation is reduced drastically
• Makes responsibilities arise
• Avoids big balls of mud
• Facilitates benchmarking
Not extracting
Extract classes
• When a function is hard to split (i.e. it has many parameters)…maybe it should be a class
• Or maybe two classes!
Extract packages
3
3. “Do one thing, do it well, and do it only”
(Single Responsibility Principle)
What is (or what defines) a responsibility?
It depends…
Functions
1. Its name describes accurately what it does
2. Such name does not have conjunctions (And / Or)
3. It does not have side effects
Classes
• Definition of class: “family of functions with a clear and well defined objective”
• This objective is the responsibility of the class
• Responsibility as a bunch of solutions to an actor
Actors / Roles
• Final user
• External systems
• Accountants / Stakeholders
• Software Architects
Classes and actors
A class must satisfy the needs of one actor, and that actor only
If we do more than one thing
• Lines of code will grow without control
• Share code between different responsibilities
• Heterogeneous collaborators
• Classes are difficult to test
• Our code will be very hard to change
How to do one thing
1. Testing (TDD)
2. Extracting
4
4. “Abstractions in code, details in data”
0 2 20 39
Id Name Address
Parsing a message
Benefits• More robust design, as there are more immutable
parts
• We can code without knowing all the details (defer details)
• Facilitates testing, as we can test the abstraction, not specifics
• Details that are likely to change are not spread out in the code, so it’s faster to find them
Get details out of your code!• Data structures (OK, still code :))
• Properties files / YAML
• Environment variables
• Datastores
• Configuration server
One exception
Tests
5
Failing test
Make it passRefactor
TDD
Failing test
Make it better
Make it work
Make it pretty
5. “Make it work, make it better, make it pretty”
My five mantras
1. Don’t leave broken windows
2. Extract till you drop
3. Do one thing, do it well, and do it only
4. Abstractions in code, details in data
5. Make it work, make it better, make it pretty
