Ce billet fait partie d'une série en 4 volets : #1, #2, #3, #4.
Suite et fin de ma sélection de citations et de notes sur le livre Software engineering at Google.
Cette lecture m'a été inspirée par l'article An ex-Googler's guide to dev tools qui résume parfaitement le cycle de vie du développement logiciel :
- vous pensez à une fonctionnalité ou à un bogue
- vous lisez un tas de code, réalisez des documents de conception, posez des questions à vos collègues. Vous vous faites une idée du problème et de la façon dont la solution pourrait s'intégrer dans le système existant
- vous commencez à écrire du code et visez d'abord un résultat qui fonctionne a minima. Pendant cette étape, vous pouvez changer d'idée, consulter de la documentation, lire le code des autres etc. plusieurs fois
- vous arrivez à quelque chose qui fonctionne, mais vous n'êtes pas prêt à le déployer. Vous avez cassé certains tests, que vous réparez maintenant, vous ajoutez d'autres tests, vous refaites le code pour le rendre plus propre et plus facile à comprendre pour la prochaine personne. Vous le poussez dans une branche. Vous attendez que la CI passe, et peut-être que vous implémentez quelques corrections supplémentaires et de petites améliorations
- vous soumettez votre changement pour revue de code. Vos collègues laissent des commentaires. Vous apportez les modifications. Peut-être qu'il y a quelques séries de va-et-vient avant que le changement ne soit approuvé
- vous fusionnez votre changement et il est déployé
- les systèmes de surveillance détermineront s'il y a des problèmes de production. Si c'est votre changement qui a causé un incident, vous êtes tenu de le réparer
Le bouquin s'attache à décrire toutes ces étapes dans sa première partie. Dans sa seconde partie très longue que je ne résumerai pas, il détaille tous les outils internes utilisés par Google pour chaque étape de ce cycle de vie. Vous pouvez trouver des alternatives open-source.
Vous pouvez trouver aussi d'autres synthèses du livre :
- Review of "Software Engineering at Google"
- My Notes from Software Engineering at Google: Lessons Learned from Programming Over Time
Obsolescence
Chap. 15 Deprecation
Unlike with most of the other topics we have discussed in this book, Google is still learning how best to deprecate and remove software systems.
Gestion de versions et modèle de création de branche
Chap. 16 Version Control and Branch Management
Un système de gestion de versions est la clé permettant de faire grossir les équipes et les organisations.
Google utilise un logiciel de gestion de versions maison nommé Piper.
La cohérence a une importance énorme à tous les niveaux d'une organisation. Google utilise un monorepo, d'après eux si tous vos projets ont les mêmes exigences en matière de secret professionnel, de légalité, de confidentialité et de sécurité, un monorepo est une bonne solution.
Avoir une politique de création de branche simple permet d'obtenir de meilleurs résultats.
Recherche de code
Chap. 17 Code Search
Kythe est un outil de recherche de code développé par Google optimisé pour la lecture, la compréhension et l'exploration à grande échelle.
L'un des cas d'utilisation les plus fréquents de l'outil est de permettre de voir comment les autres font quelque chose.
Gestion des dépendances
Chap. 21 Dependency management
La gestion des bibliothèques et des paquets externes, sur lesquels nous n'avons pas le contrôle, est l'un des problèmes les moins compris et les plus difficiles à résoudre dans le domaine du génie logiciel :
- est-il sage de dépendre d'un code produit par une autre organisation ?
- quels sont les risques en matière de sécurité ?
- comment gérer un code extérieur, sa mise à jour, ses sous-dépendances dans le temps ?
L'économie de coût réalisée par l'import d'une dépendance externe n'est pas toujours le bon choix. Il faut considérer aussi son coût de maintenance sur la durée.
En amont d'un import de dépendance, les développeurs sont encouragés à se poser des questions :
- cette dépendance a-t-elle des tests ?
- est-ce que ces tests passent ?
- qui est l'auteur de la dépendance ?
- à quel niveau de compatibilité aspire la dépendance ?
- quelle est la popularité de la la dépendance ?
- combien de temps allons-nous en dépendre ?
- à quelle fréquence la dépendance fait-elle des changement cassant (breaking changes) dans son code ?
Et à considérer le problème du point de vue interne :
- serait-il compliqué de mettre en œuvre cette fonctionnalité en interne ?
- quelle sera notre motivation pour maintenir cette dépendance à jour ?
- qui effectuera la mise à jour ?
- quel est le niveau de difficulté de sa mise à jour ?
Voir Our Software Dependency Problem :
Software dependencies carry with them serious risks that are too often overlooked.
Il faut être conscients de l'impact du temps : tous les logiciels ont des bogues, certains d'entre eux seront critiques. Une partie de nos dépendances sera donc critique et il faudra la mettre à jour sur une période de temps probablement longue.
Intégration continue
Chap. 23 Continuous integration
l'intégration continue (continuous integration, CI) est une pratique de développement consistant à vérifier à chaque modification de code source que le résultat ne produit pas de régression.
L'objectif fondamental est de détecter automatiquement les changements problématiques le plus tôt possible.
Il est naturel de concevoir l'intégration continue en termes de tests car les deux sont étroitement liés.
Plus un bogue est découvert tard, plus son coût augmente presque exponentiellement. La technique de canarying (à la mine, le canari prévenait du coup de grisou) ou déployer d'abord pour un petit pourcentage d'utilisateurs peut aider à minimiser les risques lors d'une mise en production.
Livraison continue
Chap. 24 Continuous delivery
La livraison continue ou déploiement continu (continuous deployment, CD) est une pratique de développement qui consiste à construire les logiciels pour être capable de livrer des fonctionnalités à tout moment par le biais de déploiements automatisés.
La clé du succès de toute organisation est sa capacité à mettre en œuvre ses idées, puis à les mettre entre les mains des utilisateurs le plus rapidement possible pour réagir rapidement à leurs réactions.
User Feedback: the biggest risk to any software effort is that you end up building something that isn't useful.
Plus tôt et plus fréquemment vous mettez un logiciel dans les mains de ses utilisateurs, plus vite vous avez un retour sur sa valeur réelle.
L'un des principes fondamentaux de la livraison continue est que sur la durée, des petits lots de modifications se traduisent par une meilleure qualité.
One of our codebases, YouTube, is a large, monolithic Python application. The release process is laborious, with Build Cops, release managers, and other volunteers. […] There is also a 50-hour manual regression testing cycle run by a remote QA team on every release.
À propos de la qualité et des services centrés sur les usagers : ne conserver que ce qui est utilisé. Un effet secondaire malheureux de la plupart des cycles de développement est de rendre un logiciel obèse (bloated), notamment quand un produit a du succès.
Une procédure de livraison continue efficace a pour inconvénient d'amplifier ce problème.
Ça finit par poser des problèmes à l'équipe produit et même aux utilisateurs : coût par exemple en termes de lenteur ou de volume de téléchargement de données, même pour les fonctionnalités qui ne sont jamais utilisée. Pour les développeurs, ce coût se manifeste par des préparations du code (builds) plus lentes, des déploiements plus complexes, des bogues rares etc.
Surveillez le coût et la valeur de toute fonctionnalité déployée pour savoir si elle est toujours pertinente et si elle offre encore une valeur suffisante à vos utilisateurs.
Dans tous leurs produits logiciels, Google a constaté que, même si ça semble contre-intuitif, tout ce qui sort plus vite est plus sûr. Déployez tôt, souvent et par petits lots pour réduire les risques de chaque version et minimiser les temps de mise sur le marché.
Joint