Let‘s have a discussion about quality.
- How do you measure it?
- How can you compare it?
- How can you achieve it?
- What‘s necessary and what makes sense to achieve it repeatably with different teams?
I will give answers (my answers) to these questions. But I hope to actually have a discussion about it. Perhaps round-table like? Who would be up for that?
2. You start with good intentions on a
green field project.
It never turns out the way you
envisioned it.
External factors, internal factors.
talk more about risks of bad software
Every application is a
future legacy application.
3. Writing good code
is hard
‣ It takes time
‣ It takes experience
‣ It requires domain knowledge
‣ The better your communication
the better your team’s result!
4. You are not your code!
The value of a developer shouldn’t be tied
to the amount or the quality of code.
5. Many different ideas
Sometimes you
only notice it some
years later
If I look back at old code, I usually
learn a lot about myself.
Ward Cunningham’s original
definition of Technical debt:
[...] a cycle where our
understanding grows so that one
day in the future we see a better
way and put it in.
6. I am by far not the first to speak on this subject.
There are many books written and talks given. There
is the "Clean Code" and "Code Craftsmanship"
idea. A big proponent of this is
Single Responsibility
Open-Closed (extension, modification)
Liskov substitution (objects replaced by subtypes,
still correct)
Interface segregation (small, focused interfaces)
dependency inversion (depend on abstractions)
Many different ideas try to help and make it easier
‣Sandi Metz
‣Uncle Bob author of the book
“Clean Code” & SOLID rules
‣Kent Beck
‣Ron Jeffries
‣Ward Cunningham
…and many, many more
7. Duplication of knowledge, not
code!
Other rules perhaps even
more known to Ruby
programmers are the Rules by
Sandi Metz
Simple Code — The
4 rules by Kent
Beck
‣ Pass all tests
‣ Clear, expressive, & consistent
‣ Duplicates no behavior or
configuration
‣ Minimal methods, classes, &
modules
9. You could run with either of
these lists of rules, or you
Simple code makes
software:
‣ easier to understand
‣ simpler to change
‣ more fun to work with
‣ saves money and time in the
long run
‣ reduces risk of software projects
10. You adapt existing rules and see what
works best for you and your team.
This will be heavily influenced by
whoever you happen to work with
If you have your own rules, you could
use tools to help you achieve your
goals and stick to the rules.
Create your own rules
Bound to happen with time.
11. Use tools to help you measure
‣Linters
‣Static Analysis
‣Behavioral Analysis
