Skip to content

Instantly share code, notes, and snippets.

@ramonfsk
Last active October 30, 2024 15:21
Show Gist options
  • Save ramonfsk/2784ef906f734f2979a80fa940442708 to your computer and use it in GitHub Desktop.
Save ramonfsk/2784ef906f734f2979a80fa940442708 to your computer and use it in GitHub Desktop.

Metric and evaluate code complexity guided by CDD

Metric rules

  1. Conditionals (if, loops, ternary if): 1CP
  2. Aditional block of codes (try, catch, cases of switch, closures or lambdas): 1CP
  3. Coupling with specific project classes: 1CP

How to evaluate what was measured?

  • 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.

Guide to write automated tests

  1. Look for always 90% or more to coverage.
  2. Look for write the tests more integrated possbile.
  3. Stay always alert to time of execution.
  4. To coverage code, use MC/DC technique (modify condition, decision converage).
  5. Use Boundary Testing technique to explore th values of test.
  6. Try use property based testing to go beyond to tests derivaded of a way sistematic.
  7. Define a metric and a way to evaluate inspired by CDD to control the increase to complexity of test files.

Guide to log

When log and which level of severity use

  1. Always that have an update of state on system, do the log in info level before and after the realization.
  2. Always that consume external sevices, do the log in info level before and after of api call.
  3. 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.
  4. Do the log in debug level when to code have many ways of decision, such like ifs, loops, etc. Do it sparingly.

How do the log?

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.

Maximize the coesion of code

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:

  1. 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.
  2. If you decided to create a new service, maximize the chance that each code of that service really has a connection to each other.

Postpone to the maximum the generalizations and ideas of code reuse

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.

Patterns could be followed

  1. Controllers 100% cohesive.
  2. Services 100% cohesive.
  3. UseCases 100% cohesive.
  4. Form/Request/DTO Value Objects
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment