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
 AUTHOR
Corridoni
Corridoni
No. Release # CVS Component Name CVS
Branch Version.
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

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

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

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

38 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 1.2.4.2
COMPLETE_CALL_ORDER_HIST_OTC.sql
46 1.2 DEVR1_2 1.1.4.3
COMPLETE_CALL_GET_ORDER_HIST.sql
47 1.2 DEVR1_2 MSS_PROCESSING.PKB 1.1.2.1
48 1.2 DEVR1_2 MSS_PROCESSING.PKB 1.1.2.1
Method/Procedure Line # Issue/Review Comments Category Reviewed
Name
Need consistent commenting. Object header comments Defect 12/20/2010
are required. Method comments with parameters, return
values, and exceptions are required for each method and
must be consistently implemented regardless if different
developers changed different code modules.

Need consistent commenting. Package header Defect 12/20/2010

comments are required. Procedure header comments
with parameters, return values, and exceptions are
required for each procedure and must be created
consistently across all objects regardless of the developer
who created it

Use logger.debug(e), where e is an exception instead of Defect 12/20/2010

calling e.printStackTrace()
No batch processing unit test documentation was found in Defect 12/20/2010
SharePoint. Two Word documents appeared to reference
zip files that were expected to contain test results, but
these zip files were not available.

XCOM TDD section 4.1 PL/SQL Procedure Definitions Defect 12/21/2010

lists naming conventions indicating all new XCOM procs
must have a consistent prefix making them easily
recognizable. All procs in XCOM_API follow this
convention correctly. But the procs in XCOM_BATCH
and XCOM_PROCESSING packages have no consistent
prefix

There are no calls to COMMIT_MSS_LOGS with DEBUG Defect 12/21/2010

information. We certainly don't want an enormous
amount of debug information such that it impacts
performance but I find it hard to believe that there is
absolutely no need for any debugging information to help
diagnose issues or help debug testing defects.

There are no calls to COMMIT_MSS_LOGS with DEBUG Defect 12/21/2010

information. We certainly don't want an enormous
amount of debug information such that it impacts
performance but I find it hard to believe that there is
absolutely no need for any debugging information to help
diagnose issues or help debug testing defects.

There are no calls to COMMIT_MSS_LOGS with DEBUG Defect 12/21/2010

information. We certainly don't want an enormous
amount of debug information such that it impacts
performance but I find it hard to believe that there is
absolutely no need for any debugging information to help
diagnose issues or help debug testing defects.
The spreadsheet CIBER sent contains 3 logically named Defect 12/21/2010
packages, XCOM_API, XCOM_BATCH and
XCOM_PROCESSING. However there is no
XCOM_PROCESSING package in CVS. Searching for
the procedure names I did find something named
"mss_processing" containing similar functions. Rename
the package "mss_processing" to be
"XCOM_PROCESSING" as indicated so all 3 packages
appear together given their conistent naming, also match
case, don't name one package with lowercase and name
another package with uppercase.

CIBER list says AR_CUSTOMER_PROCESS procedure Defect 12/21/2010

was modified. In reviewing the code in the DEVR1_2
CVS branch it appears all calls to the new logging
procedure COMMIT_MSS_LOGS have disappeared and I
see the old APP_DEBUG_INFO_INSERT procedure.
It appears the new XCOM development was done to old
versions of this procedure instead of the R1_1 version.

CIBER list says TABLE_MAINTENANCE package was Defect 12/21/2010

modified for R1.2 but in viewing the pkb and pks files in
DEVR1_2 for TABLE_MAINTENANCE package there are
no comments or revision history content which indicates
this was changes or why. If it really was modified you
must include some comment or revision history noting
who changed what, when and why.

out_ERR_CODE parameter is not being logged in calls to Defect 12/21/2010

COMMIT_MSS_LOGS consistently. Some places
correctly concatenate out_ERR_MESSAGE +
out_ERR_CODE when calling COMMIT_MSS_LOGS but
in most instances the our_ERR_CODE is not being
logged, both the error message and the corresponding
error code should be logged when there are errors.

out_ERR_CODE parameter is not being logged in calls to Defect 12/21/2010

COMMIT_MSS_LOGS consistently. Some places
correctly concatenate out_ERR_MESSAGE +
out_ERR_CODE when calling COMMIT_MSS_LOGS but
in most instances the our_ERR_CODE is not being
logged, both the error message and the corresponding
error code should be logged when there are errors.

I am seeing the same problem where out_ERR_CODE is Defect 12/21/2010

not being logged in many of the XCOM_API procedures,
same issue as #19 and #20
 Most of the new PL/SQL objects contains commented Defect 12/21/2010
code, i.e. lines of PL/SQL code commented out. The
existing MSS legacy codebase is difficult to maintain
because of how messy the code is, with commented code
blocks everywhere.
There is no reason why you need to commit commented
code into CVS. If there is a codeblock or line of code
which is no longer required, remove it, do not comment it
out and commit it to CVS. This is new development and
we want it as clean and easy to maintain as possible.
If there are legitimately instances where you want to have
a line or block of code to include or exclude on demand
for testing purposes, ensure you include an appropriate
explanation of what happens when you include that code
as a comment with explanation of purpose so future
developers know why the lines are commented out.
Leaving lines of code simply commented out and
committed to CVS will just confuse future developers and
make the newly developed code just as messy as the
existing legacy codebase. Examples of commented code
include COMMIT and ROLLBACK statements, calls to
DBMS_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 into
serial_gtt
(MFG_PROD_CD,
Success is mispelled in many instances across the new Defect 12/21/2010
code (out_err_message := 'Sucess';)
executeProcesses 95 LOGGER.error is used in if condition. It should be defect 12/29/2010
LOGGER.info
All Several Code should use logger.ERROR rather than defect 12/29/2010
e.printStackTrace() to have good debugging.
All Several No comments for methods/class defect 12/29/2010
Some Several Code should use logger.ERROR rather than defect 12/29/2010
e.printStackTrace() to have good debugging in the catch
block
getOrderHeadersBycallI 46 Code should use logger.ERROR rather than defect 12/29/2010
d e.printStackTrace() to have good debugging in the catch
block
Some Several Code should use logger.ERROR rather than defect 12/29/2010
e.printStackTrace() to have good debugging in the catch
block

some Several Code should use logger.debug rather than defect 12/29/2010
System.out.println.
some Several Code should use logger.ERROR rather than defect 12/29/2010
e.printStackTrace() to have good debugging in the catch
block
134 addOperation Use logger.info to provide information rather than defect 12/29/2010
logger.error.
Some Several Error code variable (out_err_code) is not used in the su defect 12/29/2010
Some Eg.964 Typo error for the variable assignment Typo 12/29/2010
out_err_message := 'Sucess';
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 Comment need to be added for the newly created Index Suggestion 12/29/2010
creation part
Cursor s1 59 Both Old code need to be commented and new existing Suggestion 12/29/2010
code to be placed
Err Code Some Error code variable (out_err_code) is not used while defect 12/29/2010
calling the sub procedure commit_mss_logs procedure
mss_ohb_failure_detail Some No_data_found exception is not handled in the procedure Clarification 12/29/2010
mss_ohb_failure_detail
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
M. Corridoni Open

M. Corridoni Open

M. Corridoni Open

M. Corridoni Open

M. Corridoni Open

M. Corridoni Open
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
IBM Open
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 requirements, input into

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
equirements, input into SDD/TDD