1) Application Design Structure and layered architecture.
a) Build Management - All configurations for Rest Services etc , static values in config files. Each dependency listed with version in lib folder , Profiles for each environment.
b) Interceptor – API request validation - If the API request has some prequisite validation this needs to be handled here
Example : Post Login Api Calls – Session Validator , Brute force Attack Prevention – Max Request Interceptor
c) Request Model Validation - All data parameters of object should be validated at the Pojo Model level.
Example : Login Request has user object, it should be validated for fields like username
(validation for null , empty and may be pattern for regex) . This avoids large data being injected in requests.
d) Service Level should be generic
Example :- All consuming REST services/ RMI call should be through common gateway
e) Data retrieval from third party service layer should be validated.
Example :- Keys returned from rest service may be null or empty , such cases need to be handled and updated
Example :- Json response from service level is expected to have key “LOGGEDIN”, this has been missed , such cases data should be validated and custom exception logged and handled gracefully.
f) Timeouts & Connectivity Downtime Handling
Rest Connection , Read , Socket Timeout to be addressed and tested.
DB and other web service etc outbound connections should be tested for possible downtime and gracefully handle the failure.
2) Code Quality
a) Attribute and method naming should be clear and understood by any developer who is not the author of the code. (camelCase variable and method declarations)
E.g. calculateGst(BigDecimal amount), BalanceLoader.java, etc.
Bad: List list;
Good: List<String> users;
b) Methods need to be 15 lines max with exceptions handling within one try catch block , each method should do a specific function which is explained in its name.
E.g. CustomerDao.java for data access logic only, Customer.javafor domain object, CustomerService.java for business logic,
and CustomerValidator.java for validating input fields, etc.
Similarly, separate functions like processSalary(String customerCode) will invoke other sub functions with meaningful names like
evaluateBonus(String customerCode),
evaluateLeaveLoading(String customerCode), etc
c) Variable declaration for value retrieval from external method or service, in these scenarios if value if is not being used to validate / business logic , no new variables should be declared and assigned.
d) Logging is mandatory to easily track a request flow. Logging levels should be precise to understand the current state of the request flow.
e) Using collections and library methods for String , Date utility Functionns.
f) Exception Handling should be optimized.
g) Creating new Instances of objects , Beans , static values assigning should be taken extreme precaution and should be tested locally handling multiple scenarios
h) String comparison and Object Comparison, should be done effectively.
I) AutoCloseable Interface implementing classes should use the enhanced try block for handling streams and and IO operations.
j) Session variables usage should be limited for specific business logic only.
k) Sonar Lint should be used while development on each class to check before and after changes on bugs.
3) Checklist
| Checklist | Description/example |
| Make a class final and the object immutable where possible. | Immutable classes are inherently thread-safe and more secured. For example, the Java String class is immutable and declared as final. |
| Minimize the accessibility of the packages, classes and its members like methods and variables. | E.g. private, protected, default, and public access modifiers. |
| Code to interface as opposed to implementation. | Bad: ArrayList<String> names = new ArrayList<String>();
Good: List<String> names = new ArrayList<String>();
|
| Use right data types. | For example, use BigDecimal instead of floating point variables like float or double for monetary values. Use enums instead of int constants. |
| Avoid finalizers and properly override equals, hashCode, and toString methods. | The equals and hashCode contract must be correctly implemented to prevent hard to debug defects. |
| Write fail-fast code by validating the input parameters. | Apply design by contract. |
| Return an empty collection or throw an exception as opposed to returning a null. Also, be aware of the implicit autoboxing and unboxing gotchas. | NullpointerException is one of the most common exceptions in Java. |
Don’t log sensitive data.
|
Security.
|
Clearly document security related information.
|
Security.
|
Sanitize user inputs.
|
Security.
|
Favor immutable objects.
|
Security.
|
Use Prepared statements / Optimized ORM as opposed to ordinary statements.
|
Security to prevent SQL injection attack.
|
Release resources (Streams, Connections, etc).
|
Security to prevent denial of service attack (DoS) and resource leak issues.
|
Don’t let sensitive information like file paths, server names, host names, etc escape via exceptions.
|
Security and Exception Handling.
|
Follow proper security best practices like SSL (one-way, two-way, etc), encrypting sensitive data, authentication/authorization, etc.
|
Security.
|
Use exceptions as opposed to return null.
|
Exception Handling.
|
Don’t ignore or suppress exceptions. Standardize the use of checked and unchecked exceptions. Throw exceptions early and catch them late.
|
Exception Handling.
|
Write thread-safe code with proper synchronization and use of immutable objects. Also, document thread-safety.
|
Concurrency.
|
Keep synchronization section small and favor the use of the new concurrency libraries to prevent excessive synchronization.
|
Concurrency and Performance.
|
Reuse objects via flyweight design pattern.
|
Performance.
|
Presence of long lived objects like ThreaLocal and static variables holding references to lots of short lived objects.
|
Memory Leak and Performance
|
| Favor using well proven frameworks and libraries as opposed to reinventing the wheel by writing your own. | E.g. Apache commons libraries, Spring libraries, XML/JSON libraries, etc. |
| RISK Tests and Security Prevention Link |
|
