Often while working you will be doing something that you have done before. You know exactly how to do it, the only thing different for you are the slight variations for this story. For example making a new endpoint that does some CRUD operation, or adding a DAO for yet another class
Consider writing a functional test
This policy recommends the writing of functional tests first. If you are an API that can be a pact given to you by one of your consumers, or faked up by yourself. If you are a website it could bea cucumber test or a selenium test.
Consider adding a feature flag
As we move towards continuous delivery we try and get our code into production ever quicker. A feature flag allows dark releases, eases Canary testing, and in general is good because it causes you to think a lot about the impact of your code
Look at similar code
If you have similar features (for example similar end points) don’t just cut and paste. Look at the existing code, and think about it. Work out if you could reuse large parts of it (i.e. you would benefit from cutting and pasting). If you do consider carefully whether to refactor before you add the new code (https://martinfowler.com/articles/preparatory-refactoring-example.html)
Write Unit Tests then make them pass
This is the Use Case that best supports TDD. We know what we are doing, so we can write unit tests easily and then make the code pass and then write more unit tests…
Consider if there is a security issue
Review the OWASP top ten list. Consider if you have data in a database that needs to be protected by cryptography or digests. Check if there is personal data anywhere. Check your logs (and make sure there are tests for logs) to ensure that no secrets are revealed. If you required any secrets for the story (passwords etc) make sure they are handled in accordance with company policy
Consider if you need a performance test for the new code
This is a case by case decision. Use your engineering judgement
Consider if you need a new End/End test
These should be avoided if possible. If you feel you need one, check if it is because you think you are missing some lower level tests, and then add those tests. A handful of End/End tests are acceptable, but these should not be used to avoid writing unit tests.
Review your own code
When you are happy that the code works you need to reflect upon it. Could you tidy it up? Does it have the correct levels of abstraction? Have you over simplified something? Have you made something over complicated? Does the code read as though you were explaining it to someone? Do you have any resource leaks?
Refactor at the end
At the end of the code, you must pause for reflection, review your code and work out how you are going to improve it. Reviewing it with a colleague is valuable for gaining insites at this stage. It is expected that you will do this before the final review
Have your code reviewed
Your company has a four eyes policy on code. This means that two people must review all code before it goes into production. This is a valuable process that not only checks security issues but is one of the main learning moments. It is entirely probably that refactoring will be needed after the code review based on the insites of the reviewer
#Links