| I've inherited code where I thought sections were well written, but probably not an entire project. "good" is incredibly subjective, and subjectivity is temporal in nature. there
been times when I thought code wasn't"good" at the time of inheritance, but several years later, found appreciation for it. Perhaps not enough to consider it good...but some appreciation. I've tried to let go of classifying code as good or bad, or any other subjective means. Non-exhaustive list of things I'm more concerned with these days: - How long does it take for a new hire to onboard and be productive? - How quickly are we able to respond with bug fixes? - Do we have enough test tooling to have high enough fidelity coverage to say we've implemented something, or that an issue is fixed? - How observable is it in production? - How reproducible are any issues? - How accurate is the documentation? - Is there enough test coverage to be able to reimplement a portion with confidence? You can probably take all of those things and distill it down into a "good/bad", but I think in general it's better to look at specific concerns that are managed over time. I'm less concerned about the current state of the code, and far more concerned with how easily I can change the state of the code without incident. |
This is great, it’s the most concise definition of clean code I can think of: how easily can I change the code in ways that the system as a whole changes only in ways I intended.