La réutilisation des logiciels empêche-t-elle la répétabilité des processus

La réutilisation du code comme problème

Je pensais à cette question sur la livraison de logiciels, et je revenais sans cesse sur la question de la répétabilité et / ou de la reproductibilité . Ils sont importants, car si vous ne répétez pas un projet, il devient plus difficile d'améliorer le processus que vous avez utilisé pour construire le projet. L'ingénierie implique l'amélioration constante des processus impliqués dans la conception et la construction afin de produire des projets de meilleure qualité.

Le logiciel peut dépendre fortement de la réutilisation en raison de sa forme numérique. Au lieu de réécrire un module, il suffit de le rappeler ou de le copier sur l'autre système. Certains exemples sont l'authentification / connexion ou peut-être une fonction de journalisation. Il existe de nombreux exemples bien connus pour ces catégories, et la sagesse conventionnelle consiste à réutiliser ce qui existe au lieu de rouler le vôtre.

Quelques comparaisons avec d'autres disciplines

Construction

En revanche, la construction de systèmes physiques (bâtiments, ponts) est loin d'être aussi réutilisable. Il est vrai que le plan d'une maison peut être réutilisé plusieurs fois pour construire la même copie de la maison, mais la construction doit être effectuée à chaque fois. Le copier-coller ne fonctionne pas comme ça dans le monde analogique. Les plans de pont sont moins réutilisables que les maisons car les conditions du site varient.

Les maîtres d'œuvre sont des experts reconnus pour avoir conçu et / ou construit des dizaines, des centaines ou des milliers de choses dans leur région. Par exemple, Frank Lloyd Wright , architecte et designer de renommée mondiale designed more than 1,000 structures and completed 532 works. Comparez cela avec Anders Hejlsberg qui a conçu "seulement" cinq langages (Turbo Pascal; Delphi; J ++; C #; Typescript). À bien des égards, c'est une comparaison injuste car les domaines sont différents. Mais à un niveau large, la production quantifiable de deux personnes très intelligentes est très différente.

Arts martiaux

Les artistes martiaux diront que la maîtrise d'un mouvement ne vient que de milliers de répétitions. Après qu'une bonne partie de ces répétitions ait été mise en place, de nombreux artistes martiaux sont surpris de voir comment un kata ou une forme auparavant perçu comme complexe est devenu simple. Les instructeurs de ces élèves remarqueront également comment le mouvement devient plus fluide et utile, tout en ayant une économie de mouvement. De même, les artistes martiaux expérimentés sont capables de ramasser des katas plus complexes plus rapidement que les étudiants moins expérimentés. L'expérience de la répétition leur a donné un cadre ou un processus qui leur permet d'apprendre plus rapidement.

Travail du bois

Les menuisiers connaissent une transformation similaire. Les menuisiers amateurs se réfèrent toujours à leur premier projet qui nécessitait beaucoup de tiroirs. S'ils achèvent le projet, ils acquièrent une nouvelle appréciation pour l'efficacité des chaînes de montage. Il y a d'autres avantages comme une meilleure compréhension de la disposition des pièces des tiroirs sur le stock de feuilles afin de maximiser l'utilisation du bois. Par rapport aux amateurs, les menuisiers professionnels sont en mesure de concevoir, de démarrer et de construire plus rapidement des articles qu'ils ont fabriqués à plusieurs reprises auparavant. Ils acquièrent également la capacité de voir les problèmes inhérents à la conception de quelqu'un d'autre ayant fait cette erreur dans leur travail.

La réutilisation des logiciels empêche-t-elle les développeurs de devenir plus compétents?

À bien des égards, la conception et la construction de logiciels sont toujours nouvelles. Nous ne répétons pas les travaux passés, car si nous pouvons réutiliser un module, une bibliothèque ou un système, nous le faisons. Nous étendrons préférentiellement un système existant avant de réécrire le tout à partir de zéro. Mais la répétition est ce qui nous permet de trouver de l'efficacité dans la conception et la construction. Quiconque a pratiqué un sport ou une activité physique vous dira que la répétition est la clé pour devenir un bon pratiquant.

Ma question: la capacité du logiciel à être réutilisé empêche-t-elle l'amélioration et l'efficacité des processus nécessaires qui découlent de la répétition d'un projet?

La possibilité de réutiliser le logiciel n'empêche pas l'amélioration des processus.

Si vous pensez aux processus qui entrent dans la création de logiciels - développement des exigences, conception du système, implémentation du système, déploiement du système, gestion des exigences, gestion des configurations, vérification et validation du produit de travail, suivi des modifications et plusieurs autres (voir le Zones de processus CMMI pour une ventilation possible des activités clés dans le développement de logiciels) - elles sont répétées sur chaque projet, quelle que soit la quantité de réutilisation dont vous disposez. En outre, chacun a une sorte de mesures quantitatives et qualitatives qui peuvent être utilisées pour déterminer la qualité de ce processus ou de cette activité particulière et, par conséquent, la qualité du processus de développement dans son ensemble.

À une extrémité de l'extrême, nous pouvons supposer une gamme de produits logiciels robustes. À l'autre, vous pouvez assumer le développement de nouveaux terrains. Il est toujours nécessaire d'effectuer tous ces processus, à des degrés divers, bien qu'ils puissent se produire à des rythmes différents ou peut-être même dans des séquences différentes. Par exemple, dans une quantité élevée de réutilisation, un plus grand pourcentage du temps alloué peut être consacré aux activités d'intégration et de vérification / validation au niveau du système (exigences V&V, tests d'intégration, tests du système, tests d'acceptation). Avec de nouveaux efforts de développement, un pourcentage plus important de temps peut être nécessaire lors de la conception et de la mise en œuvre. Tant que vous effectuez un processus au moins une fois au cours d'un projet, vous pouvez le mesurer (quantitativement et qualitativement). Une fois que vous avez effectué des ajustements et que vous voyez comment ces ajustements ont un impact sur une mesure du domaine de processus ou de la capacité globale à fournir des logiciels,

La clé de l'amélioration des processus est d'avoir une sorte de ventilation logique de vos activités et processus, de déterminer comment les mesurer (de préférence de manière cohérente) et comment comprendre ces mesures pour effectuer des changements de processus vers une certaine fin. Il ne s'agit pas de répéter le projet, mais de la cohérence dans la façon dont vous répétez le processus.

Je pense que l'idée que d'autres disciplines de l'ingénierie n'utilisent pas la réutilisation est fausse. Même lors de la conception de bâtiments / machines, vous disposez toujours de composants utilisés par de nombreux autres projets. Par exemple, concevez-vous vos propres vis? Des moteurs? Portes ou fenêtres? Bien sûr que non. Ceux-ci sont souvent conçus par différentes personnes qui les utilisent ensuite dans différents produits. Et ils sont assez souvent standardisés, ce qui favorise encore plus la réutilisation.

Je pense que le problème aime la complexité. Vous ne pouvez tout simplement pas comparer la complexité des bâtiments, même les plus complexes, à des logiciels complexes. C'est une idée généralement acceptée que la complexité du logiciel est ce qui rend difficile l'approche du côté de l'ingénierie. Au moment où vous avez un processus en place qui vous permet de créer des logiciels de qualité acceptable, vous constatez que la complexité des logiciels dont vous avez besoin pour créer des sauts par ordre de grandeur. Le processus ne peut donc pas être utilisé. Donc, si nous devions répéter une partie du logiciel plusieurs fois jusqu'à ce que nous soyons satisfaits du résultat, nous ne terminerions jamais ce logiciel.

C'est pourquoi le code propre est promu. La capacité de changer le code passé en fonction de nouvelles expériences peut être considérée comme une forme de réutilisation de la conception. Ainsi, au lieu de créer plusieurs logiciels différents plusieurs fois, nous refactorisons et affinons un seul logiciel en réutilisant de nouvelles expériences et en concevant d'anciens problèmes. Tout en essayant de faire faire au logiciel la même chose.

Le logiciel est différent de la plupart des autres disciplines, de sorte que l'économie de l'endroit où nous passons le mieux notre temps est souvent différente.

Dans la construction, vous dépensez un certain temps et de l'argent sur un plan (et le logiciel ressemble beaucoup plus à la production d'un plan qu'à la construction d'un bâtiment), puis, en gros, beaucoup plus à le construire en réalité une ou plusieurs fois. Il vaut donc la peine de consacrer beaucoup de travail à l'élaboration du plan directeur. Plus précisément à votre question - il vaut la peine de répéter l'effort de le refaire à partir de zéro pour améliorer un peu le produit final.

Dans le logiciel, lorsque vous avez le plan directeur, il est beaucoup moins cher de construire le produit que de le faire. Au moins la plupart du temps - si le logiciel est intégré dans un stimulateur cardiaque, vous êtes à bien des égards plus proche de la situation d'un constructeur de ponts. Mais en général, la réutilisation de logiciels peut économiser 90% du coût de votre élément budgétaire le plus important, contre 90% d'un élément budgétaire beaucoup plus petit pour la construction d'un pont. La réutilisation gagne donc beaucoup plus souvent.

En ce qui concerne la productivité - lorsque vous construisez, disons, un pont, vous êtes confronté à des contraintes réelles très importantes. Imaginez si les architectes ont été payés de grosses sommes d'argent pour concevoir des ponts pour des jeux en ligne massifs multijoueurs, où les coûts de construction étaient proches de 0 et les limitations beaucoup moins importantes que dans le monde réel. Ils concevraient des ponts qui sont terriblement complexes par rapport aux normes réelles des ponts. La phase du plan peut prendre un peu plus de temps.

De plus, il y a un nombre limité de ponts à construire et, puisque la conception est une petite partie du coût, vous pouvez payer pour le meilleur, et quelques-uns des meilleurs peuvent faire la plupart de la conception. Il y a des centaines de milliers de développeurs de logiciels et, fondamentalement, tous ont un arriéré géant de choses qu'ils feraient s'ils avaient le temps. Vous n'allez pas trouver un gars qui fait une grande partie de tout cela - c'est un peu surprenant qu'il y ait des gens qui se rapprochent, vraiment.

Votre véritable argument semble être que nous pouvons perdre quelque chose en réutilisant au lieu d'essayer de répéter et d'améliorer les choses. Je pense que vous avez raison. Le problème est que, bien qu'il soit très probablement plus efficace à l'échelle mondiale de réécrire certains des éléments fondamentaux et d'essayer de les améliorer, celui qui prend cela prend tous les risques et probablement pas autant de récompense. (Il y a aussi un énorme problème pratique de l'enfer de la dépendance, qui prend probablement une partie de la victoire de la réécriture des choses, mais pas au point que cela ne serait pas utile, du moins en regardant l'image globale. Le droit d'auteur et les brevets peuvent également forcer un effort de réingénierie proposé mordre un peu de travail de réécriture pour refaire de plus petits morceaux de code existant).

En termes d'apprentissage de la répétition - dans toutes les disciplines, cela se produit moins dans la conception que dans la construction, car il y a moins de répétition, donc moins de chance d'apprendre, et peut-être moins d'avantages. De plus, le processus de conception n'est probablement pas reproductible. C'est un peu comme avoir un processus pour écrire un roman. Un bon processus peut presque certainement aider, et un logiciel est généralement beaucoup plus collaboratif qu'un roman, mais répéter un processus lorsque le but est d'inventer quelque chose de nouveau est problématique. Même les romanciers apprennent du passé, beaucoup, mais un processus reproductible est un facteur secondaire pour les efforts créatifs. Et si une partie du développement logiciel est vraiment vraiment reproductible, pourquoi un ordinateur ne le fait-il pas?

La capacité du logiciel à être réutilisé empêche-t-elle l'amélioration et l'efficacité des processus nécessaires résultant de la répétition d'un projet?

J'ai travaillé en tant qu'ingénieur systèmes et logiciels dans le même grand projet au cours des 17 dernières années, d'ailleurs (en pensant à la référence Airbus A380 dans votre premier lien) dans l'industrie aéronautique, bien que mes responsabilités se situent dans le secteur des avions militaires. Des histoires comme celles-ci sont fondamentalement de la pure fiction, et en fait vraiment amusantes à regarder lorsque vous avez un aperçu des initiés.

Mais pour votre question brève et concise: D'après mon expérience, je dirais oui et non.

Permettez-moi d'abord de dire que je suis pour le recyclage de logiciels sous toutes ses formes (enfin, peut-être pas tous ...). Les avantages de réutiliser à peu près n'importe quoi, des extraits de code et des algorithmes de copier-coller, aux modules de code entiers et aux bibliothèques de fonctions, sont dans l'ensemble bien meilleurs que de toujours recommencer depuis le début (pour pousser un peu).

L'inconvénient est, comme vous le faites remarquer (ou du moins en déduisez), que lorsque vous ajoutez des fonctionnalités en assemblant simplement un ensemble donné de composants (et, oui, je simplifie à l'extrême), vous n'évoluez pas vraiment en tant que programmeur, ingénieur ou autre.

En regardant les ingénieurs logiciels qui m'entourent au travail, je sais par longue expérience qu'une majorité d'entre eux ne savent pas, et pire encore - n'ont aucun intérêt à apprendre, quoi que ce soit sur le produit que nous construisons autre que le strict minimum dont ils ont besoin pour produire le document ou le morceau de code qu'ils sont chargés de faire.

Je suis un peu hors sujet ici, mais mon point est que lorsque les programmeurs n'ont pas besoin d'apprendre à quoi servira vraiment le code qu'ils construisent, et n'ont pas besoin d'apprendre le fonctionnement interne du système car ils peuvent simplement réutilisez des composants déjà écrits et testés, alors la plupart d'entre eux ne prendront pas la peine de le faire.

Certes, cela est également dû à d'autres circonstances, telles que le produit que nous construisons est incroyablement complexe, et il serait impossible pour une personne de tout savoir (et je ne parle que de l'un des ordinateurs de l'avion - le plus complexe d'entre eux, mais quand même).

Si nos ingénieurs logiciels n'avaient pas la possibilité de réutiliser autant de code, je suis convaincu qu'ils deviendraient mieux dans leur profession en général, et des atouts beaucoup plus importants pour le projet en particulier.

Oh, et vous avez peut - être remarqué que je parle les beaucoup ici. Je fais bien sûr également partie de ces ingénieurs logiciels. L'exception étant que je semble être beaucoup plus curieux et désireux d'apprendre de nouvelles choses que les autres :-) Face à une nouvelle tâche, je prends toujours sur moi d'en apprendre autant que possible, à la fois dans le sous forme de faits et en étudiant le code source (oui, j'aime ça aussi).

Ah - dang, à nouveau sur le côté ... Mon excuse est que je n'ai pas dormi depuis 32 heures, donc ma capacité de concentration est un peu ... qu'est-ce que je disais?

Si quelqu'un lit encore, ma conclusion est que:

Oui , une trop grande réutilisation des logiciels rend les ingénieurs logiciels moins compétents, ce qui les rend nettement moins efficaces lorsqu'ils ont réellement besoin de savoir comment les choses fonctionnent. L'analyse des problèmes est un bon exemple, ou même simplement être en mesure de dire si une solution de conception suggérée est viable. Et bien sûr, l'amélioration des processus est également plus difficile à réaliser lorsque vous ne savez pas vraiment ce que vous faites :-)

et Non , la réutilisation des logiciels avec soin , ce qui peut vous donner beaucoup de temps libre à examiner et à l' amélioration des processus de plan.

Comme indiqué dans la réponse acceptée dans une autre question des programmeurs, les analogies avec la construction doivent être prises avec soin:

une lecture recommandée pour cela est l' analogie de la construction de logiciels est cassée

le logiciel est souvent assimilé à la construction. Malheureusement, cette analogie est erronée et les enseignements tirés de l'industrie de la construction sont suspects ...

Ce que j'ai observé, c'est que les bons projets logiciels "transforment" beaucoup de répétabilité en assurance qualité.

Lorsque j'étais testeur dans un projet de 1,5 an, nous exécutons des cycles de test à des sorties hebdomadaires de «points de contrôle», environ 70 fois au total tout au long du projet. C'était ... tout à fait répétable, doucement (peu de choses changent en une semaine). Le test des versions nocturnes a été, naturellement, encore plus répétable - environ 500 fois tout au long du projet (quelques bugs amusants de showstopper étaient trop rares pour faire la différence).

Maintenant, suivant cette analogie «suspecte», dites-moi une entreprise de construction qui a construit 500 ponts - tous avec la même équipe.

• Ensuite, dites-moi une entreprise qui utilise principalement les mêmes briques et fer à repasser sur chacun de leurs nouveaux ponts (ici, je me réfère au fait que les versions que nous avons testées avaient principalement les mêmes bits de code jour par jour, semaine par semaine - "peu de choses changent").
  

Les maîtres d'œuvre sont des experts reconnus pour avoir conçu et / ou construit des dizaines, des centaines ou des milliers de choses dans leur région.

Très bien, suite à votre explication de la répétabilité citée ci-dessus, je peux le dire quoi? À l'époque, notre petit groupe de testeurs peu spécial a vérifié, voir ci-dessus ("environ 500") des centaines de choses dans notre région.

Quant aux développeurs de projets, ils ont littéralement construit ("builds nocturnes") - voyez, le mot est le même, et le sens est juste dans ce contexte - des centaines de choses dans leur domaine.

Si l'on veut continuer cette analogie "suspecte" jusqu'à "des milliers de choses", ces montants ne sont, encore une fois, rien de spectaculaire dans le développement logiciel quand on regarde les bonnes choses.

• À titre d'exemple, un autre de mes projets passés (encore une fois rien de spectaculaire, plutôt régulier), cette fois en rôle de développeur, dure depuis plus de 5 ans (8 sorties majeures, plusieurs dizaines de mineures). Il y avait des points de contrôle hebdomadaires similaires ( 5x52~=250d'entre eux), des sorties nocturnes similaires ( 5x365~=1800d'entre eux) et de même, les mêmes équipes de développement / AQ travaillant sur ces points . Jour par jour, semaine par semaine, mois par mois, surtout des choses répétitives (pas beaucoup de changement entre deux versions nocturnes) - comme promis, des milliers de fois (1800).

Des projets plus longs comme Windows ou Java, ou AutoCAD peuvent s'étendre sur 10, 20, 30 ans, ce qui explique facilement la répétition d'autant de «milliers» de constructions et de tests nocturnes qu'il obtient.

Le concept de passage de la répétabilité à l'AQ devient encore plus important avec l' intégration continue ...

la pratique ... de fusionner toutes les copies de travail des développeurs avec une ligne principale partagée plusieurs fois par jour ... CI peut être considéré comme une intensification des pratiques d'intégration périodique ..

En plus des tests unitaires automatisés, les organisations utilisant CI utilisent généralement un serveur de génération pour mettre en œuvre des processus continus d'application du contrôle qualité en général - de petits efforts, appliqués fréquemment. En plus d'exécuter les tests unitaires et d'intégration, ces processus exécutent des tests statiques et dynamiques supplémentaires, mesurent et profilent les performances, extraient et formatent la documentation à partir du code source et facilitent les processus manuels d'AQ. Cette application continue du contrôle qualité vise à améliorer la qualité des logiciels , et à réduire le temps nécessaire à leur livraison, en remplaçant la pratique traditionnelle consistant à appliquer le contrôle qualité aprèsterminer tous les développements. Ceci est très similaire à l'idée originale d'intégrer plus fréquemment pour faciliter l'intégration, uniquement appliquée aux processus d'AQ ...

Répétabilité? c'est là, autant que l'on peut penser.

Avec un contrôle qualité fréquent / continu, les choses qui tournent mal reviennent rapidement aux développeurs qui sont obligés de répéter les tentatives pour le faire correctement jusqu'à ce que les tests échouent avec succès. Dans un sens, ce cycle de répétition jusqu'à ce qu'il passe ressemble au code cata ,

un exercice de programmation qui aide un programmeur à perfectionner ses compétences par la pratique et la répétition ...

Une partie de ce que vous dites est vraie: par exemple, les bibliothèques résolvent les fonctions non résolues par des langages de haut niveau qui résolvent les problèmes non résolus par l'assemblage qui résolvent les problèmes non résolus par le code machine. Lorsque vous appelez System.out.println () en java, vous perdez de vue la sortie d'un processeur vers un périphérique.

Alors oui, vous perdez quelque chose. Ce que vous gagnez, c'est la capacité de vous concentrer sur les problèmes non résolus. Il se peut maintenant que vous deviez vous immerger dans certains autres aspects de la technologie (par exemple, le fonctionnement des réseaux) pour résoudre un problème. Mais vous n'avez pas besoin de devenir un expert en lecture de langage machine lorsque tout ce que vous voulez faire est de créer une page Web.

De la même manière, les constructeurs de ponts résolvent à chaque fois un problème légèrement différent (c'est une rivière différente). Ils ne se soucient pas de la façon de créer des poutres en acier d'une certaine résistance à la traction, ni de la façon d'usiner des boulons avec une certaine tolérance. Ils laissent cela aux spécialistes qui ont résolu ce problème.

Regardez attentivement, et vous verrez que toute notre société et notre infrastructure sont construites sur 99% de réutilisation et seulement 1% de progrès réels. La plupart des nouvelles choses ne sont que de vieilles choses avec un petit quelque chose en plus ajouté ou supprimé. C'est l'accumulation de connaissances humaines. Vous pouvez écrire du code dans un langage de haut niveau avec des bibliothèques décentes parce que quelqu'un a compris toutes les choses incroyablement compliquées nécessaires pour arriver à ce point. Il vous permet de résoudre des problèmes nouveaux et intéressants.

Pour lier tout cela et répondre aux commentaires: Vous n'avez pas à résoudre des problèmes qui ont déjà été résolus pour développer la compétence. De plus, une grande partie de ce que vous faites réinventera la roue. Bref, la réponse est non - vous n'avez pas besoin de réimplémenter les fonctions des bibliothèques pour devenir compétent. Il y a beaucoup d'opportunités, certaines par cœur, d'autres créatives pour affiner votre métier.

C'est une question de ressources. Il y a des années, si vous développiez des projets logiciels pour de grands ordinateurs centraux, ils pourraient durer environ 15 ans avec un environnement de développement statique. Le programme FORTRAN écrit pour calculer la masse salariale ou le programme COBOL a été perfectionné au fil des décennies car il était constamment utilisé. Il y avait des ressources pour voir comment cela pourrait être amélioré. Nous n'avons plus ce genre d'environnement lent pour affiner et peaufiner les compétences d'un projet spécifique. Mais nous prenons les compétences et les adaptons aux ressources du prochain projet le permettant. Mais au final, cela devient un choix d'argent dépensé sur le nouveau projet pour faire le travail, ou pour faire le nouveau travail avec une grande quantité de dorure. Placer l'or dans un projet signifie l'améliorer au nième degré et ajouter une tonne de cloches et de sifflets même si l'utilisateur ne l'a pas fait.

Le mieux que nous puissions faire est d'examiner la conception globale d'un nouveau projet et de voir comment il peut être amélioré en fonction de l'expérience passée de l'équipe. Mais il faut un véritable architecte logiciel d'expérience pour avoir une vision de ce qui est réellement considéré comme l'amélioration de la conception pour améliorer les compétences par rapport à la simple utilisation du dernier mot à la mode en développement, comme Agile, OOP, etc.