Some Tips to do a better code or points to have in mind when do a cross code-review

gistfile1.txt

Some Tips to do a better code or points to have in mind when do a cross code-review:

  - Classes and methods small -> Classes should represent simple entities. Methods should have one job. This is crucial for testing, refactoring, understanding, and maintaining.
  
  - Make class fields private, and provide getters when necessary -> This is necessary to encapsulate the logic in a class, so callers are not dependent on the class implementation.
  
  - Immutable classes -> Usage of setters are not a good practice. Using this on the classes, will let the data mutable, and the results can be catastrophic. Also, use final on variables (this will make them immutable).
  
  
  - Avoid large blocks of code -> Use whitespace to separate tiny, logical chunks of code. (Do not be afraid of whitespace. It is your friend.) Use inline documentation to describe unclear bits of code, but better yet, restructure your code and rename methods/variables until the code is clear.
  
  - Name your classes, fields, and methods descriptively -> Auto-complete in an IDE removes the effort involved in using longer names, and clear names are what makes your code human-parseable.
  
  - When writing a piece of code, future readers should not be able to tell what member of the team wrote it. Having an institutionally-consistent codebase allows the whole team to easily read, understand, and alter unfamiliar code.
  
  - Usage of patterns -> Prefer always use a good pattern, like strategy, template, builder, etc, then create a weird logic with full of if/elses, loops, etc.
  
  - Reduce the amount of if/else using Optional -> Learn how to use Optional will take you to another level of codification, and will keep you code cleaner.
  
  - Avoid anemic models -> About the Model Layer, from Eric Evan's book Domain driven Design: 
     "Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software."
	 
  - No println allowed! -> if you want to print something on the console, use log instead println. (in java, most of the applications use Lombok lib, so you can annotate your class with @Slf4j)
  

  - Use Lombok -> mandatory
	
  - Use StringUtils.isBlank() instead equals("") -> this method will check, at once, if your string is null, empty or whitespace only. 
  
  - On Typescript, use "any" only when you really don't know which type are you expecting (or sending, if it's a function result) -> prefer use explicty types on variable and methods, this can make the code more consistent and avoid some type mismatch during the runtime. 
  
  -Logs
    - Use DEBUG instead INFO, unless the information you're logging if important to be show on production log 
 
 
  - Respect the organization of the projects defined by the lib (or other projects)
  
  
About merge requests and commits:
  - Write what's the purpose of it and what's necessary to evaluate your code -> A good merge request must have the minimum information about what are you're doing (or planning to do) and why it's exists
  
  - Push comment must be explicity on what's that change means
  
  - Push often -> Try to avoid push large amount of data. The larger is the amount of files one must review, the less will be the people reviewing it.
  
  
  
  - Ask (kindly) if someone from other teams can also check your code. 
     Note: someone's comment cannot be a blocker to merge the code, but it must be considered to be fix (or improved)