Facile à maintenir

Nous veillons à ce que la structure des dossiers soit la première chose qu'un futur développeur jugera. Des structures de dossiers cohérentes et opinionnées sont utilisées (par exemple, src/components, src/services, src/hooks, src/features).

Nous écrivons du code pour les humains, pas seulement pour le compilateur. Des conventions de nommage et des modèles cohérents sont suivis dans tous les projets. ESLint et Prettier sont configurés pour appliquer le formatage via des hooks pré-commit comme Husky, garantissant la qualité du code dès le départ. Nous privilégions les langages typés, utilisant TypeScript plutôt que JavaScript pour une meilleure maintenabilité. Nous veillons toujours à ce que le code soit lisible et gérable, concentré et petit.

Nous évitons le chaos du design en encodant les décisions de design dans des composants de code réutilisables. Des systèmes de composants établis comme ShadCN, Tailwind UI ou Material UI sont utilisés pour garantir la cohérence à travers les projets. Cette approche aide à éviter d'écrire du code UI unique sauf si absolument nécessaire, économisant du temps et garantissant la cohérence du design.

Nous veillons à ce que la logique métier n'appartienne jamais à la couche UI. Des couches de service, des hooks personnalisés ou des modules de contrôleur sont utilisés pour isoler et organiser correctement la logique métier. Pour les interactions API, des modèles modernes de récupération de données sont mis en œuvre en utilisant SWR, React Query ou des wrappers personnalisés qui gèrent efficacement la mise en cache et les états d'erreur. Tous les appels API sont abstraits dans des dossiers de service dédiés, tels que services/api/user.ts, rendant la base de code plus maintenable et testable.

Nous n'écrivons pas de romans—juste assez pour intégrer rapidement le prochain développeur. README.md est toujours rédigé avec la configuration, les variables d'environnement, les instructions de déploiement. Des commentaires courts sont ajoutés pour la logique complexe (ne pas trop commenter). TSDoc / JSDoc sont utilisés pour les méthodes publiques. Un CONTRIBUTING.md est ajouté pour expliquer comment exécuter des tests / conventions.

Nous n'avons pas besoin de 100 % de couverture, mais nous avons besoin d'une couverture complète là où l'échec est coûteux. Les tests unitaires sont prioritaires pour les fonctions critiques pour l'entreprise. Des tests d'intégration sont utilisés pour les points de terminaison API ou les flux de travail. Des outils faciles à utiliser sont choisis : Jest + Testing Library (React), Playwright pour e2e. Ainsi, nous pouvons maintenir un équilibre entre la couverture et le temps de mise sur le marché.

Chaque commit déclenche des vérifications de sécurité. Un pipeline CI/CD simple est mis en place qui effectue : des vérifications de type (par exemple, tsc --noEmit), des vérifications de lint/format, des tests unitaires, un déploiement automatique vers la mise en scène. Des outils communs sont utilisés : GitHub Actions, Docker Compose.

Nous évitons de coder en dur quoi que ce soit = douleur à long terme. Tous les secrets/configurations sont stockés dans .env ou une configuration distante (par exemple, AWS SSM, environnements Vercel). Une configuration basée sur l'environnement est utilisée (process.env.NODE_ENV). L'engagement de .env.*, des clés API, des identifiants, etc. est évité. Et ils sont bien documentés.