Codebase evaluation checklist
Codebase checklist
Highly opinionated checklist, but each of these items will make it faster (for me) to onboard and contribute to a codebase.
- Project self-containment
- Backing services are defined in the project and under version control
- External dependencies are limited to a runtime and task runner
- Test presence and separation
- Unit tests can be run without any further setup or configuration tasks
- Clear separation of unit and types of non-unit tests
- Test runner is idiomatic
- Tests can be executed using project task runner
- Test results are reported in human and machine readable forms (e.g. HTML and XML)
- Test coverage results are reported in human and machine readable forms (e.g. HTML and XML)
- Build system is idiomatic
- One single command runs the build and generates an artefact
- Minimal set of global dependencies required to run the build
- Coding style
- Coding style is specified local to the project
- Coding style can be verified using the project task runner
- Coding style can be applied using the project task runner
- Coding style has integration with relevant IDEs
- Coding style can be overridden using inline directives
- Project is set up to allow static analysis of the codebase via the task runner
- Logging
- Log events are emitted are different levels (TRACE, DEBUG, INFO, WARN, ERROR)
- Logs are structured (e.g. can be serialised to JSON)
- Logs are contextual (e.g. contain a correlation ID)
- Logs are emitted as streams (STDOUT, STDERR)
- Logging facility can be set or changed at runtime
- Documentation in repository
- Documentation is written in an appropriate textual format (e.g. Markdown, AsciiDoc)
- Installation, setup instructions are present (e.g. INSTALL)
- Project overview and description are present (e.g. README)
- Quickstart instructions available (e.g. list of 5 steps to get up and all tests running)
- Architecture or design documentation is present
- Historical decisions are present (e.g. ADR, Architecture Decision Records)
- Operational documentation present (supportability, fault mode descriptions)
- Developer support documentation present (e.g. specific instructions for re-creating production scenarios)
- Dependency management
- Dependencies declared
- Declaration has explicit dependency versions using SEMVER
- Declaration has dependency version integrity markers (e.g. checksum, signature)
- Separation between app and non-app (e.g. dev, tool) dependencies
- Conflict free use and upgrading of app and non-app dependencies
Next time, we'll talk about "10 Reasons why gcc SHOULD be re-written in JavaScript - You won't believe #8!"