Comments on: Code review checklist for AS/400 applicationhttp://itknowledgeexchange.techtarget.com/itanswers/code-review-checklist-for-as400-application/
Fri, 09 Dec 2016 16:23:18 +0000hourly1By: TomLiottahttp://itknowledgeexchange.techtarget.com/itanswers/code-review-checklist-for-as400-application/#comment-116682
Sun, 24 Feb 2013 12:36:13 +0000http://itknowledgeexchange.techtarget.com/itanswers/code-review-checklist-for-as400-application/#comment-116682Unit Testing is often not done by QA and is generally impossible for end users. A Unit Test tests a “unit” in isolation. It most often is created by the developer and commonly performed by the developer, usually because of the difficulty in getting it done by anyone else. I usually first code a CL wrapper that passes in a set of known values and compares actual results to expected results. The “unit” being tested might be a procedure or a *PGM, but it will not be integrated with other elements. It will succeed or fail as a ‘Unit’.

As the ‘unit’ is iteratively developed, the wrapper might also be developed more. Ideally, a database of test values and expected results allows the wrapper to repeat tests automatically and to test new combinations of inputs.

Unit Testing should be done all through the development of the component (the ‘unit’). Depending on development methodology, the site standards and other considerations, code review probably shouldn’t be done until after the developer is satisfied with the Unit Test. The code is then assumed by the developer to be ready for review. Any test wrapper can also be promoted for QA’s use.

The code review should then be reviewing code that “works”. The review may find numerous issues with quality or standards or simply unexpected circumstances. Because the Unit Test already exists, fixes may be tested as soon as they’re made, and a subsequent review can conceivably be made later the same day, or at least it can be made soon enough that reviewers are still freshly familiar with the code.

A code review should review code that is candidate for promotion. There is less need to review code that is known will be massively modified.

As for what a code review should physically consist of, I suggest starting with two Google searches, first for [ code review ] and second for [ code review checklist ].

What works for me is unlikely to work well for you. The types of code and their purposes are likely to be very different. For example, the last major code unit I created was an interface-matching replacement for IBM’s Qp0lProcessSubtree()–Process a Path Name API. That’s not the kind of code most sites see. Reviews would have different focuses.

If you read a few articles on code reviews, you can then look over some of the code-review checklists already available on the internet. It’s likely that many of them won’t seem to apply to you, but you can cut & paste parts together to custom build one that seems to work in your environment.

When you create a first example, you might paste it back here to see if anyone can add bits that weren’t obvious before. But it will be bits added to something that you think fits. It won’t be something that works in some other shop.