Le besoin de spécifications de conception logicielle a-t-il considérablement diminué avec l'évolution des langages de programmation plus expressifs?


16

Pour de nombreux informaticiens, y compris moi-même il y a quelques années, le processus de développement logiciel idéal impliquerait la création de documents de conception détaillés avec de nombreux diagrammes UML avant l'écriture d'une ligne de code. (Cela ressemble à une description du modèle de cascade, mais c'est la même chose avec Agile, sauf que les itérations sont plus petites.)

Au cours des deux ou trois dernières années, j'ai complètement changé d'avis. Je pense toujours qu'une spécification détaillée des exigences avec les cas de test associés est absolument essentielle. Pour les grands projets, j'aurais également besoin d'un aperçu de l'architecture globale avant de commencer à coder. Mais tout le reste doit être fait en code autant que possible. Dans le cas idéal, il ne devrait y avoir aucune description de la conception du logiciel à l'exception du code lui-même.

Comment en suis-je arrivé à cette conclusion? Voici quelques arguments:

Retour d'information

Les outils pour écrire des documents ou créer des diagrammes fournissent peu de commentaires. Oui, il existe des outils de modélisation qui effectuent des vérifications de cohérence sur les diagrammes UML, mais ils sont limités et entraînent de nombreux frais généraux.

Sans rétroaction, il est difficile de reconnaître et de corriger les erreurs.

Dès que vous écrivez du code, vous obtenez beaucoup de commentaires, par exemple:

  • Erreurs et avertissements du compilateur
  • Résultats de l'analyse de code statique
  • Tests unitaires

Les erreurs peuvent être rapidement reconnues et corrigées.

Cohérence

Pour vous assurer que le code est cohérent avec vos documents, vous devez vérifier encore et encore. S'il y a des changements fréquents, il est difficile de synchroniser le code et les documents.

Refactoring

Il existe de puissants outils et techniques pour refactoriser le code tandis que la refactorisation des descriptions textuelles ou des diagrammes est généralement difficile et sujette aux erreurs.


Il y a une condition préalable pour que cela fonctionne: le code doit être assez facile à lire et à comprendre. Cela ne peut probablement pas être réalisé avec Assembler, Basic ou Fortran mais les langages (et bibliothèques) modernes sont beaucoup plus expressifs.

Donc, si mes arguments sont valables, il devrait y avoir une tendance vers des spécifications et une documentation de conception logicielle moins ou plus légères. Existe-t-il des preuves empiriques de cette tendance?


2
La conception initiale est tombée en disgrâce en raison du développement agile qui gagne en popularité à mesure que l'industrie évoluait. Les langages devenant plus expressifs et les outils plus légers ont facilité le prototypage rapide, permettant un développement plus agile. Je pense qu'il y a un lien de causalité entre les deux.
Rétablir Monica

14
D'après mon expérience, "la création de documents de conception détaillés avec beaucoup de diagrammes UML avant qu'une ligne de code ne soit écrite" n'a jamais été une bonne idée - du moins pas à l'époque puisque je travaillais en tant que programmeur professionnel, qui est plus d'un une décennie de plus que UML existe. Cependant, étirer une conception de haut niveau avant de coder est et était une bonne idée lorsque les systèmes devraient avoir une certaine taille. Mais UML n'est à mon humble avis pas le bon outil pour cela.
Doc Brown

2
Trop paresseux pour une réponse correcte: des langages de programmation plus expressifs et des ordinateurs plus puissants conduisent à des besoins de programmes de plus en plus performants et complexes, ce qui conduit à des spécifications d'exigences plus compliquées.
whatsisname

2
Lecture recommandée: battre les moyennes .
Robert Harvey

1
J'ai travaillé sur un projet avec une conception UML complète. À partir de laquelle nous avons généré du code. J'en suis venu à la conclusion que je ne voulais plus jamais recommencer. Il était beaucoup plus difficile de changer l'UML que de changer le code; et un grand modèle UML est au moins aussi lourd que beaucoup de code source. Le code "généré" était difficile à lire et le générateur laissait des "marqueurs" dans le code.
Nick Keighley

Réponses:


9

Je remets en question la prémisse que les langues sont de plus en plus expressives. Avec le code ASP.NET d'aujourd'hui en c #, j'écris à peu près au même niveau que lorsque j'ai écrit du code ASP en Visual Basic. Nous utilisons toujours c ++. Javascript a ajouté des fonctionnalités mais dans l'ensemble la langue n'a pas changé. Même chose avec SQL.

Je pense que ces autres changements sont plus importants:

  1. Adoption de tests unitaires automatisés. Certains diraient que les tests sont la spécification. Nous n'avons donc pas supprimé la nécessité de rédiger des spécifications; nous les écrivons plutôt dans du code plutôt que dans des documents Word.

  2. Changements dans la méthodologie de déploiement. Dans le passé, il était très coûteux de commettre une erreur car vous deviez envoyer une copie mise à jour de votre logiciel. Il fallait donc faire attention. Avec les applications Web, vous pouvez déployer des correctifs pour une utilisation immédiate et vous pouvez vous permettre de réagir aux problèmes plutôt que de les anticiper, en restructurant le code au fur et à mesure.

  3. Adoption de modèles de conception. Lorsque tout le monde connaît les modèles, vous n'avez pratiquement rien à concevoir; vous pouvez simplement dire "ajouter une fabrique de référentiels" et votre équipe devrait le faire sans avoir besoin de voir UML.

  4. Contrats de données de SOA. Presque tout est SOA de nos jours. Tout ce dont vous avez besoin est un WSDL. L'époque de la définition et de la documentation des formats de transfert de données est révolue. L'évolution actuelle vers davantage de RESTful et de micro-services poursuit cette tendance.

  5. Les logiciels sont plus petits. En partie grâce aux architectures SOA, les équipes écrivent des programmes plus petits qui sont liés entre eux. Chaque composant individuel est moins complexe et nécessite moins de conception initiale; de plus, il est plus facile de changer une partie de l'architecture sans casser la solution globale en raison des coupe-feu forcés par les définitions d'interface entre les composants.

  6. Beaucoup, beaucoup plus d'utilisation des bibliothèques établies. Le .NET CLR offre une tonne de fonctionnalités standard, donc pas besoin de concevoir, par exemple, un schéma de mise en cache des données de session. Les bibliothèques tierces comme jQuery UI ou Bootstrap établissent des normes pour écrire du code pour fonctionner d'une certaine manière. Vous n'avez pas besoin de les documenter; les équipes devraient pouvoir simplement les utiliser.

  7. Maturité de l'industrie. Les SWE ont appris qu'il n'existe pas de projet "Battlestar Galactica" où vous passez des années et des années à atteindre un objectif spécifique; au moment où ces années se seront écoulées, l'objectif aura changé. Aujourd'hui, nous savons que le délai de mise sur le marché est beaucoup plus important que d'obtenir tout exactement comme nous le voulons dans la conception.

  8. Des ingénieurs mieux formés et mieux formés. Ces jours-ci, vous pouvez embaucher des ingénieurs qui comprennent les meilleures pratiques (espérons-le) et les mettront simplement en œuvre sans document de conception leur indiquant quoi faire.

  9. Les outils de productivité tels que TFS vous permettent d'écrire une tâche simple qui référence un cas d'utilisation et fournit quelques puces pour toute décision technique ambiguë. Vous n'avez pas besoin de beaucoup plus que cela. Les développeurs peuvent réviser, estimer, obtenir des révisions de code, archiver, etc. tout via l'outil. C'est beaucoup plus efficace que de travailler avec des documents externes car cela relie tout ensemble.

Vous avez toujours besoin de documents de conception pour certaines choses ... par exemple, si votre application est divisée en différents composants qui sont développés par différentes équipes, vous devez au moins leur dire quel composant est responsable de quelles exigences. Mais pour la plupart, les méthodologies de développement d'aujourd'hui offrent beaucoup plus de liberté tout en vous donnant des outils pour gérer et contenir tout risque pouvant survenir lorsqu'un développeur prend une mauvaise décision.


3
Notre industrie a mûri ... un peu. Le point 5 est de loin le changement le plus important; cela a un impact positif sur tous les autres. Mais le fait que nous changeons toutes nos technologies tous les 5 ans suggère que nous avons encore un long chemin à parcourir, et l'expressivité de la langue (la seule chose qui est relativement stable dans le temps parce qu'une amélioration significative dans ce domaine est si péniblement difficile) produit plus de gains que vous ne le pensez.
Robert Harvey

1
Ce n'est pas tout un progrès: le principal saut en avant a été, gracieusement, avec l'invention du compilateur. Mais nous enseignons toujours des organigrammes, une abstraction sur le code assembleur (et de nombreuses autres pratiques obsolètes). Probablement parce que nous avons oublié pourquoi?
ctrl-alt-delor

6

Je plaiderais pour non .

Pour une simple raison

Pour de nombreux informaticiens, y compris moi-même il y a quelques années, le processus de développement logiciel idéal impliquerait la création de documents de conception détaillés avec de nombreux diagrammes UML avant l'écriture d'une ligne de code.

N'a jamais été considéré comme «idéal», car Extreme Programming existe depuis les années 1990 . Et comme vous dites:

Dans le cas idéal, il ne devrait y avoir aucune description de la conception du logiciel, sauf le code lui-même.

A été débattue il y a longtemps. Par exemple, cet article légendaire de 1992: Qu'est-ce que la conception de logiciels .

Ce qui précède montre que vous pouvez avoir un processus «extrême» avec une architecture hautement évolutive et une approche itérative sans avoir besoin de langages complexes ou d'IDE.

Au lieu de cela, je dirais que ce passage "apparent" de la conception à l'avance avec beaucoup de diagrammes et de documents de cas d'utilisation à une approche plus évolutive et itérative consiste simplement à remplacer les gestionnaires de la "vieille école" par de nouveaux, qui ont grandi dans beaucoup plus environnement dynamique et pour qui il est beaucoup plus facile d'accepter et de travailler dans un environnement plus "agile".


6

Je suis à peu près d'accord avec cela, mais je pense que cela a commencé beaucoup plus tôt que vous l'imaginez. Je pense également qu'il y a un autre facteur important en dehors de l'expressivité. Lorsque mon père a commencé à programmer, il a dû créer des cartes perforées et planifier du temps sur l'ordinateur. Vous pourriez avoir une chance par jour d'exécuter votre programme. Il n'y avait pas beaucoup de temps pour perdre le code du bâtiment, le laisser échouer, puis le réparer. Vous avez peut-être 2 ou 3 coups de feu et si cela ne fonctionnait pas, vous aviez des problèmes.

Le risque de cela signifiait qu'il était crucial de consacrer beaucoup de temps supplémentaire à la planification de votre programme. Les gens écrivaient leur code au crayon, puis le transféraient sur les cartes perforées. Au fur et à mesure que la technologie progressait, vous pouviez coder directement dans le terminal mais vous utilisiez toujours des ressources partagées et le CPU était cher. Une méthodologie test-first serait complètement intenable dans ce monde. Si vous ne planifiez pas à l'avance, vos pairs seront à votre bureau avec des fourches.

Les ressources informatiques sont devenues moins chères et meilleures à un rythme incroyable. Bon nombre des contraintes sous lesquelles toutes ces pratiques ont été développées sont complètement effacées. Comme le souligne Euphoric, l'abandon de cela a vraiment commencé dans les années 90. La suite d'une grande partie de la grande conception initiale a été une pure inertie.

Donc, oui, l'expressivité améliorée des langages de programmation a eu un impact sur cela du simple fait qu'il est plus facile d'utiliser du code expressif comme sa propre documentation. Le coût de production d'un document qui vous dit ce que dit le code est très élevé et sa valeur (c'est inévitablement faux à un certain niveau.) En même temps, le coût de jeter de la merde au mur et de voir ce qui colle est fondamentalement négligeable.


3

Je pense que vous oubliez le but d'avoir des documents de conception en premier lieu!

Les documents de conception (exigences, cas d'utilisation, maquettes, etc.) nous permettent de décrire, comprendre et discuter du système à un niveau élevé. La quantité de détails laissés de côté dans ces documents est ce qui les rend utiles.

Il n'est pas nécessaire d'avoir des documents qui décrivent le comportement exact du système système dans tous les détails, car en effet le code source lui-même sert à cet effet.

Le développement de logiciels pourrait être considéré comme le processus de transformation de spécifications lisibles de haut niveau en spécifications de bas niveau non ambiguës qui sont exécutables par une machine. Mais vous avez besoin d' entrée pour ce processus.


Bien sûr, une documentation de haut niveau qui ne traite pas des détails est absolument requise. Mais c'est exactement ce que j'attends d'un bon langage de programmation. Il devrait permettre d'écrire du code à différents niveaux de détail. Le code ne doit pas être un désordre non structuré d'instructions de bas niveau.
Frank Puffer

@FrankPuffer un diagramme vaut 100 000 LoC.
RubberDuck

1
@RubberDuck Il me semble que la capacité (ou son absence) de générer divers diagrammes utiles à partir du code pourrait être une mesure de l'expressivité d'un langage. Il n'y a pas de diagramme que vous pouvez dessiner qui ne peut pas être exprimé dans une sorte de langage. La question est de savoir si cette langue peut transmettre les mêmes informations d'une manière qui peut être facilement écrite ou lue.
JimmyJames

1
@RubberDuck: Les diagrammes ont du sens dans certains cas, par exemple pour expliquer l'architecture globale. Mais je ne pense pas qu'ils devraient être la valeur par défaut. Il y a certainement des diagrammes bons et utiles mais malheureusement la plupart des UML que j'ai vus sont plus déroutants qu'utiles. Et pire encore, elle diffère souvent de la mise en œuvre réelle.
Frank Puffer

J'aime que vous mentionniez la génération de diagrammes @JimmyJames. Je préfère la génération à la création manuelle. Vous avez un argument très valable, mais je me demande si c'est en fonction de l'expressivité ou de l'outillage.
RubberDuck

1

Dans le cas idéal, il ne devrait y avoir aucune description de la conception du logiciel, sauf le code lui-même.

C'est plus loin que vous ne le pensez. Même des choses comme les types dépendants (qui, si je comprends bien, sont assez prometteurs en théorie) sont sur plusieurs années.

La vérification formelle est assez difficile, et pour cette raison, le seul endroit où la vérification formelle est couramment utilisée est les bibliothèques de cryptographie.

Tests unitaires

Si les tests de propriété n'ont pas atteint le courant dominant, je ne pense pas que ce sera pratique pendant longtemps.

De plus, écrire de bons tests (qui n'auront pas besoin d'être édités avec chaque refactor mais qui attraperont toujours suffisamment d'erreurs) est assez difficile.

Pour vous assurer que le code est cohérent avec vos documents, vous devez vérifier encore et encore. S'il y a des changements fréquents, il est difficile de synchroniser le code et les documents.

Il est probablement plus facile d'utiliser un outil de test de documentation pour le moment.

Il y a une condition préalable pour que cela fonctionne: le code doit être assez facile à lire et à comprendre.

Malheureusement, il est difficile de concevoir des langages non seulement extrêmement expressifs, mais aussi parfaitement lisibles. Des langages tels que Go donnent la priorité à la lisibilité, et il entrave la réflexion de niveau supérieur.

Enfin, d'après mon expérience, de meilleurs langages et outils ne conduisent pas à des logiciels avec moins de bugs, mais plutôt à des projets plus importants. Il n'y a vraiment aucun moyen plausible pandocqui aurait été écrit en 1970.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.