Passons en revue les méthodes de création de logiciels inventées en environ 70 ans d'existence. Il n'y en a pas autant qu'il y paraît. Mais assez pour être perplexe.
Adage
L'homme est adaptatif par nature. Vous allez, par exemple, à la cuisine, où le poulet tourne sur le gril. L'odeur atteint le nez, et si vous avez faim, vous allez même saliver. Après environ cinq minutes, vous arrêtez de sentir. La seule chose qui rappelle la nourriture est un morceau de viande qui tourne derrière la vitre du four avec les ailes déployées. L'odeur est toujours là, vous pouvez la mesurer, mais les informations des récepteurs sont bloquées par le cerveau.
Cela se produit partout et le génie logiciel ne fait pas exception. Nous commençons par de «merveilleuses découvertes» que «l'esprit de l'illumination nous prépare», passons en douceur à la routine, à la honte et à la mêlée, aux sprints-shmints, à l'encapsulation-polymorphisme-nationalité, et, oh merde, un morceau de viande est tourner dans le four, menaçant de brûler jusqu'à terme, malgré une stimulation matérielle régulière au-dessus de la moyenne de l'hôpital.
Dans les années 1960, un homme curieux du nom de Richard B. Doss a découvert qu'en Amérique, saturée de bourreaux de travail protestants, 70 à 80% des gens travaillent bien en deçà de leur capacité de travailler. De plus, contrairement à un manipulateur robotique, un travailleur de la protéine est capable de le couper rapidement. Les études ont été répétées en «zéro» et «dixièmes» avec le même résultat. Une telle situation affecte la santé, pour le moins dire, ce n'est pas grave.
Le but du texte n'est pas de vous dissuader d'une productivité insuffisante ou de vous donner des conseils. Nous ne reviendrons que brièvement sur les méthodes de création de logiciels inventées en environ 70 ans d'existence.
Trois façons
Je ne vais pas tirer sur le caoutchouc, je vais commencer par l'essentiel. Il n'y a que trois façons de développer un logiciel. Oui, trois est un bon nombre, magnifique. Donc:
méthode descendante . C'est à ce moment-là qu'ils pensent globalement «quoi faire», puis «comment le faire», et ensuite ils le font, s'il reste du temps.
Voie ascendante . C'est à ce moment-là qu'ils le font pour la première fois, petit à petit, en petites parties. Ils ne pensent «quoi, oui comment» que sur cette partie, sans se soucier du global et durable.
Chemin en spirale . Nous commençons à penser globalement, mais lorsque l'alarme sonne, nous nous réveillons et déployons le prototype. Et ainsi plusieurs fois, en accumulant de l'expérience, jusqu'à ce qu'une solution apparaisse en fonction des besoins.
Développement descendant
Dans le langage courant, toutes les méthodes descendantes sont appelées «chutes d'eau». Si l'on vous a déjà parlé de l'existence de plusieurs morceaux d'ajiles, alors une telle «simplicité est pire que le vol» devrait éveiller les soupçons.
La descente de la méthode vers les masses se produit dans les années 1960, complétant organiquement les exigences de la programmation structurée pour se laver les mains avant de manger et d'utiliser des couverts et des serviettes. La tâche globale a été divisée en sous-tâches plus petites, qui, à leur tour, en tâches encore plus détaillées, et ainsi de suite jusqu'au niveau d'un bloc structurel qui peut être directement implémenté dans un langage de programmation. Au fait, les tests pour ces blocs sont écrits en parallèle, bonjour aux TDD des années 1960.
Le proverbe russe «Mesurer sept fois - couper une fois» est à peu près la méthode descendante.
Dans la version orthodoxe de la "cascade", les retours du client ne viennent qu'après la livraison. Nous avons travaillé pendant un an, sorti le piano des buissons, il s'est avéré "pas tout à fait correct", quelques finitions sont nécessaires. Pendant ce temps, le client a donné naissance à une longue liste de nouvelles fonctionnalités. Pas habitué à travailler dans un tel schéma est un peu stupide. Par conséquent, dans une version humaine, il est possible de revenir à l'étape précédente pour clarifier à partir de n'importe quel point, aboutissant à une "cascade avec retours".
Les avantages de la méthode sont évidents. Plus on réfléchit au début, moins il faudra faire de travail inutile au milieu et à la fin. La réinvention multiple des vélos, la duplication des fonctions et les erreurs sont exclues.
Cependant, s'il y a beaucoup de fonctions au départ, il n'est pas facile de donner naissance à la bonne ventilation. Nous avons besoin de bons analystes, de concepteurs ayant une expérience dans ces domaines. Et même dans ce cas, il existe un risque de retarder la planification de la mise en œuvre pour une période indécente.
Dans le futur, la méthode a été améliorée à plusieurs reprises, par exemple la méthode V , où les étapes de développement le long de la pente gauche de la lettre «V» correspondent aux étapes de tests et d'acceptation de l'ascension à droite. Le niveau horizontal montre immédiatement quel document de projet de l'entrepreneur sert de base au document d'acceptation du client.
Il est clair que les améliorations ne peuvent pas surmonter les limites fondamentales de la méthode. C'est pourquoi ils ont des principes. Cela ne veut pas dire que la méthode est mauvaise. Il a juste des risques de ce type. Si vous pouvez repousser les risques, alors tout va bien, nous commençons à réfléchir et à profiter des avantages en cours de route.
Développement en amont
En fait, la méthode ascendante est encore plus ancienne que la méthode descendante. Dans les années 1950, le Fortran et le Cobol existaient déjà, mais il n'y avait aucune idée claire de la manière de créer un logiciel. Par conséquent, nous avons agi de la manière la plus naturelle: aujourd'hui nous ferons une chose, demain une autre, puis un jour nous la collons dans une troisième. Si vous avez besoin de mettre en œuvre plusieurs tâches, nous sélectionnons les plus importantes.
Parfois, la méthode est également appelée incrémentale, apparemment par analogie avec
i++
. Ajout d'une fonction - incrément. Si vous souhaitez étirer le globe sur la projection Mercator, vous pouvez également appeler la méthode en spirale incrémentielle, mais nous en reparlerons plus tard. Ils aiment aussi dépeindre la méthode sous la forme d'un cycle, bien que pour
i++
les valeurs finales ne sont pas définies, vous devrez donc "creuser" d'ici jusqu'à l'heure du déjeuner. Poursuivant le thème des proverbes russes, nous avons un dicton «tourne comme un écureuil dans une roue» - il s'agit simplement de la méthode ascendante.
La technique était et reste la plus typique pour le développement en interne. Leurs programmeurs doivent faire ce dont l'entreprise a besoin hier. Pour penser plus globalement, les années 1960 ont vu l' émergence de «maisons de logiciels» - de grands bureaux d'études pour le développement de systèmes personnalisés, y compris des monstres comme IBM .
Toute cette construction logicielle ascendante s'est poursuivie sans changements significatifs jusqu'aux années 1990. La bataille principale pour faire correspondre les théories académiques à la pratique de l'ingénierie a contourné le refuge parce qu'elle s'est déroulée dans la jungle des méthodes descendantes et en spirale.
Dans les années 90, il y avait une forte tendance à remplacer les programmeurs «à la maison» par des consultants externes. L'une des raisons est la complication des technologies et de la spécialisation, ce qui est difficile à réaliser au sein de l'entreprise pour laquelle le génie logiciel est une activité secondaire. Le logiciel pour la maison est maintenant développé par des équipes temporaires
Dans une telle situation, une méthode simple fonction par fonction semble à nouveau appropriée. Mais travailler avec un entrepreneur à la journée demande plus de supervision que les salariés à temps plein. L'approche doit être adaptée, en évitant les procédures bureaucratiques. En effet, pour "délivrer le mandat", il faut une planification générale et des documents pertinents, c'est-à-dire des vollensnolens, il faudrait passer à des méthodes formelles descendantes ou en spirale. Et pourquoi une entreprise de transport ou un constructeur automobile en a-t-il besoin, par exemple? Les gens veulent simplement résoudre un petit problème interne, y calculer le salaire ou réduire le calendrier des vacances.
La demande crée l'offre, à la fin des années 1990, les méthodes dites agiles sont apparues, à tout le moins, ont permis au client de garder le doigt sur le pouls, et l'entrepreneur a progressivement compris ce qu'il mettait en fait en œuvre.
Ce qui est amélioré:
- la planification est encore courte, mais elle couvre plus d'une fonction, et leur groupe, tandis que la durée de l'étape est strictement limitée;
- un enregistrement de ce qui a été fait est conservé;
- théoriquement, du temps devrait être alloué pour simplifier et nettoyer le code (refactoring);
- en théorie, les risques de régression doivent être contrés par des tests complets.
Pourquoi est-ce que j'écris «théoriquement»? En pratique, lorsque le budget est limité ou en difficulté dans le temps, ces deux points sont sacrifiés en premier lieu. La "vache sacrée" dans ajiles n'est pas la qualité du code, comme les auteurs l'ont voulu, mais la date limite pour la fonction suivante.
Duplication de code, des complications inutiles, des implémentations inefficaces reportées «pour plus tard» - si vous ne nettoyez pas ce qui a été fait auparavant, la dette technique augmente. Plus la dette est remboursée tard, plus vous devez payer à la fin: temps, jours-homme, erreurs, échecs, lenteur de travail, etc.
Après 10 à 15 ans, les auteurs du "Manifeste d'Ajaila" ont commencé à tirer la sonnette d'alarme: "Les gars, que faites-vous, nous voulions autre chose." Ils sont quelque peu corrects, le développement ascendant est si simple et si convaincant que toutes ces procédures supplémentaires semblent inutiles.
Résumons ce qui est bon dans le développement ascendant. Tout d'abord, le seuil d'entrée est fortement réduit. Partir de zéro ne nécessite pas de coûteux experts en analyse et en conception expérimentés. Bien que toute la construction puisse durer indéfiniment, les premières casernes seront bientôt érigées et vous pouvez commencer à vous y installer. Il est plus facile de gérer le processus, les points de contrôle et les objectifs locaux sont transparents.
Les problèmes, comme dans le cas des «chutes d'eau», sont fondamentaux. Il est plus facile de gérer le processus, mais presque impossible - le résultat final, car il n'est clairement enregistré nulle part. Les risques sont répercutés sur le client: laissez le product owner penser qu'il a une grosse tête. Si l'équipe fait face à l'architecture technique avec l'expérience, les tests et la refactorisation (jusqu'à un certain seuil de complexité), alors l'architecture fonctionnelle est mauvaise. La simplification de l'énoncé du problème, le «refactoring» même, maintenant le modèle de domaine, aiderait à se débarrasser du code sophistiqué et coûteux à maintenir, mais il n'y a personne pour le faire. Et il n'y a pas de modèle, pour être honnête, toute la sémantique est dans les têtes et dans le code.
Mais il n'y a aucune raison d'être bouleversé, rappelez-vous du sprint le plus désastreux de l'histoire du monde: 5 jours de création et un milliard et demi d'années de refactoring continu.
Ingénierie en spirale
Les limites de la «cascade» susmentionnées sont devenues claires dans les années 1970, après la mise en œuvre massive des méthodologies correspondantes telles que SADT / IDEF . Dans le même temps, nous avons travaillé sur des méthodes ascendantes sur des projets «maison» avec d'autres problèmes, ce qui a créé un sentiment d'impasse. Par conséquent, les chercheurs intrigués par le problème (principalement Barry Boehm ), grattant leurs navets, ont émis dès le milieu des années 1980 une vision actualisée du processus de création de logiciels sous la forme d'une spirale .
La logique du raisonnement "en spirale" est approximativement la suivante. Oui, à mesure que la complexité des tâches augmente, nous passons de plus en plus de temps sur l'analyse et la conception, le risque d'erreurs à ce stade augmente. Mais la mise en œuvre de fonctions individuelles sans plan général, nous risquons de faire des erreurs non moins, et nous nous retrouvons avec des pièces inefficaces ou simplement incompatibles. Par conséquent, nous laisserons de côté la conception de la «vache sacrée», mais a) nous limiterons le délai et b) nous vérifierons rigoureusement les décisions prises, en déployant un prototype complet.
Le point "b" est très important. Avec le développement ascendant, vous produisez également constamment quelque chose, des corrections de bogues, de nouvelles fonctionnalités. Mais cela fonctionnera si le système est déjà en fonctionnement et en cours de maintenance. Et sinon? Imaginez qu'un client souhaite un système de contrôle du trafic ferroviaire et que dans quelques semaines, vous lui montrez des écrans pour saisir des informations sur le matériel roulant et un simulateur d'horaires. Pas sérieusement.
Le prototype devrait inclure la plupart des fonctions, même s'il n'est pas entièrement implémenté ou même avec des "stubs". Du prototype complet, respectivement, nous obtenons un retour complet: ici ils ont merdé, n'ont pas compris l'essence des exigences, ils n'ont pas pris en compte l'environnement d'exploitation, là le format de sortie ne correspond pas au format d'entrée, etc. Avec ce précieux retour d'expérience, nous entamons le deuxième tour de la spirale, pensant raisonnablement que les chances d'amener le prochain prototype au niveau d'un produit fini sont élevées. Pour les systèmes de taille moyenne (jusqu'à un million de lignes de code environ), deux ou trois itérations suffisent.
D'après ce qui a été dit, il est clair qu'attribuer la spirale à des méthodes progressives est aussi ridicule que les baleines le sont à pêcher, bien que les deux aient une queue.
Qu'est-ce qui est bon dans la spirale? Nous réduisons considérablement les risques de déploiement chez le client au lieu d'un produit, franchement, mais en même temps, nous ne sacrifions pas le design. Autrement dit, la vision globale de la situation demeure, le résultat final peut être géré en calculant le budget et le profit. Tout le monde, client et entrepreneur, peut voir la lumière au bout du tunnel. Le client, s'il est sérieux dans ses intentions, ne braillera pas non plus: "Pourquoi me mets-tu la queue, puis tu glisses ma trompe, montre-moi tout l'éléphant!" A chaque tour, l'éléphant entier est visible.
Cependant, en comparaison avec la montée en puissance du génie logiciel, il est impossible de gérer un peloton de programmeurs-techniciens sans analystes et concepteurs, et vous devrez expliquer ce moment délicat au client pour justifier un prix plus élevé. Après la phase de conception du premier tour, les spécialistes ne restent pas les bras croisés, mais continuent à mordre dans la tâche, en attendant les commentaires, mais au dernier tour, ils ne seront probablement pas du tout nécessaires. La longueur de la bobine peut aller jusqu'à plusieurs mois, mais elle en coûte généralement deux à trois. Cela ne ressemble pas à un sprint hebdomadaire extrême, mais cela ne ressemble pas non plus à une attente annuelle d'un produit. Il n'est pas non plus facile de choisir quand, à ce stade, «il suffit de concevoir» et qu'il est temps de commencer à poser des briques.
La mise en œuvre la plus célèbre et la plus réussie de la technique en spirale - MSF(Microsoft Solution Framework). Microsoft a par la suite eu une version recadrée, affinée pour les méthodes ascendantes, et commercialisée sous le nom de MSF pour Agile pour des projets et des équipes relativement petits.
Au lieu d'un épilogue
Grand-père Brooks a décrit quatre types de logiciels que les gens construisent dans son livre à succès .
L'image montre qu'à un moment donné, vous pouvez arrêter «d'écrire simplement un programme» et que «pour un prix exorbitant», vous voulez en faire soit un produit (quelque chose qui est fourni à de nombreux clients différents), soit un complexe (quelque chose qui se compose de plusieurs programmes et s'intègre de manière transparente dans l'environnement du client, y compris l'équipement). Et si "écrire un programme", dans l'ensemble, peut être l'une des méthodes de construction douce, alors vos excellents projets de développement ultérieur peuvent être perturbés par les lacunes des méthodes descendantes et ascendantes.
Dans les conditions où la ressource humaine des programmeurs-techniciens est excessive avec une pénurie et des difficultés à embaucher des concepteurs et des analystes, au lieu d'une organisation horizontale (les «ingénieurs systèmes» font une plateforme pour les «candidats»), ils commencent à utiliser une organisation verticale , où chaque équipe met en œuvre ses fonctions en fonction de ses propres vélos. Du point de vue de la gestion, la seconde méthode paraît plus simple, mais seulement jusqu'au moment où une commande «architecture» horizontale est introduite, ce qui, par une longue persuasion et coordination, réduit les risques des mêmes erreurs répétitives.
Là-dessus, peut-être pouvons-nous nous arrêter, car l'orientation initiale dans l'espace de l'information devrait suffire. Il y a des mots-clés et des liens dans le texte, afin que les curieux puissent approfondir le sujet.
Texte original sur le site "Mécanique du génie logiciel"