Skip to main content

Track and Trace Code Review Standard

Version: 1, effective date: 04-Oct-2021

Aleksandr Illarionov

Contents​

IT Standards of Code Review Practices

1 Standard description​

This document will define standard of working with the source code of T&T business applications.

Check list:

  • Establish Automate process

  • Set goals and standards

  • Communicate Goals and Expectations**

  • Define a Code Review Process

  • Use a code review checklist

  • Authors should annotate source code before the review**

  • Review for no more than 60 minutes at a time

  • Establish a process for fixing defects found

2 Document objectives and benefits​

2.1 Objectives​

Objectives of the document are:

  • Define code quality policy for all T&T business applications
  • Define code writing style standards

2.2 Benefits​

The document helps to identify readiness of business application to T&T implementation.

3 Definitions​

T&T – Track & trace

Lint ( or a linter) – software from category of static code analysis tool used to flag programming errors, bugs, stylistic errors and suspicious constructs

Please refer to IT P&P portal search page for more definitions.

4 Roles & Responsibilities​

Accountable: Approves the activity or recommendations from a person or team.

Responsible: Responsible to do the work associated with an activity, either by completing personally or through sole accountability for a team’s output.

Consulted: Reviews the output of an activity and provides input, but has no approval authority. Provides support to an activity and may be consulted by team during the course of the activity.

Informed: Is informed about activities to aid in planning own work.

#ActivityGDC TTDCBTS T&T
1Define and maintain StandardA / RC
2Apply the Standard in the T&T Implementation projectsA / RC

5 Code Review Practices​

5.1 Code Preparation​

Check out file to be prepared The relevant module and any associated header files should be formally ‘checked out’ of the version control or software code control system for any changes to take place.

The most recent checked-in or promoted revision should be used.

Make changes to each unit/module In order to prevent unintentional change of functionality, no changes to the actual body of code or its structure should be made prior to a first pass review. Changes which do not affect the functionality (such as the addition of comments) can be made.

Scope of review

The general categories of information to be included are:

  • Comments

  • Data usage (input/output parameters, data structures accessed, changes to global variables, etc.)

  • Unit processing algorithm/design

  • Potential failure modes related to system hazards to the patient; required mitigation actions

  • Miscellaneous notes on critical or risky areas of the design; design assumptions; etc.

Check in files

The updated module(s) should be checked back into the official version control or software code control system

Prepare diagrams and other supporting information

Data flow, state diagrams or any other useful descriptive information should be prepared to present along with the code for review. This information may be added to the wiki page of the application project after the review.

Comment related units

If, when preparing just one unit from a module, it is found necessary to analyze other un-reviewed units, the addition of comments should be made, and any helpful information that could be of future use in the review and/or test of those additional units should be recorded.

Document recommended changes to actual code

Recommended changes may be prepared on a copy of the module and presented for review.

Both the original and the copy with differences clearly indicated should be provided.

Run Lint

Lint must be run on the module or unit(s).

Each warning or message produced should be inspected and any real issues corrected or flagged for correction

See the code review checklist on the following pages for a list of the items Lint must be used to detect.

Global wrap-up’ output can be discarded and ignored for code review.

The final Lint output will be recorded as part of the formal review meeting.

5.2 Code Review Process Overview​

5.2.1 Frameworks and solutions restrictions​

In application development restricted to use frameworks and solutions supported by JTI (GSD, DCO, TA, MMDC, etc.).

5.2.2 Code Preparation​

Preparer ensures that code adheres to code review checklist. Makes non-functional changes as necessary. Notes any functional changes that should be made to adhere to checklist. Pays particular attention to including all items required for header blocks and adding helpful comments.

5.2.3 Off-line Code Review​

Individually or in small groups as desired, reviewers review the code for all items on the code review checklist, covering the areas of proper operation, adherence to coding guidelines, and implementation of risk (and safety hazard) mitigation actions. Reviewers recommend changes.

5.2.4 Formal Code Review Meeting​

Development team review suggested changes from the off-line code reviews, decide actions, approve code.

  • The code review checklists filled out during off-line review, and any recommended changes to code, will be analyzed.

  • The code review record will be filled out to document any actions, including required changes to the code, and the approval of the code.

  • The code review record and attached code review checklists will be filed as the official record of the code review.

5.3 Coding Guidelines​

In the process of writing code, should adhere to the following guidelines:

6 Standard Owner​

Provide here information about the role who owns the standard

7 Document Control​

7.1 Contact Person​

Questions and feedback regarding this standard should be submitted to the Illarionov, Aleksandr

7.2 Revision History​

VersionEffective datePurpose of changeAuthor
104-Oct-2021First version of the documentAleksandr Illarionov

8 References​

ANY QUESTIONS?

ASK TEAM