Les petites équipes (2 à 5 développeurs) ont un super pouvoir : une communication rapide. Tout le monde sait ce que font les autres. L'architecture logicielle de ces équipes doit renforcer cette agilité et ne pas créer de bureaucratie.
Si vous avez une petite équipe, copier l’architecture de Google est un suicide. Vous avez besoin d’une architecture qui vous permet de créer de la valeur avec peu de personnes.
Sans serveur (le meilleur ami des petites équipes)
Le sans serveur (AWS Lambda, Google Cloud Functions) est l'architecture définitive pour les petites équipes.
- Zéro maintenance : il n'y a aucun serveur à mettre à jour, aucun système d'exploitation à corriger.
- Coût par utilisation : si personne ne l'utilise tôt le matin, vous ne payez rien.
- Échelle infinie : si 1 million de personnes y accèdent, le cloud augmente de 1 million de fonctions.
Votre équipe se concentre à 100 % sur l'écriture de la fonction ("requête de sauvegarde"), et à 0 % sur le fonctionnement du serveur.
Automatisation extrême (CI/CD)
Avec peu de personnes, vous ne pouvez pas avoir un « QA » (testeur) manuel qui clique sur tout avant le déploiement.
- Deploy Pipeline : chaque commit dans la branche
maindoit passer automatiquement en production après avoir réussi les tests. - Tests automatisés : écrivez des tests d'intégration (qui testent le fonctionnement de l'API) au lieu de trop vous concentrer sur des tests unitaires microscopiques. Testez ce qui compte pour l’utilisateur.
Documentation "Viva" (Code explicite)
Les petites équipes détestent rédiger de la documentation dans Word (qui est obsolète en 1 semaine).
- OpenAPI (Swagger) : utilisez des outils qui génèrent de la documentation API à partir du code.
- Type Hinting : utilisez TypeScript (si JS) ou Python Typing. Cela sert de documentation sur "ce que cette fonction s'attend à recevoir".
Évitez le « syndrome inventé ici »
N'écrivez pas votre propre système d'authentification. N'écrivez pas votre propre framework CSS.
- Utilisez Auth0 ou Firebase Auth.
- Utilisez Tailwind ou Bootstrap.
- Utilisez des bibliothèques standards.
Le code le plus évolutif est celui que vous n'avez pas eu à écrire (et que vous n'avez pas besoin de maintenir).
Conclusion
L'architecture pour les petites équipes est une question d'effet de levier. Utilisez le levier Cloud, le levier Open Source et le levier Automatisation pour effectuer le travail de 50 ingénieurs avec seulement 5. Réduisez la complexité incidente (infrastructure) au minimum.
A lire aussi
- Architecture logicielle évolutive - Meilleures pratiques de mise à l'échelle
- Architecture logicielle évolutive - Meilleures pratiques pour les startups
- Architecture logicielle évolutive : Comment créer des systèmes qui évoluent -Microservices dans les applications : architecture distribuée pour mobile
- Monolith vs Microservices : quelle architecture choisir -Architecture des applications - Meilleures pratiques pour les entreprises
