Code Quality Process

Establish a process to ensure code quality. Implement static code analysis and peer review processes to have a code that does what it should, follow a consistent style, is easy to understand, has been well-documented, and can be tested.

Why

A quality code makes software reliable, extendable, and maintainable. It reduces the frustrating bugs and design problems and manages risks of data loss, security incidents, and scaling problems. It’s much harder to read and understand a bad quality code than to write it, whereas quality code is easier, safer, and less time consuming to maintain. Good quality code can speed up long-term software development since it can be reused, and developers don’t have to spend much time fixing old bugs and polishing code. It also makes it easier for new project members who join the project.

How

  • Awareness

    • Software architectural patterns and design patterns.
    • Well defined coding standards in general and specific to programming languages.
    • Security guidelines which should be followed.
    • In-depth knowledge about the domain, system, and used programming languages.
  • Implement Controls

    • Come up with an approach to address the problem and plan it well before code writing is started.
    • Design the approach considering software architectural patterns and design patterns.
    • Write unit tests for codes you are going to write.
    • Follow well-defined coding standards both general and language-specific.
    • Document all necessary details to refer to later.
    • Add necessary comments on code to log why you’re doing something that’s not straight forward
    • Do proper developer testing and peer reviews.
    • Check whether security guidelines are followed.
    • Refactor the code well so that you can’t think of any other improvement.
    • Get your code reviewed before it's merged to the main branch and do necessary updates.
  • Monitoring and Reporting

    • Ensure the code behaves as expected in the live environment.
    • Unit test and code coverage results.
    • Reports for scans through analysis tools.
    • Monitor once the code is in a staging environment that’s similar to production.
    • Continuously monitor the production environment once the code is live.
    • Log root causes for the bugs observed.
  • Process to Control

    • Ensure findings from analysis tools are addressed correctly.
    • Make adaptations for the findings in the staging environment, as necessary.
    • Continuous KT sessions to ensure everyone within the team has the necessary knowledge.
    • Discuss the root causes and find ways to avoid them.

References