Here is my second installment of raw notes on code quality as part of my larger project on code quality as outlined in my Code Quality — Preamble.
As before, I am unable to post my hierarchical list of bullet points directly in Medium since Medium does not support hierarchical bullet points, so instead I offer a link to the Google Doc containing my notes:
Feel free to comment here or directly on the document.
I may indeed post additional notes, but at this stage I do think that I have covered virtually all bases fairly well.
I don’t have a separate set of notes to post on software and product quality as distinct from code quality at this point. Most of my latest notes are fairly close to quality of source code itself.
My next step will be to step back and take stock of where I think I am overall for this project. I may take a breather before continuing, abandon the project (I mean, who really cares about this stuff?!), or, more likely, publish an intermediate document on what I think I’ve learned from the project so far.
As a teaser, I present here a handful of the top-level points from this latest batch of notes:
- Drivers of poor code quality
- Drivers of code complexity
- What can developers do to improve code quality?
- How can developers get stronger support from management to improve code quality?
- How can managers tell if they have a code quality problem?
- How can managers persuade developers to improve code quality?
- How to measure code quality?
- Checklists for code quality
- How to boost code quality
- Academic research
- Why doesn’t quality assurance (QA) apply to source code?
- Code quality is also a reference to the efficiency of machine code generated by a compiler
- Culture needed for effective code reviews
- Purpose and intent
So, please let me know — what am I still missing?