Souvent dans le processus de mise en œuvre des projets, les équipes sont confrontées à la question: à quoi doit-on accorder plus d'attention - la sortie de nouvelles fonctionnalités ou l'amélioration de la qualité du code? En règle générale, les gestionnaires optent pour des fonctionnalités. Souvent, les développeurs sont mécontents de cet état de fait, estimant qu'ils n'ont pas assez de temps pour travailler sur l'architecture et la qualité du code.
La
loi de Betterridge stipule: "Tout titre se
terminant par un point d'interrogation peut recevoir une réponse par le mot non." Ceux qui me connaissent personnellement savent que je ne partage pas cette pensée. Mais dans cet article, je veux aller encore plus loin et prouver que poser la question du titre de cet article n'a tout simplement pas de sens. Une telle formulation de la question suggère qu'il y a un compromis entre coût et qualité. Et vous devez constamment maintenir l'équilibre. Dans cet article, je prouverai que ce compromis n'est pas applicable au monde du développement de systèmes informatiques et, en fait, créer des logiciels de haute qualité est finalement moins cher.
Malgré le fait que le principal public cible de l'article soit les développeurs, il ne nécessite pas de connaissances particulières pour le comprendre. J'aimerais que cet article profite à tous ceux qui sont en quelque sorte liés au processus de développement, et en particulier aux gestionnaires qui forment le vecteur de développement de produits.
Nous avons l'habitude de choisir entre prix et qualité.
Comme je l'ai écrit plus tôt, lors du développement d'un logiciel, il faut constamment faire un choix entre la qualité du produit et les coûts de son développement. Lorsque vous achetez un nouveau smartphone, vous avez le choix. Payez plus d'argent et obtenez un processeur plus rapide, plus de mémoire et un écran amélioré, ou payez moins, mais sacrifiez certaines fonctionnalités. Il existe des exceptions à cette règle: parfois, un produit de meilleure qualité est moins cher. Et parfois, les gens ne peuvent même pas comparer objectivement deux produits et en choisir un meilleur. Par exemple, ils ne remarquent pas la différence entre les écrans réalisés avec des technologies complètement différentes. Cependant, l'énoncé «La qualité coûte plus cher» est généralement vrai.
La qualité du logiciel est très importante.
En parlant de qualité logicielle, vous devez commencer par définir des critères de qualité. Qu'est-ce qu'un logiciel de qualité? À partir de ce moment, les choses se compliquent un peu, car tout système informatique a de nombreux critères permettant d'évaluer sa qualité. Vous pouvez évaluer l'interface utilisateur et UX: à quelle vitesse et simple un utilisateur peut-il résoudre son problème? La fiabilité peut être évaluée: y a-t-il des bogues dans le programme qui conduisent à un comportement incorrect et instable? Un autre critère est l'architecture: dans quelle mesure le code source du programme est structuré, dans quelle mesure le programmeur peut-il trouver le code dont il a besoin en ce moment?
La liste ci-dessus des critères de qualité n'est bien sûr pas complète. Mais ces critères suffisent à montrer une chose importante. Certains critères par lesquels la qualité d'un programme est généralement évaluée ne sont même pas visibles pour les utilisateurs finaux. Les clients peuvent donner leur avis et dire dans quelle mesure le logiciel résout leurs problèmes commerciaux. Les utilisateurs peuvent se plaindre de l'interface peu pratique. Ou ils se plaindront de bogues, surtout s'ils entraînent une perte de données ou une indisponibilité prolongée du système. Mais les utilisateurs ne sont pas en mesure d'apprécier l'architecture et la qualité du code.
Par conséquent, je divise les critères de qualité en deux catégories:
externes (par exemple, UI / UX ou la présence de bugs) et
internes (architecture). Leur différence la plus importante est que les utilisateurs peuvent évaluer la qualité externe, mais ils ne peuvent pas comprendre à quel point l'architecture interne du système est bonne (ou mauvaise).
À première vue, la qualité interne n'a pas d'importance pour les utilisateurs (mais seulement au début)
Si les utilisateurs ne peuvent pas évaluer la qualité interne du logiciel, ce critère est-il important? Imaginons une situation hypothétique où deux équipes de développement, indépendamment l'une de l'autre, ont décidé de créer une application pour suivre et prévoir les retards de vol. Je gère une équipe et Rebecca mène la seconde. L'ensemble des fonctions de base pour les applications est à peu près le même, l'interface pour les deux applications s'est également avérée très pratique et réfléchie, il n'y a pas de bogues critiques dans les applications. La seule différence est que le code source de l'application de Rebecca est clairement structuré et organisé, et le code créé par mon équipe est un ensemble désordonné de classes et de méthodes avec des noms obscurs et une logique encore plus obscure de la façon dont ce code est interconnecté. Il y a une autre différence: je vends mon application pour 6 $, et Rebecca vend presque la même application pour 10 $.
Étant donné que le code source des applications est inaccessible aux utilisateurs et que la qualité du code n'affecte pas l'expérience utilisateur, pourquoi les utilisateurs devraient-ils payer un supplément de 4 $? En d'autres termes - pourquoi surpayer la qualité interne, ce qui n'a pas d'importance pour les utilisateurs?
Si vous développez cette idée encore plus loin, vous pouvez arriver à la conclusion qu'investir dans la qualité externe est plus rentable qu'en interne. En faisant un choix entre deux applications, l'utilisateur peut choisir celle qui est la plus chère s'il dispose d'une interface meilleure et plus pratique. Mais les utilisateurs ne voient pas la structure interne des applications, sans parler du fait que l'utilisateur peut comparer l'architecture des deux applications. Alors, pourquoi payer plus pour quelque chose qui n'apporte pas d'avantages pratiques? Et pourquoi les développeurs devraient-ils consacrer du temps et des ressources à l'amélioration de la qualité interne de leurs programmes?
Les programmes de haute qualité interne sont plus faciles à étendre
Pourquoi est-il si important pour les programmeurs d'avoir un code de qualité? Les programmeurs passent la plupart de leur temps à le lire et à le modifier. Même lors du développement d'un nouveau système, le travail est presque toujours effectué dans le contexte d'un code déjà écrit. Lorsqu'un programmeur ajoute une nouvelle fonctionnalité, il doit d'abord comprendre comment cette fonctionnalité s'intègre dans l'architecture d'application existante. Ensuite, vous devez souvent apporter des modifications à l'architecture afin qu'une nouvelle fonctionnalité puisse être implémentée. Vous devez souvent utiliser des structures de données qui sont déjà dans le système. Par conséquent, vous devez comprendre que ces structures de données signifient quel type de relations existent entre elles et quelles nouvelles structures de données doivent être ajoutées pour implémenter les fonctionnalités.
Un code de haute qualité permet aux programmeurs de le parcourir rapidement. Atteindre une situation où le code devient difficile à comprendre est en fait très simple. Les conditions logiques peuvent être entrelacées; les relations entre les structures de données peuvent être complexes et implicites. Les noms que Tony a donnés aux variables et aux fonctions il y a 6 mois étaient peut-être clairs pour lui, mais aussi incompréhensibles pour le nouveau développeur, ainsi que les motifs qui ont poussé Tony à quitter l'entreprise. Les développeurs appellent généralement cette
«dette technique» (
dette technique ), ou en d'autres termes, la différence entre l'état actuel du code et l'état idéal dans lequel il peut se trouver.
L'un des principaux avantages de la haute qualité du code est que le programmeur peut comprendre rapidement comment fonctionne le système et effectuer les modifications nécessaires. Lorsque l'application est divisée en modules, le programmeur n'a pas besoin d'étudier les 500 000 lignes de code source et il peut trouver rapidement les centaines de lignes dont il a besoin pour le moment. Lorsque les programmeurs donnent des noms significatifs aux variables, aux fonctions et aux classes, vous pouvez facilement comprendre ce que fait chaque morceau de code individuel sans avoir à plonger profondément dans le contexte. Si les structures de données du programme coïncident avec la terminologie du domaine de l'entreprise, il est facile pour le programmeur de corréler la demande de nouvelles fonctionnalités avec le fonctionnement du système. La dette technique augmente également le temps nécessaire pour travailler avec le code. La probabilité de faire des erreurs augmente également. En cas de bugs dus à la mauvaise qualité du code, un délai supplémentaire sera nécessaire pour localiser le problème et le corriger. Et si le bogue n'est pas immédiatement remarqué, cela entraînera des problèmes dans le code de production et le fait que vous devrez passer encore plus de temps à résoudre ces problèmes à l'avenir.
Chaque modification du code affecte l'avenir du produit. Il y a souvent une situation où il existe un moyen simple et rapide de mettre en œuvre une nouvelle fonctionnalité, mais au prix de casser l'architecture actuelle (c'est-à-dire en raison d'une augmentation de la dette technique). Si un programmeur choisit ce chemin, il libère sa fonctionnalité plus rapidement, mais ralentit le travail des autres développeurs qui devront prendre en charge ce code plus tard. Si tout le monde dans l'équipe le fait, même une application bien conçue avec un bon code se transformera rapidement en dettes techniques, et même quelques changements prendront plusieurs semaines.
Les utilisateurs souhaitent obtenir de nouvelles fonctionnalités le plus rapidement possible.
Nous approchons d'un point important, à savoir: pour répondre à la question, pourquoi la qualité interne des logiciels est-elle toujours importante pour les utilisateurs? Une qualité interne élevée favorise la publication plus rapide de nouvelles fonctionnalités, car elles sont plus faciles, plus rapides et moins coûteuses à faire. Mes applications avec Rebecca sont maintenant presque les mêmes, mais après quelques mois, le code de haute qualité de Rebecca lui permettra de publier une nouvelle fonctionnalité chaque semaine, et je serai bloqué, essayant de faire face à la dette technique et essayant de lancer au moins une nouvelle fonctionnalité. Je ne pourrai pas rivaliser avec Rebecca en termes de vitesse de développement, et son application dépassera rapidement la mienne en termes de fonctionnalité. En fin de compte, les utilisateurs supprimeront mon application et utiliseront l'application Rebecca, même si cela coûte plus cher.
Visualisation de l'influence de la qualité interne
Le principal avantage de la haute qualité interne du programme est la réduction du coût des changements futurs. Mais l'écriture de code de haute qualité nécessite plus d'efforts, ce qui augmente les ressources nécessaires à court terme.
Le graphique ci-dessous montre schématiquement comment vous pouvez imaginer le ratio de fonctionnalités et le temps nécessaire pour les développer. En règle générale, une courbe ressemble à ceci:
Voici à quoi ressemble le processus de développement lorsque le code n'est pas de très haute qualité. Au début, le développement est assez rapide, mais il faut de plus en plus de temps pour étendre davantage la fonctionnalité. À un certain moment, afin de faire même un petit changement, le programmeur doit d'abord apprendre beaucoup de code complexe et déroutant. Une fois la modification effectuée, il est découvert que quelque chose s'est cassé, ce qui entraîne un temps supplémentaire consacré au test et à la correction des erreurs.
Une qualité interne élevée contribue à l'efficacité du développement à des stades ultérieurs. Certaines équipes parviennent même à obtenir l'effet inverse, lorsque chaque nouvelle fonctionnalité est publiée plus rapidement que la précédente du fait qu'il est possible de réutiliser du code déjà écrit. Mais cela arrive rarement, car cela nécessite une équipe hautement professionnelle avec une bonne organisation du travail. Mais parfois, cela se produit encore.
Cependant, il y a une astuce. Dans les premiers stades de développement, ignorer la qualité du code est plus efficace que de suivre des normes élevées. Mais quand cette période se termine-t-elle?
Pour répondre à cette question, vous devez d'abord préciser que les images représentent des
pseudographies . Il n'y a pas de véritable moyen d'évaluer la performance d'une équipe. Il n'est pas facile de comprendre comment un mauvais code affecte la qualité finale du produit (et si cette corrélation existe, à quel point elle est prononcée). Soit dit en passant, ce problème est pertinent non seulement pour l'industrie informatique. Comment, par exemple, évaluer la qualité du travail d'un avocat ou d'un médecin?
Mais revenons à la question, à quel point cela vaut-il la peine de commencer à réfléchir à la qualité du code. Les développeurs expérimentés pensent que la mauvaise qualité du code commence à ralentir quelques semaines après le début du projet. À un stade précoce du projet, la beauté de l'architecture et du code peut être ignorée.
De plus, d'après ma propre expérience, je peux dire que même les petits projets obtiennent un sérieux avantage concurrentiel s'ils utilisent des pratiques de développement modernes et efficaces dans leur travail et pensent à la qualité du code.
Même les meilleures équipes écrivent parfois du mauvais code
Les nouveaux venus dans le processus de développement pensent qu'un mauvais code indique que l'équipe ne fonctionne pas bien. Mais, comme le montre la pratique, même les équipes les plus expérimentées font parfois des erreurs et écrivent du mauvais code.
Pour le démontrer clairement, je veux vous parler d'une conversation avec l'un de nos meilleurs chefs d'équipe. À ce moment, il venait de terminer de travailler sur un projet que tout le monde considérait comme très réussi. Le client était ravi du nouveau système, tant par les nouvelles fonctionnalités que par les ressources consacrées à son développement. L'équipe était également satisfaite du projet terminé. Le chef technique de l'équipe était également très satisfait du résultat, mais a admis qu'en fait l'architecture du système n'était pas aussi réussie. Je lui ai demandé: "Mais comment se fait-il que vous soyez l'un de nos meilleurs architectes?" Il a répondu comme n'importe quel architecte expérimenté aurait répondu: «Nous avons pris de bonnes décisions, mais seulement maintenant nous savons comment le faire correctement.»
Beaucoup de gens comparent la création de systèmes complexes avec la conception de gratte-ciel. Apparemment, c'est pourquoi les développeurs expérimentés sont appelés «architectes». Mais dans le processus de création de logiciels, il y a toujours une certaine incertitude, peu caractéristique des autres domaines d'activité, dans laquelle les incertitudes sont bien moindres. Les clients typiques ont une mauvaise compréhension de ce qu'ils veulent du programme et ne commencent à le comprendre que dans le processus de travail. Le plus souvent, au moment où on leur montre les premières versions du programme. Les éléments à partir desquels les programmes sont créés (langages de programmation, bibliothèques, plates-formes) changent régulièrement. En faisant une analogie avec la construction d'un gratte-ciel, pouvez-vous imaginer une situation où le client demande à l'architecte d'ajouter une douzaine d'étages supplémentaires et de modifier la disposition des étages inférieurs, malgré le fait que la moitié du bâtiment est déjà construite? La situation devient encore plus compliquée lorsqu'il s'avère que les technologies utilisées pour la production de béton, ses propriétés physiques et ses caractéristiques sont mises à jour tous les 2 ans.
Face à de nouveaux défis constants, à l'augmentation de leur nombre et de leur complexité, les équipes doivent constamment proposer quelque chose de nouveau. De plus en plus, il est nécessaire de résoudre des problèmes que personne n'a jamais résolus auparavant et, par conséquent, il n'y a pas de solution connue et éprouvée pour eux. Habituellement, une compréhension claire du problème ne vient qu'au moment de sa solution, donc j'entends souvent l'opinion que la compréhension de l'architecture d'un système complexe survient au moins un an après le début des travaux. Et même l'équipe de développement la plus professionnelle du monde ne pourra pas rendre le système parfait.
Une équipe professionnelle et organisée diffère d'une équipe moins organisée en ce sens que dans le processus de travail sur le système, elle crée moins de dette technique et se débarrasse également de la dette existante. Cela aide le projet à se développer rapidement et à publier de nouvelles fonctionnalités le plus rapidement possible. Une telle équipe investit dans la création de tests automatisés, ce qui permet d'identifier les problèmes plus rapidement et de passer moins de temps à rechercher et à corriger les bogues. Les membres d'une telle équipe travaillent constamment pour maintenir un code de haute qualité et se débarrasser rapidement du mauvais code jusqu'à ce qu'il commence à entraver la progression. Les systèmes CI y contribuent également, en particulier dans une situation où de nombreuses personnes travaillent simultanément sur différentes tâches. Comme métaphore, vous pouvez apporter dans la cuisine après la cuisson. Il est impossible de cuisiner quelque chose sans salir la table, la vaisselle et les autres ustensiles de cuisine. Si vous ne les nettoyez pas immédiatement, la saleté se dessèchera et il sera alors beaucoup plus difficile de la laver. Et la prochaine fois que vous voudrez cuisiner quelque chose, ce sera beaucoup plus difficile pour vous de le faire car vous devez d'abord laver la montagne de vaisselle.
Recherche et évaluation DevOps (DORA)
Le compromis entre coût et qualité n'est pas le seul dans le monde du développement logiciel qui semble simple à première vue, mais dans la pratique, tout se révèle un peu plus compliqué. Il y a également une large discussion sur ce qu'il vaut mieux choisir - des taux de développement et de sortie rapides, ou des taux plus lents et des tests rigoureux. On pense que l'utilisation de la seconde approche permet d'obtenir une stabilité plus élevée des systèmes de production. Cependant, l'étude
DORA a prouvé que ce n'est pas le cas.
Après avoir collecté des statistiques sur plusieurs années, les chercheurs ont identifié les pratiques qui contribuent à une meilleure performance de l'équipe. Il s'est avéré que les équipes les plus efficaces mettent à jour le serveur de production plusieurs fois par jour, et la libération du code à partir du moment où il est écrit pour la publication ne prend pas plus d'une heure. Le fait de suivre cette approche vous permet d'annuler les modifications apportées aux petites pièces et de réduire la probabilité de dommages graves. Les équipes qui font des sorties moins souvent, selon les statistiques, sont confrontées à de nombreux problèmes graves. De plus, les équipes habituées à un rythme élevé peuvent récupérer plus rapidement après un crash. Des études ont également montré que dans ces équipes, les processus sont généralement mieux alignés et fonctionnent de manière plus organisée.
La prise en charge des systèmes avec une bonne architecture est moins chère
Les points les plus importants de ce dont nous avons parlé ci-dessus:
- Le manque d'attention à la qualité du code conduit à l'accumulation de dettes techniques
- La dette technique ralentit le développement du système
- Même les équipes professionnelles prennent parfois de mauvaises décisions. Mais l'application des pratiques modernes et le "remboursement" périodique de la dette technique vous permettent de la maîtriser
- Le maintien d'un niveau élevé de qualité du code minimise la dette technique. Cela permet de se concentrer sur de nouvelles fonctionnalités et de les publier avec moins d'effort, plus rapidement et moins cher.
Malheureusement, il est généralement difficile pour les développeurs d'expliquer cela à la direction. J'entends souvent des plaintes selon lesquelles le manuel ne permet pas de maintenir un code de haute qualité en limitant le temps alloué au travail sur les tâches. Lorsqu'ils répondent à des questions de gestion, pourquoi dépenser des ressources supplémentaires pour la beauté du code, les développeurs répondent généralement qu'il s'agit d'un indicateur de professionnalisme élevé. Mais utiliser uniquement cet argument implique que des ressources supplémentaires sont dépensées pour maintenir une qualité élevée, qui pourrait être utilisée pour d'autres tâches. Et cela sape l'argument du professionnalisme lui-même. La vérité est qu'en raison d'une architecture de mauvaise qualité et d'un code médiocre, la vie devient plus difficile pour tout le monde: il est plus difficile pour les développeurs de travailler avec elle, et pour les clients, cela coûte plus cher. Lorsque je discute de la qualité du code avec la direction, j'insiste pour qu'il soit considéré uniquement comme un indicateur économique. Si le programme à l'intérieur est fait avec une haute qualité, il sera plus facile et moins cher d'y ajouter de nouvelles fonctionnalités. Cela signifie que l'investissement dans l'écriture de code de qualité réduit en fin de compte les coûts de développement globaux.
C'est la vraie raison pour laquelle la question du titre de l'article n'a tout simplement pas de sens. Dépenser des ressources supplémentaires pour l'architecture et le bon code, d'un point de vue économique, au final, est plus rentable. , , , . , . ( ). , .
. :
, , . – . . , . .