Reviewing your own code can be a hard thing to do and no one writes perfect code every time on the first attempt. To avoid sending a PR with a code that isn't as good as I want it to be or that isn't according to my team's current practice, I'm developing some tactics to review my own code.

These tactics are still ideas in test and are a method that I'm developing thinking in my own qualities and problems. So, feel free to comment what other tactics you developed yourself to review your own code and ensure a better code quality.

1. Reproduce the problem / Test the design-prototype

The first thing that I do is to discover/reproduce the problem that I need to solve or to test the design/prototype for a feature, if you have one. With this first step you aim to know for sure what you're trying to solve or to implement.

During this step, you can also open a markdown or text file and write anything that you think you would need to know during the code process. On my case, I create a Vim function that calls a single work file where I write anything work related, but you can try to do something similar with any text editor.

2. Write the tests

Before you start to write the code, write any tests that you'll need to ensure that your code works. Even if you don't use a test suite or work on a TDD environment, you can write some series of steps to ensure that you code works and that it doesn't break any other feature.

On the company that I work right now, as a frontend developer, we don't have any tests. So, for this step, based on the data that I got from the first step, I write the steps to reproduce the error, adding some extra steps based on what I think could be impacted by the code that I'll need to write to solve the problem.

Even if you still don't know how to solve the problem and what it would impact, it's still important to write the tests before start coding, so you can have an idea on what you'll need to look for while coding. Also, you can come back and forth as you want to review the test that you wrote and ensure that they cover everything you are changing.

3. Solving the problem/ Implementing the feature

Write a code that solves the problem or implements the feature that you need to implement. Write it the way that you want to.

On this step you don't need to write the perfect code. You'll have time to review it later, make it better, to rewrite it on your companies' style or to use any library that you are forced to use by you companies' guide/colleagues (looking at you lodash).

4. Test the code

Test the code that you wrote using the test steps that you wrote and any test library/suite/framework that you use on your project.

5. Let the code rest a bit

With everything working, it is important to let the code rest a little.

On this step I try to stay away from code for at least 5 minutes, but not more than 15 minutes. I do this, because this isn't the only rest from code that I'll do during this self review steps. This is only a little rest to prepare for the next step.

6. Rewrite the code/solution

On this step you review the code that you wrote and rewrite it using the code style that you want or that you need to follow. You can also write any comments that you think the code need and any documentation that you need to write for you code.

7. Test you code again

After rewriting the code, you can test it again. But this time test every detail in every possible environment that you can think.

On the frontend side, I test my code on every possible browser and machine that we are supporting (we are dropping support for IE11 now, yeah!!!).

Try to test every edge case that you can imagine. Because the users will find that ones and some new more ways to create new bugs.

8. Commit your code, but don't create your PR yet

Commit you code and write a good commit message. I would advice to write not only the commit title, but a body too, explaining all your changes and how you tested it.

Commit messages are a live documentation that, if anything goes wrong, it can helps your team revert some bad code, understand what was happening on the code base on a specific time, and defends yourself if you need some backup when anything blows up on your companies' app(s). But don't create your PR yet, because this is the time for a longer rest.

9. Let the code rest for longer

This time you should let the code rest a while longer. You go tackle another ticket or do something else that takes more than one hour. The idea is that, when you return back to the original ticket, you had some more time to think about any edge cases that the test that you wrote before maybe doesn't cover, or any other style issue that you didn't remember on the first time you review you code.

10. Update your test and run everything again

At last, You can write any updates that you think the tests need and test everything again one extra time. If everything runs smoothly, the code is to ready be a PR and to be reviewed by the rest of the team.