- Conditionals (if, loops, ternary if): 1CP
- Aditional block of codes (try, catch, cases of switch, closures or lambdas): 1CP
- Coupling with specific project classes: 1CP
- If it's greenfiled, suggest start in a way more restrictive and evaluate, initial limit is 10.
- If it's a legacy of knowledge that already comes with a lot of complexity, increase the initial limit to 50.
- Look for always 90% or more to coverage.
- Look for write the tests more integrated possbile.
- Stay always alert to time of execution.
- To coverage code, use MC/DC technique (modify condition, decision converage).
- Use Boundary Testing technique to explore th values of test.
- Try use property based testing to go beyond to tests derivaded of a way sistematic.
- Define a metric and a way to evaluate inspired by CDD to control the increase to complexity of test files.
- Always that have an update of state on system, do the log in info level before and after the realization.
- Always that consume external sevices, do the log in info level before and after of api call.
- Always that do error treatment (try & catch), whose problem able to the flow of application continue, do the log in error level. Remember that avoid do the log in error level and pass the problem up.
- Do the log in debug level when to code have many ways of decision, such like ifs, loops, etc. Do it sparingly.
All applications must do the log using the default library of the company that to force the passage of relevant parameters just as it would already be in the adequate format.
Constemente analise se o codigo que voce esta escrevendo tem conexao com os outros codigos ja escritos. Tente manter tudo que faz sentido ficar junto, realmente proximo, Alguns exemplos da aplicacao dessa ideia:
- If you have a class that has a date attribute and you need to know if a certain object has a value before or after that date, you should create a method within that class to operate on the attribute.
- If you decided to create a new service, maximize the chance that each code of that service really has a connection to each other.
Deciding early on generalizations and reusable codes can cause you to extract something that is not actually reusable. Simply because you did not expect to have collected more variables of understanding about the problem that was being solved.
- Controllers 100% cohesive.
- Services 100% cohesive.
- UseCases 100% cohesive.
- Form/Request/DTO Value Objects