- we can't be agile if our code sucks
- "Code is how we tell our colleagues how we feel about them"
- "I hate you."
- "I love you."
- http://wiki.c2.com/?FirstLawOfProgramming "Lowering quality lengthens development time."
"This code is great because I wrote it..."
Quality code is inversely proportional to time and effort it takes to understand it.
- List out where debt is
- Pay high interest debt down before lower interest
- Avoid just paying the minimum payment
Avoid technical bankruptcy, abandoning the code base.
The bank doesn't want to get you in trouble. They want to get you into real trouble.
Low quality code is not technical debt, it is sabotage.
We should have time for technical debt along with planning, pto, and other non-development activities
"What do you mean we have to build a fence, we have to chase the cattle."
Civilization started when we didn't have to hunt or gather food constantly.
Some companies have innovation weeks where developers can work on any idea they have.
Narrow, focused, does one things well.
Code that has a cyclomatic complexity of 5 when born but today it is 864.
A software system needs to change all the time. Any code that is relevant has to change over time.
SOLID
- Single Responsibility
- Open-Closed principle
Often, code we write is optimized for writing and not for reading.
As yourself "What is the purpose of this code."
Don't work around this purpose and put things in there that can't be articulate.
Tight coupling makes hard to extend and test.
TDD gives you an indicator that you have a bad design. If it is hard to test it is tightly coupled.
Eliminate coupling where possible.
If you hate unit tests because they are brittle that likely means your design sucks.
Isolate the areas in your code with dependencies from those that don't. The ones that don't will become easier to test.
Isolate complex code from dependent code.
Ask yourself, "why does this code exist."
"When I wrote this code, only God and I understood what is was doing. Now God only knows."
Simple design (Beck Design Rules, https://martinfowler.com/bliki/BeckDesignRules.html):
- Passes the tests all the time
- Reveals intention
- No duplication
- Fewest elements
Writing test first makes you think about what you are writing.
15 lines of code that can be replaced with a single line if libraries were understood.
Imperative code is packed with accidental complexity.
It is code like this that prematurely turns programmers into managers.
Good code should read like a story not like a puzzle.
Imperative means you tell what to do and how to do it.
Declarative (including functional code) tells what to do not how to do it.
We all have an urge to write clever code! Dopamine rush.
Large god code makes you feel awesome. I can fix it not because I'm good but because I wrote in the first place.
"Programs should be written for people to read, only incidently for machines to execute."
10% of the time we write ugnly code for performance reasons, 90% of the time we write it to be consistent.
"On Writing Well, The Classic Guide to Writing Nonfiction" - Zinsser
Rules:
- Simplicity - able to enjoy the writing and understand
- Clarity - make things very clear, don't make it convoluted
- Brevity - keep things small
- Humanity - programmers are not antisocial just not social with some people
Don't comment to cover up bad code. Refactor to make it self documenting.
Write expressive self-documenting code.
http://blog.agiledeveloper.com/2006/01/comments-on-comments.html Good code is like a good joke. Writing comments is like explaining a joke.
//this function allows you to pass through void passthrough(){}
Long methods get longer.
42k lines of code in a single method!
https://media.pragprog.com/titles/pad/PAD-pulloutcard.pdf
Hart to test, maintain, understand, change Fragile, Lack cohesion, high coupling Get longer
Length of a method is not the number of lines at all but the length of its intent, the levels of abstraction.
Long detailed descriptions of 'how was your weekend' question.
We communicate abstractions to people not details.
A programmer is one who can name their children quite easily but has a hard time naming variables.
int i1,i2,i3,p1,p2,p3;
The first step in becoming a better programmer...