4 ms·
One measure for code quality should be the effort to make a minor change to code, or to fix a simple, common bug. Can a developer who is familiar with the code
by UweSchmidt 4y ago
One measure for code quality should be the effort to make a minor change to code, or to fix a simple, common bug.
Can a developer who is familiar with the code, effortless make a change in an area where change was expected at the beginning?
Assuming a typical, minor bug that turns out to originate from the usual suspect places in the code (database query, logical error, incomplete implementation of a requirement, off-by-one/calculation error). Is it usually easy to narrow things down, and to spot the error?
That means the lead architect should regularly try implementing minor features or fix minor bugs and/or pair up with colleagues who do, and draw conclusions about the code accordingly.
- hu3 4y agoThat's a good one. Another measure I use for code quality is: how afraid am I of breaking something when I make changes? This is where typing and tests shine.
- wtetzner 4y agoTyping and tests definitely help, but nothing works better than having well-factored, decoupled code, so a change in one place doesn’t impact the rest of the code base in unexpected ways. Unfortunately I don’t know of a good way to do that outside of experience + vigilance.
- baby 4y agoGood abstractions + asserts + minimal assumptions everywhere in the code (also called refactoring-resistant code)
- deleted 4y ago[deleted]
- bcrosby95 4y agoUnexpected is an interesting word. This probably means consistency is important, because expected in one codebase could be unexpected in another.