Disclaimer: This is an opinionated guide. Decide what works for you and your team and stick with those policies.
Let’s discuss these practices one by one.
Testing, Typescript and Linting.
That’s it! There I have said it. Test your WIP (Work In Progress) as much and strictly as you can. If your code is test passed, you are almost there. Do not bypass your work from the testing. Yes, I know you have already heard it like zillionth time but let me write the tools for testing for you.
It is a powerful tool for Integration testing. Unit tests on their own don’t guarantee that your app will work even if those tests pass because the relationship between the units might be wrong. You should test different features with integration tests.
Cypress is an end-to-end testing tool. It enables you to write unit tests and integration tests too. These tests are usually run on the entire application.
"Fast, easy and reliable testing for anything that runs in a browser.”
Your test passed codebase can still be a pain for the other developers. If a codebase does not follow strict coding standard guidelines — it will directly impact its scalability. Scalable code is as important as bug-free and tested code. ESLint lets you put uniform, standard coding guidelines. The project should follow one and only one standard protocol. For more details, please check my blog on ESLint.
While Typescripting, Testing and Linting cover the major part following are few other practices that you can follow:
With the npm, you have thousands of third party libraries at your hand that you can use. But you should be cautious of the third parties you are adding to your project. In general, the more third parties you add, the more control you lose over your project, the bulkier it gets. Here are few rules to help you out.
- Check how often the dependency gets updated or maintained. You can visit the Github repository and check the open issues and the recent activities.
- You can check the weekly downloads. It gives you a brief idea about the popularity of that dependency.
- Make sure the dependency you are adding is backed by the authentic contributor(s).
- You should also consider checking the unpacked size, last published date.
It is needless to say. You should set up the CI/CD that runs all the test cases, lint scripts. Feel free to set up the lenient CI/CD if you want bugs to enter in your production. Consider using Github actions or CircleCI. Every time someone merges or pushes their changes into the main branch there should be an action that runs all the test scenarios and lint scripts beforehand.
Do you think your piece of code requires commenting for better understanding? Chances are, you are right. Write comments when and where it is necessary. However, you should consider few important things:
- Update your comment(s) when required.
- Feel free to mention Tickets ID for reference in the comment.
- Do not write unnecessary comments. For example:
// assigning 10 to the x
let x = 10;
They say that the first rule of programming is,
“dOn’T tOuCh If iT’s wOrKiNG!”
I don’t want to sound rude but, I do not believe this. I believe — improve it if it can be improved. Optimize if it can be optimised. With the luxury of having a version control system, I wouldn’t even mind experimenting with it. You should consider your codebase refactoring every once in a while. Monthly if not weekly.
Feel free to connect with me, I’d love to hear from you! Thanks for reading.