By S\u00e9bastien Julliand<\/h3>\n<\/div><\/div><\/div>Summary<\/h2>\n\n- Captain, take the ship \u201chard to port\u201d!<\/a><\/li>\n
- Developer brain time available<\/a><\/li>\n
- Nothing is lost, everything is shared<\/a><\/li>\n
- Meanwhile, on the IBM i<\/a><\/li>\n
- What about security? <\/a><\/li>\n
- The final word <\/a><\/li>\n<\/ol>\n<\/div><\/div>
It won\u2019t come as any surprise to you if I say that code review matters<\/em>.\u00a0 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.\u00a0 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.\u00a0 Continuous code review keeps your “technical debt” burden in check\u2026<\/p>\nSo why is something as elementary as code review so effective? As any developer will tell you, code has a “smell<\/em>“.\u00a0 This notion of “code smell” is very common in standard definitions of code review.\u00a0 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.<\/p>\nIt 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.\u00a0 These rules can catch the most frequent quality defects.\u00a0 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<\/em> or god objects<\/em>\u2026<\/p>\n<\/div>\n1. Captain, take the ship “hard to port”!<\/strong><\/h2>\nThe 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<\/em>. 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.<\/p>\n<\/div>\n2. Developer brain time available<\/strong><\/h2>\nCode review takes time, and especially valuable developers\u2019 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.\u00a0 We also avoid the opportunity cost of draining key resources that could instead be allocated to building \u201crevenue driving\u201d functionality.<\/p>\n
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.\u00a0 \u00a0The same is true for quality rules that highlight inefficient or even “dead<\/em>” code.\u00a0 This level of automation leaves developers with more time to focus on the more complex problems that only a manual code review can decipher.<\/p>\nAutomation thus increases (or at least does not decrease) developer availability and prevents harmful bottlenecks from emerging the development cycle.<\/p>\n
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…<\/p>\n<\/div><\/div><\/div>
Continuous Quality checking for your RPG code : Eliminate the “technical debt” in your IBM i application. Watch Now!<\/strong><\/p>\n<\/div>Watch the webinar<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. Nothing is lost, everything is shared<\/strong><\/h2>\nKnowledge 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.<\/p>\n
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,<\/p>\n
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 \u2013 and the one that fits best in a DevOps approach \u2013 is to integrate the code quality checker right into the development environment, making the checking and enforcement of quality rules continuous<\/em>. It also saves the developer the tedious task of flipping back and forth between his editor and some external knowledge source.<\/p>\n<\/div>\n4. Meanwhile, on the IBM i<\/strong><\/h2>\n“Old pots make the best soup<\/em>,” 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<\/a>, (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.<\/p>\n<\/div>\n5. What about security?<\/strong><\/h2>\nIf there is one subject of utmost importance, especially since the advent of the DevOps movement, it is undoubtedly security within the source code<\/em>. We are talking here about DevSecOps<\/em>. 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.<\/p>\nLegacy 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.<\/p>\n
Summary<\/h2>\n\n- Captain, take the ship \u201chard to port\u201d!<\/a><\/li>\n
- Developer brain time available<\/a><\/li>\n
- Nothing is lost, everything is shared<\/a><\/li>\n
- Meanwhile, on the IBM i<\/a><\/li>\n
- What about security? <\/a><\/li>\n
- The final word <\/a><\/li>\n<\/ol>\n<\/div><\/div>
It won\u2019t come as any surprise to you if I say that code review matters<\/em>.\u00a0 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.\u00a0 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.\u00a0 Continuous code review keeps your “technical debt” burden in check\u2026<\/p>\nSo why is something as elementary as code review so effective? As any developer will tell you, code has a “smell<\/em>“.\u00a0 This notion of “code smell” is very common in standard definitions of code review.\u00a0 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.<\/p>\nIt 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.\u00a0 These rules can catch the most frequent quality defects.\u00a0 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<\/em> or god objects<\/em>\u2026<\/p>\n<\/div>\n1. Captain, take the ship “hard to port”!<\/strong><\/h2>\nThe 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<\/em>. 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.<\/p>\n<\/div>\n2. Developer brain time available<\/strong><\/h2>\nCode review takes time, and especially valuable developers\u2019 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.\u00a0 We also avoid the opportunity cost of draining key resources that could instead be allocated to building \u201crevenue driving\u201d functionality.<\/p>\n
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.\u00a0 \u00a0The same is true for quality rules that highlight inefficient or even “dead<\/em>” code.\u00a0 This level of automation leaves developers with more time to focus on the more complex problems that only a manual code review can decipher.<\/p>\nAutomation thus increases (or at least does not decrease) developer availability and prevents harmful bottlenecks from emerging the development cycle.<\/p>\n
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…<\/p>\n<\/div><\/div><\/div>
Continuous Quality checking for your RPG code : Eliminate the “technical debt” in your IBM i application. Watch Now!<\/strong><\/p>\n<\/div>Watch the webinar<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. Nothing is lost, everything is shared<\/strong><\/h2>\nKnowledge 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.<\/p>\n
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,<\/p>\n
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 \u2013 and the one that fits best in a DevOps approach \u2013 is to integrate the code quality checker right into the development environment, making the checking and enforcement of quality rules continuous<\/em>. It also saves the developer the tedious task of flipping back and forth between his editor and some external knowledge source.<\/p>\n<\/div>\n4. Meanwhile, on the IBM i<\/strong><\/h2>\n“Old pots make the best soup<\/em>,” 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<\/a>, (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.<\/p>\n<\/div>\n5. What about security?<\/strong><\/h2>\nIf there is one subject of utmost importance, especially since the advent of the DevOps movement, it is undoubtedly security within the source code<\/em>. We are talking here about DevSecOps<\/em>. 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.<\/p>\nLegacy 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.<\/p>\n
It won\u2019t come as any surprise to you if I say that code review matters<\/em>.\u00a0 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.\u00a0 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.\u00a0 Continuous code review keeps your “technical debt” burden in check\u2026<\/p>\n So why is something as elementary as code review so effective? As any developer will tell you, code has a “smell<\/em>“.\u00a0 This notion of “code smell” is very common in standard definitions of code review.\u00a0 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.<\/p>\n 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.\u00a0 These rules can catch the most frequent quality defects.\u00a0 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<\/em> or god objects<\/em>\u2026<\/p>\n 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<\/em>. 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.<\/p>\n Code review takes time, and especially valuable developers\u2019 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.\u00a0 We also avoid the opportunity cost of draining key resources that could instead be allocated to building \u201crevenue driving\u201d functionality.<\/p>\n 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.\u00a0 \u00a0The same is true for quality rules that highlight inefficient or even “dead<\/em>” code.\u00a0 This level of automation leaves developers with more time to focus on the more complex problems that only a manual code review can decipher.<\/p>\n Automation thus increases (or at least does not decrease) developer availability and prevents harmful bottlenecks from emerging the development cycle.<\/p>\n 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…<\/p>\n<\/div><\/div><\/div> Continuous Quality checking for your RPG code : Eliminate the “technical debt” in your IBM i application. Watch Now!<\/strong><\/p>\n<\/div> 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.<\/p>\n 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,<\/p>\n 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 \u2013 and the one that fits best in a DevOps approach \u2013 is to integrate the code quality checker right into the development environment, making the checking and enforcement of quality rules continuous<\/em>. It also saves the developer the tedious task of flipping back and forth between his editor and some external knowledge source.<\/p>\n “Old pots make the best soup<\/em>,” 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<\/a>, (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.<\/p>\n If there is one subject of utmost importance, especially since the advent of the DevOps movement, it is undoubtedly security within the source code<\/em>. We are talking here about DevSecOps<\/em>. 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.<\/p>\n 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.<\/p>\n1. Captain, take the ship “hard to port”!<\/strong><\/h2>\n
2. Developer brain time available<\/strong><\/h2>\n
3. Nothing is lost, everything is shared<\/strong><\/h2>\n
4. Meanwhile, on the IBM i<\/strong><\/h2>\n
5. What about security?<\/strong><\/h2>\n
![\"\"](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2020\/02\/SJU-Teams-Linkedin-PPT-300x300.png\")
<\/p>\n<\/div><\/div><\/div>