Code review strategy for backend.

Following are the points that the code reviewer should watch out for while reviewing backend code base.

1. Follow the MVC (Model-View-Controller) architecture: Separate your application into distinct layers for better organization and modularity. The model represents the data, the view handles the presentation, and the controller manages the interaction between the two.

2. Readability and Maintainability.

   1. Check if the code is well-organized, with proper indentation, consistent naming conventions, and appropriate comments.

   2. Ensure the code follows the principles of modularity and separation of concerns, using appropriate design patterns where applicable.

   3. Verify that the code is concise, avoiding duplication and complex logic.

   4. Look for clear and meaningful variable and method names, which aid in understanding the code's purpose.

3. Code comments and documentation.
   A good developer is one who does have to be present while their code is being reviewed. For this to happen the developer must provide ample information to the reviewer through comments. There are two types of comments in Java:

   1. Implementation comments: Comment which are written inside a scope of a function, defining what the code below the comment does.

      // Loop will print Eshopbox 50 times for (int x = 0; x < 50; x++) { logger.info("Eshopbox") }

   2. Documentation comments: Comments which are part of java-doc, defined above a function. These comments help other developers to get a gist of what the function is about and what it does.

      /** * Returns an Image object that can then be painted on the screen. * The url argument must specify an absolute <a href="#{@link}">{@link URL}</a>. The name * argument is a specifier that is relative to the url argument. * <p> * This method always returns immediately, whether or not the * image exists. When this applet attempts to draw the image on * the screen, the data will be loaded. The graphics primitives * that draw the image will incrementally paint on the screen. * * @param url an absolute URL giving the base location of the image * @param name the location of the image, relative to the url argument * @return the image at the specified URL * @see Image */ public Image getImage(URL url, String name) { try { return getImage(new URL(url, name)); } catch (MalformedURLException e) { return null; } }

4. 5/10, 50, 500 Rule.
   A code can be written in a single line, in a single file without and need for segregation based on its functionality. A controller can have 1000 line of code without any need for services. But a properly segmented code structure is what defines a good developer from a bad one. For this, we have a thumb rule called 5/10 | 50 | 500. This means:

   1. 5/10: At controller/ endpoint level, there should not be more than 5 or 10 functions present in a class. If there are more than 10 functions in a class, it means that that Class/ Endpoint has function which can be moved to another class.

   2. 50: Any function in controller and service should not have more than 50 lines of logical code. Logical code does not include scope parameters, return statements, declarations etc.

      private void run (Dog dog) { if (dog.getLegs() > 5) { // logical code logger.info("This is no longer a dog"); // logical code return; // not a logical code } // not a logical code // spacing is not considered as logical code raceService.addDogToRace(dog); // logical code if (dog.getWeight() < 10kg) { // logical code raceService.addLightWeightRacer(dog); // logical code } else { // logical code raceService.addHeavyWeightRacer(dog); // logical code } // not a logical code }

   3. 500: Service layer is responsible for connecting DAO layers with other DAL/ Services but the business logic while writing code in a function in helper layers should not exceed more than 500 lines of code.

5. Use meaningful and consistent naming conventions: Choose descriptive names for variables, classes, methods, and packages. Follow established naming conventions, such as camel case (e.g., myVariable) for functions and variables, to enhance code readability.

6. Error Handling and Exception Management:

   1. Check if exceptions are handled appropriately, with proper error logging and informative error messages.

   2. Ensure that exceptions are caught at the appropriate level in the application and handled gracefully, without causing unexpected behavior or crashes.

   3. Verify that critical resources (such as database connections) are released properly, even in the presence of exceptions.

7. Session usage in DAO layers.
   Best practice is to prepare session object inside the DAO layer and not the session layer. Never pass the session object as a function parameter as it becomes difficult to maintain its release in case of exception.

   1. Always see if try catch finally blocks used properly.

      public SomeDTO getDTOById(Long id) { Session hibernateSession = HibernateUtil.getHibernateSession(); try { HibernateUtil.beginTransaction(hibernateSesison); // write query to fetch data HibernateUtil.commitTransaction(hibernateSession); } catch (Exception ex) { // properlogging for exception. HibernateUtil.rollbackTransaction(hibernateSession); } finally { HibernateUtil.closeSession(hibernateSession); } }

8. Avoid using trailing scopes.

9. Avoid using native query.

10. Avoid using List<Object[]> while fetching data from data-source. Use user-defined DTOs to transfer data from DAO to Service layers

11. Using proper caching technique for config-level low rate-transactional tables.

12. Avoid usage of System.out.println, instead use proper loggers.

13. Avoid using loggers from sl4j dependencies.

14. Use named parameters instead of directly adding filter values as string using parameter which contains value from the request