Automated code reviews
Contents
Automated code reviews 1
Introduction 1
Description 1
Conclusion 1
Introduction: Software is written incrementally in the form of well tested features. This typically involves additional code and tests. Before the code makes its way through the pipeline to the release for use by customers, it has a chance to be vetted in many stages. This writeup tries to articulate the benefits of adding an automated code review as a criteria for such validations.
Description: When the software is compiled, tested, peer reviewed and checked into the pipeline, it has already gone through some form of static validations as well as automated and manual reviews. After it enters the pipeline, there are several tests that run against it. These tests include both unit-tests and content–tests. This works well for new software but legacy software is often large and complex. Many software products claim millions of lines of code that require feverish rituals for mere compilation. Moreover covering all surface area with adequate tests has traditionally fallen short regardless of high infusion of engineering resources. The problem perhaps lies in the cost-benefit ratio of the percentage of time dedicated for new development versus clearing technical debt. Therefore, it can be safely assumed that legacy software often cannot meet the stringent combing done for newer software. Even compile time checks are loosened for legacy software in favor of acceptance criteria. Moreover, newer software are written in managed languages which are far more easier to validate and make consistent as opposed to earlier invented but still very much widely accepted languages.
In this context, additional processes are tolerated for the build and release of legacy software as long as they are advisory in nature but not triggering a failure or interruption. Compile and static code analysis tools have come in very handy for provide the earliest feedback in terms of the discovery of defects in a code. Along with annotations to the parameters and methods, these code analysis tools can help detect a wide variety of defects such as buffer overruns, unguarded access, initialization mistakes and such others. Annotations work slightly differently from instrumentation of the code where the latter usually does not make it to the release while the former remains available in release and as informational only. Furthermore, the takeaway here is that annotation comes directly from the developers in their attempt to use the tool to improve their own code health. On the other hand analysis of interactions between components is hardly known until at least runtime. The code reviews help here in that peers can flag potential overlooks as they shed light from multiple perspectives. However the code is not the only source of information for the highest source of defects. Such kind of information comes from stack traces that are usually hashed or they come from defect databases where the stack trace may be one of the attributes. Consequently, the defects database and specifically known stack-traces could provide an alternate source of information that could translate to checks during build time. These additional checks may be package specific or branch specific and therefore become a form of automated code reviews.
Conclusion: Software code reviews could lean on information gained from history and defect tracking databases whenever available. In short, the static code vetting need not be standalone any more.
Contents
Automated code reviews 1
Introduction 1
Description 1
Conclusion 1
Introduction: Software is written incrementally in the form of well tested features. This typically involves additional code and tests. Before the code makes its way through the pipeline to the release for use by customers, it has a chance to be vetted in many stages. This writeup tries to articulate the benefits of adding an automated code review as a criteria for such validations.
Description: When the software is compiled, tested, peer reviewed and checked into the pipeline, it has already gone through some form of static validations as well as automated and manual reviews. After it enters the pipeline, there are several tests that run against it. These tests include both unit-tests and content–tests. This works well for new software but legacy software is often large and complex. Many software products claim millions of lines of code that require feverish rituals for mere compilation. Moreover covering all surface area with adequate tests has traditionally fallen short regardless of high infusion of engineering resources. The problem perhaps lies in the cost-benefit ratio of the percentage of time dedicated for new development versus clearing technical debt. Therefore, it can be safely assumed that legacy software often cannot meet the stringent combing done for newer software. Even compile time checks are loosened for legacy software in favor of acceptance criteria. Moreover, newer software are written in managed languages which are far more easier to validate and make consistent as opposed to earlier invented but still very much widely accepted languages.
In this context, additional processes are tolerated for the build and release of legacy software as long as they are advisory in nature but not triggering a failure or interruption. Compile and static code analysis tools have come in very handy for provide the earliest feedback in terms of the discovery of defects in a code. Along with annotations to the parameters and methods, these code analysis tools can help detect a wide variety of defects such as buffer overruns, unguarded access, initialization mistakes and such others. Annotations work slightly differently from instrumentation of the code where the latter usually does not make it to the release while the former remains available in release and as informational only. Furthermore, the takeaway here is that annotation comes directly from the developers in their attempt to use the tool to improve their own code health. On the other hand analysis of interactions between components is hardly known until at least runtime. The code reviews help here in that peers can flag potential overlooks as they shed light from multiple perspectives. However the code is not the only source of information for the highest source of defects. Such kind of information comes from stack traces that are usually hashed or they come from defect databases where the stack trace may be one of the attributes. Consequently, the defects database and specifically known stack-traces could provide an alternate source of information that could translate to checks during build time. These additional checks may be package specific or branch specific and therefore become a form of automated code reviews.
Conclusion: Software code reviews could lean on information gained from history and defect tracking databases whenever available. In short, the static code vetting need not be standalone any more.
No comments:
Post a Comment