6.3Best practices & pitfalls
The essentials in 30 seconds
- Golden rule: clean async, clear structure, systematic security — reliability pays, never raw speed.
- To do: async/await, MVC layers, compliant REST, bcrypt + .env, validation + tests, measure then deliver.
- To avoid: Sync on a server, spaghetti, plain-text secrets, trusting the client, neglected tests, blind optimisation.
Salim thread — three habits that pay
After one year, Salim takes stock: what counted most was not a framework but three habits — writing async/await without blocking the loop, validating every input, and delivering through to the end with tests and deployment. And his biggest pitfall narrowly avoided: a password stored in plain text during a week of rush.
Pick a single habit to anchor in your routine, then move to the next.
What makes the difference
The difference between fragile tinkering and professional practice is not the tools but the habits: writing clean async code, structuring, designing compliant APIs, securing, validating, testing and delivering.
✓ To do
- Write in async/await and never block the event loop.
- const by default, clearly-scoped modules, layered structure (MVC).
- Design compliant REST APIs (resources, methods, correct status codes).
- Hash passwords (bcrypt), protect secrets (environment variables), check authorisation.
- Validate every input, handle errors centrally, write tests (Jest).
- Measure before optimising; deliver through to the end (Docker, deployment, CI/CD).
✗ To avoid
- Stuffing a server with synchronous calls (fs.*Sync) that block the loop.
- Piling all the logic into routes (spaghetti) instead of layers.
- Storing a plain-text password or a secret in code/Git.
- Trusting client inputs (injection, corrupted data).
- Neglecting tests (“it works”) and leaving silent regressions.
- Optimising prematurely instead of measuring and targeting.
Ready-to-say script — checking your practice before delivering (30 s)
«Clean async with no Sync? Clear layers and compliant REST? Hashed passwords, secrets in .env, authorisation checked? Validated inputs, centralised errors, green tests? Measured before optimising? If any no, I fix before delivering.»
Copy-paste template — monthly self-check (6 questions)
// Self-check: answer yes / to improve, then act
const diagnostic = {
asynchronePropre: "yes / to improve",
couchesMVC: "yes / to improve",
restConforme: "yes / to improve",
securite: "bcrypt + .env + authorisation?",
validationTests: "Zod + errors + Jest?",
mesureLivraison: "measured + Docker + CI/CD?"
};
const maPrioriteDuMois = "...just one...";
module.exports = { diagnostic, maPrioriteDuMois };VSE / small budget
One habit per quarter is enough: clean async/await first, the rest next.
SME Algeria
Adapt routines to peaks and travel: one code-and-test review slot kept each week.
Remote / hybrid
The #1 discipline at a distance: written reviews and green tests, even for small fixes.
Intercultural
Check local practices rather than assume: an unusual authorisation rule should raise flags everywhere.
48h challenge — apply tomorrow
Fill in the monthly self-check above and choose a single priority to anchor (e.g. validate all inputs of your main route).
- I know the habits to apply and the pitfalls to avoid.
- I filled in the self-check and chose a priority.
- I did the 48h challenge or scheduled its date.
Before delivering, Salim checks his practice. Which reflex protects him best?
Golden rule: a good Node developer is not the one who codes fastest, but the one whose applications are reliable, safe, maintainable and actually delivered to production.