This week, I have brought our back-end Express code-base to strict, 100%, type-safety. This type-safety is also enforced using automated code linters, specifically eslint and prettier, which are automatically run after each commit. This enforces a standardized and readable code style, ensures that strict type-safety is maintained, and even catches common bugs such as misuse of “null-able” values before the code is even merged into master.
In a large enterprise context, such type-checking and automated linting is a vital part of the development process, as it ensures a consistent code style and enforces a common standard across all developers. Even within this project, with a team of 3, each of us may write code in very different ways. Using an automated linter therefore automatically and safely transforms the written code to conform to our standard, ensuring maximum developer productivity across all 3 of us.
A stretch goal would be to extend the linting process to require automated tests, and to execute these automated process as part of a Continuous Integration/Continuous Deployment (CI/CD) process with each commit and each merge. This is another standard operating practice in fast moving and agile enterprise environments. However, considering the scale and timeframe of our project, I do not see the need to enforce this level of rigor at this point in time.
I am currently on schedule and am well poised to deliver on the back end APIs. Next week, I will focus on delivering a key set of API endpoints that Alex can integrate into the front end.