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?
la source
Réponses:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
la source
Je plaiderais pour non .
Pour une simple raison
N'a jamais été considéré comme «idéal», car Extreme Programming existe depuis les années 1990 . Et comme vous dites:
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".
la source
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.
la source
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.
la source
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.
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.
Il est probablement plus facile d'utiliser un outil de test de documentation pour le moment.
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.la source