mss-redesign - r1.2 - code review issues and resolutions

8/8/2019 MSS-Redesign - R1.2 - Code Review Issues and Resolutions

1/16

VERSION DATE CHANGES

1.00 12/21/10 Added initial review items

2.00 01/03/11 Added IBM code review feedback from 12/29


2/16

AUTHOR

Corridoni

Corridoni


3/16

No. Release # Component Name

8 1.2 DEVR1_2 All Java Classes

9 1.2 DEVR1_2 All Database Procedures and Packages

10 1.2 DEVR1_2 All Java Classes

11 1.2 DEVR1_2 Batch processing unit tests

12 1.2 DEVR1_2 Procedures in XCOM_BATCH and XCOM_PROCESSING packages

13 1.2 DEVR1_2 XCOM_BATCH procedures

14 1.2 DEVR1_2 XCOM_API procedures

15 1.2 DEVR1_2 XCOM_PROCESSING procedures

CVSBranch

CVSVersion.


4/16

16 1.2 DEVR1_2 Missing XCOM_PROCESSING package

17 1.2 DEVR1_2 AR_CUSTOMER_PROCESS

18 1.2 DEVR1_2 TABLE_MAINTENANCE package

19 1.2 DEVR1_2 XCOM_API.XCOM_GET_CUST_LIST

20 1.2 DEVR1_2 XCOM_API.XCOM_GET_SERIAL_LIST_old

21 1.2 DEVR1_2 Many XCOM_API procedures


5/16

22 1.2 DEVR1_2 Much of the new PL/SQL objects

23 1.2 DEVR1_2 Much of the new PL/SQL objects

24 1.2 DEVR1_2 com.xim.mss.framework.batch.service.scheduler.MssBatchJob.java 1.1.2.5

28 1.2 DEVR1_2 com.xim.mss.framework.batch.service.dao.BatchJobDAO 1.1.2.3

29 1.2 DEVR1_2 com.xim.mss.framework.batch.service.dao.BatchJobDAO 1.1.2.3

32 1.2 DEVR1_2 com.xim.mss.framework.batch.service.dao.CreateOrderDAO 1.1.4.3

33 1.2 DEVR1_2 com.xim.mss.framework.batch.service.dao.OrderHeaderHelper 1.1.4.7

34 1.2 DEVR1_2 com.xim.mss.framework.batch.service.dao.SerialNoBatchDAO 1.1.2

36 1.2 DEVR1_2 com.xim.mss.framework.batch.service.SerialNoBatchProcess 1.1.2.10



41 1.2 DEVR1_2 XCOM_API 1.1.2.7

42 1.2 DEVR1_2 XCOM_API 1.1.2.7

43 1.2 DEVR1_2 XCOM_API 1.1.2.7

44 1.2 DEVR1_2 XCOM_PROCESSING

45 1.2 DEVR1_2

COMPLETE_CALL_ORDER_HIST_OTC.sql

1.2.4.2

46 1.2 DEVR1_2

COMPLETE_CALL_GET_ORDER_HIST.sql

1.1.4.3

47 1.2 DEVR1_2 MSS_PROCESSING.PKB 1.1.2.1


6/16

48 1.2 DEVR1_2 MSS_PROCESSING.PKB 1.1.2.1


7/16

Line # Issue/Review Comments Category Reviewed

Defect 12/20/2010

Defect 12/20/2010

Defect 12/20/2010

Defect 12/20/2010

Defect 12/21/2010

Defect 12/21/2010

Defect 12/21/2010

Defect 12/21/2010

Method/ProcedureName

Need consistent commenting. Object header commentsare required. Method comments with parameters, returnvalues, and exceptions are required for each method andmust be consistently implemented regardless if different

developers changed different code modules.

Need consistent commenting. Package headercomments are required. Procedure header commentswith parameters, return values, and exceptions arerequired for each procedure and must be createdconsistently across all objects regardless of the developerwho created it

Use logger.debug(e), where e is an exception instead ofcalling e.printStackTrace()

No batch processing unit test documentation was found inSharePoint. Two Word documents appeared to referencezip files that were expected to contain test results, butthese zip files were not available.

XCOM TDD section 4.1 PL/SQL Procedure Definitionslists naming conventions indicating all new XCOM procsmust have a consistent prefix making them easilyrecognizable. All procs in XCOM_API follow thisconvention correctly. But the procs in XCOM_BATCHand XCOM_PROCESSING packages have no consistentprefix

There are no calls to COMMIT_MSS_LOGS with DEBUGinformation. We certainly don't want an enormousamount of debug information such that it impactsperformance but I find it hard to believe that there isabsolutely no need for any debugging information to help

diagnose issues or help debug testing defects.

There are no calls to COMMIT_MSS_LOGS with DEBUGinformation. We certainly don't want an enormousamount of debug information such that it impactsperformance but I find it hard to believe that there isabsolutely no need for any debugging information to helpdiagnose issues or help debug testing defects.

There are no calls to COMMIT_MSS_LOGS with DEBUGinformation. We certainly don't want an enormousamount of debug information such that it impactsperformance but I find it hard to believe that there isabsolutely no need for any debugging information to helpdiagnose issues or help debug testing defects.


8/16

Defect 12/21/2010

Defect 12/21/2010

Defect 12/21/2010

Defect 12/21/2010

Defect 12/21/2010

Defect 12/21/2010

The spreadsheet CIBER sent contains 3 logically namedpackages, XCOM_API, XCOM_BATCH andXCOM_PROCESSING. However there is noXCOM_PROCESSING package in CVS. Searching forthe procedure names I did find something named"mss_processing" containing similar functions. Renamethe package "mss_processing" to be"XCOM_PROCESSING" as indicated so all 3 packages

appear together given their conistent naming, also matchcase, don't name one package with lowercase and nameanother package with uppercase.

CIBER list says AR_CUSTOMER_PROCESS procedurewas modified. In reviewing the code in the DEVR1_2CVS branch it appears all calls to the new loggingprocedure COMMIT_MSS_LOGS have disappeared and Isee the old APP_DEBUG_INFO_INSERT procedure.It appears the new XCOM development was done to oldversions of this procedure instead of the R1_1 version.

CIBER list says TABLE_MAINTENANCE package wasmodified for R1.2 but in viewing the pkb and pks files inDEVR1_2 for TABLE_MAINTENANCE package there areno comments or revision history content which indicatesthis was changes or why. If it really was modified youmust include some comment or revision history notingwho changed what, when and why.

out_ERR_CODE parameter is not being logged in calls toCOMMIT_MSS_LOGS consistently. Some placescorrectly concatenate out_ERR_MESSAGE +out_ERR_CODE when calling COMMIT_MSS_LOGS butin most instances the our_ERR_CODE is not beinglogged, both the error message and the correspondingerror code should be logged when there are errors.

out_ERR_CODE parameter is not being logged in calls toCOMMIT_MSS_LOGS consistently. Some placescorrectly concatenate out_ERR_MESSAGE +out_ERR_CODE when calling COMMIT_MSS_LOGS butin most instances the our_ERR_CODE is not beinglogged, both the error message and the correspondingerror code should be logged when there are errors.

I am seeing the same problem where out_ERR_CODE isnot being logged in many of the XCOM_API procedures,

same issue as #19 and #20


9/16

Defect 12/21/2010

Defect 12/21/2010

executeProcesses 95 defect 12/29/2010

All Several defect 12/29/2010

All Several No comments for methods/class defect 12/29/2010

Some Several defect 12/29/2010

46 defect 12/29/2010

Some Several defect 12/29/2010

some Several defect 12/29/2010

some Several defect 12/29/2010

134 addOperation defect 12/29/2010

Some Several Error code variable (out_err_code) is not used in the sub defect 12/29/2010

Some Eg.964 Typo 12/29/2010

Some Eg.1419 Debugging missing in the exception part defect 12/29/2010

All All Missing this in the brach DEVR1_2 defect 12/29/2010

Table, Index creation Index creation Suggestion 12/29/2010

Cursor s1 59 Suggestion 12/29/2010

Err Code Some defect 12/29/2010

Most of the new PL/SQL objects contains commentedcode, i.e. lines of PL/SQL code commented out. Theexisting MSS legacy codebase is difficult to maintainbecause of how messy the code is, with commented codeblocks everywhere.There is no reason why you need to commit commentedcode into CVS. If there is a codeblock or line of codewhich is no longer required, remove it, do not comment it

out and commit it to CVS. This is new development andwe want it as clean and easy to maintain as possible.If there are legitimately instances where you want to havea line or block of code to include or exclude on demandfor testing purposes, ensure you include an appropriateexplanation of what happens when you include that codeas a comment with explanation of purpose so futuredevelopers know why the lines are commented out.Leaving lines of code simply commented out andcommitted to CVS will just confuse future developers andmake the newly developed code just as messy as theexisting legacy codebase. Examples of commented codeinclude COMMIT and ROLLBACK statements, calls toDBMS_OUTPUT, exception blocks /* If SQL%NOTFOUND then l_PENDING_ADD_REMOVE :=to_char('A'); End If; */ variable declarations--v_sply_reord_tbl sply_reord_tbl := sply_reord_tbl();

columns as part of INSERT statements - Insert intoserial_gtt

(MFG_PROD_CD,Success is mispelled in many instances across the newcode (out_err_message := 'Sucess';)

LOGGER.error is used in if condition. It should beLOGGER.info

Code should use logger.ERROR rather thane.printStackTrace() to have good debugging.

Code should use logger.ERROR rather thane.printStackTrace() to have good debugging in the catch

block

getOrderHeadersBycallId


block


block

Code should use logger.debug rather thanSystem.out.println.


block

Use logger.info to provide information rather thanlogger.error.

Typo error for the variable assignmentout_err_message := 'Sucess';

Comment need to be added for the newly created Indexcreation part

Both Old code need to be commented and new existingcode to be placed

Error code variable (out_err_code) is not used whilecalling the sub procedure commit_mss_logs procedure


10/16

mss_ohb_failure_detail Some Clarification 12/29/2010No_data_found exception is not handled in the proceduremss_ohb_failure_detail


11/16

Reviewed By Status Result Closed

D. Russell Open

D. Russell Open

D. Russell Open

D. Russell Open

M. Corridoni Open

M. Corridoni Open

M. Corridoni Open

M. Corridoni Open


12/16

M. Corridoni Open

M. Corridoni Open

M. Corridoni Open

M. Corridoni Open

M. Corridoni Open

M. Corridoni Open


13/16

M. Corridoni Open

M. Corridoni Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open

IBM Open


14/16


15/16

STATUS VALUES

Closed Issue resolved and SRD changed if necessary

Open Not resolved yet

Conflict Issue is an observation of a conflict in requirements, see Risk section in BRD

Design Issue describes a design consideration and not an issue with software requirement

CATEGORY VALUES

Defect Incorrect or incomplete requirement

Typo Spelling or grammatical error

Issue Issue is an observation of a conflict in requirements

Question Requirement lacks clarity or is not clearly understood by reviewer


16/16

, input into SDD/TDD

mss-redesign - r1.2 - code review issues and resolutions

Documents