By Sébastien Julliand
Summary
It won’t come as any surprise to you if I say that code review matters. Anyone in our industry knows that peer review goes a long way to ensuring quality, for many diverse reasons (not least the very human reaction of not wanting to disappoint your peers!). Good quality code is easy to maintain, so there is a considerable financial impact too. Looking out for the complexity and the readability of source code right at the point it is written is an investment that pays off on the long term. Continuous code review keeps your “technical debt” burden in check…
So why is something as elementary as code review so effective? As any developer will tell you, code has a “smell“. This notion of “code smell” is very common in standard definitions of code review. Within minutes of perusing a block of source code an experienced developer can instinctively distinguish code that “smells good” from one that is suspicious or risky.
It is the heuristics of this instinctive process that, where possible, are built into automated code review tools in the form of predefined quality rules and rulesets. These rules can catch the most frequent quality defects. Thus keeping code clean becomes much easier (or more “pleasant”, as some enthusiasts would say) and avoids code falling into the most common traps such as spaghetti code or god objects…
1. Captain, take the ship “hard to port”!
The whole point of a code review is to detect problems as early as possible in the development cycle. This is the principle of “shift left” testing: test early. The earlier a bug is detected, the less expensive it will be to fix it. But this principle only partially answers Larry Page’s maxim: “Test early and often”. Automating code review makes this frequent checking possible by applying quality rules directly in the development environment or, at least at regular intervals in batch.
2. Developer brain time available
Code review takes time, and especially valuable developers’ time. By automating everything that can be automated in a code review, we can avoid teams losing time on the more daunting aspects of the task. We also avoid the opportunity cost of draining key resources that could instead be allocated to building “revenue driving” functionality.
The creation of rules and then rapid enforcement of compliance with coding standards (e.g. indentation, naming of objects, fields, methods, …) is performed much better and more reliably by automated tools. The same is true for quality rules that highlight inefficient or even “dead” code. This level of automation leaves developers with more time to focus on the more complex problems that only a manual code review can decipher.
Automation thus increases (or at least does not decrease) developer availability and prevents harmful bottlenecks from emerging the development cycle.
Nevertheless, it goes without saying that a tool, however powerful it may be, will never completely replace the sharp eye and coaching skills of an experienced developer in the most challenging of cases…
3. Nothing is lost, everything is shared
Knowledge sharing is a crucial and often problematic issue within development teams. At best, good technical practices and coding standards will be recorded in a document management tool and at worst they will be… in the collective unconscious! It would be unfair to blame a newcomer for not respecting the standards, if they are only used and understood by the most experienced team members.
Here again, the benefits of automation are measurable. A good source quality checking tool will naturally become the de facto documentary reference as to standards and best practices. As it is applied, the tool will gain in value as it is continually enriched with more and more rules,
This makes code quality checkers an efficient and reliable way of sharing knowledge within a project and ensuring that standards are applied. The most efficient technique – and the one that fits best in a DevOps approach – is to integrate the code quality checker right into the development environment, making the checking and enforcement of quality rules continuous. It also saves the developer the tedious task of flipping back and forth between his editor and some external knowledge source.
4. Meanwhile, on the IBM i
“Old pots make the best soup,” comes to mind when talking about the IBM i platform. Initially sidelined by the DevOps scene, IBM’s historic OS is pushing back strongly, thanks to the mobilization of major tool vendors and the Open Source world. Development on the IBM i platform is dominated by the RPG language, on which IBM has invested heavily over the last twenty years, giving it a new lease of life thanks to its RPG Free and especially RPG Fully Free form variants, which bring it right the fore of modern languages. Taking care of the specifics of RPG in an automatic code review requires specialized tools, and this is precisely what ARCAD CodeChecker, (the source code quality checker from the ARCAD for DevOps range from ARCAD Software) is designed to do. All forms and evolutions of the language are supported by the product, from RPG III to RPG-FullyFree, and even cases of mixed Columnar/Free. As experienced RPG developers are becoming increasingly rare, CodeChecker capitalizes on more than 28 years of experience in this field by providing a hundred or so quality rules applicable not only to RPG, but also to the CL language and very soon to COBOL.
5. What about security?
If there is one subject of utmost importance, especially since the advent of the DevOps movement, it is undoubtedly security within the source code. We are talking here about DevSecOps. In principle, DevSecOps requires that security of an application be a design consideration right from the very beginning – security by design. To take an example, by applying quality control rules based on the OWASP community recommendations, serious security flaws can be avoided, such as SQL injection risks, buffer overflow risks, etc.
Legacy systems are not entirely without their own security issues either. For example, in the case of the IBM i platform where application modernization techniques are common, traditional legacy programs are now routinely exposed as Web services. This creates a new risk that was hitherto unheard of in IBM i applications. It is therefore critical to detect security flaws in RPG code as early as possible. This security area is thoroughly covered by ARCAD CodeChecker, which as part of its DevSecOps ruleset, will detect and report on risks of SQL injection in RPG.
6. The final word
In conclusion, the legacy or “heritage” systems such as IBM i have an equal, or arguably even greater need for code review than their distributed counterparts. The growing scarcity of coding skills in languages like RPG has only increased the importance of automated code checking, as new generations of developers step up to maintain these core mission critical applications with little prior knowledge of the rather specific languages that comprise them.
Their specific technology has meant that legacy systems have in the past been left somewhat aside in the enterprise CI/CD chain, deploying at a different frequency and using a very different set of tools. However the situation is changing fast, thanks to a number of modern tools that have been integrated into the platform by default. Key examples include Git, which has already taken a firm foothold on IBM i and z/OS, and Ansible, just starting to make headway in the legacy world.
The automated code quality checkers are also gaining ground. Take for example SonarQube, which offers partial support for the RPG language. As mentioned above, if it is full support of all RPG variants that you need, then ARCAD CodeChecker alone delivers the exhaustive IBM i coverage required to future-proof your application, whatever the mix of languages it may contain.
Source code quality checking is now a mainstream function that fits naturally within the continuous integration (CI) phase of the DevOps cycle. With the ARCAD for DevOps range of solutions, and ARCAD CodeChecker in particular, you can automate a continuous quality process on IBM i to “shift defects left” and eliminate any risk of security vulnerabilities as you modernize.
Sébastien Julliand
Product Line Manager
Sébastien Julliand is a product manager at ARCAD Software and has been working on bringing the IBM i and open systems worlds together for more than ten years. Driven by his enthusiasm for technical challenges and a strong development expertise in many languages, from RPGLE to Java, Julliand joined ARCAD’s research and development as a functional and technical advisor, becoming a specialist on a wide range of products. Julliand is also involved in the development of several ARCAD products, particularly those focused on DevOps, and is specifically the product manager for ARCAD CodeChecker, a source code quality checker for IBM i for which Julliand brings his experience as a day-to-day developer.
REQUEST A DEMO
Let’s talk about your project!
Speak with an expert