4 Non-obvious Things to do When Starting a Project

In every project after T amount of time, we say ‘Aaah, how are we going to refactor all these codes now?’. It’s only natural to happen in the lifecycle of a project. We can’t prevent those moments from happening, but we can decrease them!

Logging

After some time, you’ll NEED a logging solution for your project. So, what you need to do when starting a project is to create a dummy logging service.

For starters, you can create something like this:

Small note: Be aware that a logging service like this might not be enough or beneficial to implement if you use a more sophisticated logging solution later.

For now, this service doing nothing but spitting console.logs and console.errors to the console. But it gets useful when you bind this service to a third-party logging solution later.

Implementing should be easier, even if the logging service that you created before is not enough or irrelevant to what you’ll be implementing. Since you log everything with this dummy service, you’ll know exactly what to log and what not to log, because you have already decided those things before.

Enforcing code standards

You wouldn’t believe how much time you are going to spend — especially if you work with a team — messing with nested if statements, nested ternaries, methods, functions & components with high cognitive complexity, etc.

So, you should set up SonarLint, eslint, and prettier right from the start. And, ideally, you should enforce these with husky and lint-staged. This way, you’ll filter out bad code more effectively.

Code Reviews

Enforcing code standards is not enough by itself to prevent bad code from entering your code base, you’ll need to do code reviews for eliminating other issues that can’t be caught by SonarLint, eslint, prettier, or a similar tool. We — especially on relatively early-stage start-ups — tend to not do code reviews at the start because not doing it is ‘faster’. Doing code reviews right from the start will put the team on the same page about architectural decisions, code standards &, etc. You’ll spend less time on refactoring later.

Abstracting third-party library methods

If you use third-party libraries, you tend to use them directly. It might be sweetalert2, it might be the quasar notify module, it might be a model validation library, and such. We need to separate these from implementations to keep the code base more maintainable.

For example, you can abstract the Quasar Notify module like this with TypeScript;

Usage like this has 3 — and probably more — benefits.

• You don’t need to import Notify every time you need to show a notification. Injecting the service above will be enough.
• Let’s say there’s been a breaking change in the Notify library. You won’t need to change every usage of Notify. You’ll need to change the implementation in this service, and you’re done.
• You can change the library for notification easily. If you want to use Noty instead of Quasar Notify, remove the quasar notify from this service, and implement Noty, you’re done.