Les langages dynamiques sont-ils défavorisés pour le développement agile?


12

D'après ce que j'ai lu, le développement agile implique souvent une refactorisation ou une ingénierie inverse du code dans des diagrammes. Bien sûr, il y a bien plus que cela, mais si l'on considère les pratiques qui s'appuient sur ces deux méthodes, les langages typés dynamiquement sont-ils défavorisés?

Il semble que les langages de type statique rendraient le refactoring et la rétro-ingénierie beaucoup plus faciles.

La refactorisation ou la rétro-ingénierie (automatisée) est-elle difficile, voire impossible, dans les langues typées dynamiquement? Que disent les projets du monde réel sur l'utilisation des langages typés dynamiquement pour la méthodologie agile?


5
Inverser le code d'ingénierie en diagrammes? Pourquoi feriez-vous cela dans Agile?
CaffGeek

7
Agile ne signifie pas «code d'abord, document plus tard».
Gort the Robot

@CaffGeek: Certains livres souvent recommandés suggèrent de dessiner des diagrammes sur un tableau blanc, puis de coder et enfin de désosser le code en diagrammes pour la prochaine réunion.
Gerenuk

1
Je pense que les caractères fortement tapés devraient être supprimés des balises et du texte de cette question. La question semble porter sur statique vs dynamique et non forte vs faible.
Winston Ewert

@WinstonEwert - Bon appel, j'ai changé les balises en dynamic-typingetstatic-typing
Carson63000

Réponses:


11

Les langages dynamiques sont théoriquement désavantagés, toutes choses étant égales par ailleurs, car ils spécifient moins le fonctionnement du code (quelles sont les contraintes), et donc moins de refactorisation peut être effectuée automatiquement, et les problèmes qui surviennent ne peuvent pas être détectés automatiquement également .

Mais tout le reste n'est pas égal. Les langages dynamiques les plus populaires permettent un code très compact mais compréhensible, ce qui rend généralement leur développement plus rapide et rend la logique (qui peut changer lors du refactoring) plus facile à repérer visuellement. Donc, même si vous perdez un peu de l'avantage relatif de travailler dans un langage dynamique, vous pouvez toujours vous démarquer, surtout si vous prévoyez de faire votre refactoring à la main de toute façon.

D'autre part, il existe des langages typés statiquement avec essentiellement les mêmes avantages que les langages dynamiques (c'est-à-dire compacts et compréhensibles - avec des types principalement déduits, mais très présents): Haskell est peut-être l'exemple principal, mais OCaML / F #, Scala, et d'autres sont également dans cette catégorie. Malheureusement, étant donné qu'ils sont moins largement utilisés que les langages à typage statique les plus populaires, ils n'ont pas autant d'outils pour eux (par exemple pour le refactoring).

Donc, en fin de compte, je pense que vous ferez bien avec les méthodologies agiles dans la plupart des langues; Je ne dirais pas qu'il y a un gagnant clair en ce moment car la pratique n'a pas encore rattrapé la théorie.


Je pense que cette réponse répond le mieux aux points clés de la question :) Pourriez-vous également développer l'importance de la refactorisation sûre et de la rétro-ingénierie pour le développement agile? Je supposais que cela jouait un rôle très important? C'est peut-être moins que ce que je pensais et les outils pour le langage dynamique sont juste assez bons.
Gerenuk

1
@Gerenuk - Je n'ai pas suffisamment d'expérience en développement agile (en particulier dans les langages dynamiques) pour donner une réponse faisant autorité - l'aspect refactoring est-il sous-accentué, reste le même, etc.? Gardez à l'esprit que d'autres aspects communs du processus - le développement piloté par les tests, par exemple - peuvent aider à déterminer où votre refactoring a mal tourné, et si vous investissez un peu plus dans, disons, la phase de conception, vous n'aurez peut-être pas besoin refactoriser autant. Je ne pense pas qu'une technique particulière soit la clé - c'est de garder un ensemble complet d'outils à portée de main, déployés fréquemment et en collaboration.
Rex Kerr

14

Le refactoring automatisé a été inventé dans Smalltalk, un langage typé dynamiquement. Donc non, il n'est pas impossible d'avoir une refactorisation automatisée dans un langage typé dynamiquement. La difficulté dépend beaucoup plus d'autres facteurs que la discipline de frappe. C ++ et Java sont tous deux typés statiquement, mais les outils de refactorisation n'existent vraiment que pour Java. Smalltalk avec son introspection et sa syntaxe simple était un très bon candidat pour les outils de refactoring.

À certains égards, la frappe dynamique facilite la refactorisation. Si vous avez une bonne suite de tests, vous pouvez être sûr que vos refactorings n'ont rien cassé. Une base de code typée dynamiquement est généralement plus petite. En outre, les refactorisations ont tendance à affecter moins de code. Au total, l'effort de refactorisation manuelle d'une base de code dynamique est inférieur à celui d'une base de code statique.


1
Qu'en est-il alors de la rétro-ingénierie? Smalltalk est-il différent de Python en ce qui concerne la frappe? Il semble difficile de déduire tous les types en Python et de déterminer ainsi quelles méthodes sont vraiment identiques et pas seulement le même nom.
Gerenuk

2
Smalltalk n'est pas que très différent de Python en ce qui concerne la saisie. Elle est cependant sensiblement différente en ce qui concerne l' outillage . Les outils et IDE disponibles pour Smalltalk sont bien meilleurs que ceux disponibles pour Python ou même C #, C ++ et Java. La raison pour laquelle les IDE pour Python sont mauvais n'est pas parce que Python est typé dynamiquement, c'est parce que, eh bien, les IDE pour Python sont mauvais. N'oublions pas que l'IDE que nous connaissons maintenant sous le nom d'Eclipse était autrefois appelé VisualAge pour Smalltalk. La communauté Smalltalk a 40 ans d'expérience dans la création d'IDE, et ils l'appliquent à Java.
Jörg W Mittag

@Gerenuk, la frappe de Smalltalk n'est pas différente de celle de python. À d'autres égards, comme l'introspection, Smalltalk fournit un ensemble de fonctionnalités plus convivial pour le refactoring. L'inférence de type en python nécessiterait du travail, mais cela a été fait, voir le projet PyPy.
Winston Ewert

1
@WinstonEwert "mais vous pouvez refactoriser manuellement, et les langages dynamiques rendent cela assez facile" - Non, le refactoring manuel n'est pas à l'échelle. La prise en charge des outils de refactoring change tout même lorsque le refactoring n'est pas 100% automatique (voir les extraits de cas ci-dessous - programmers.stackexchange.com/a/166594/4334 )
igouy

1
Presque tous les points de votre "programmation dynamique facilitent réellement la refactorisation" sont douteux ou non séquentiels. La programmation dynamique ne signifie pas que vous avez une suite de tests plus complète, juste une plus grande (car certaines choses ont besoin de tests qui seraient autrement interceptés statiquement). Vous n'offrez aucun support pour "les refactorings ont tendance à affecter moins de code" (comme un ajout à "le projet est plus petit de toute façon", ce qui est probablement vrai étant donné la récolte actuelle de langages dynamiques). Et «l'effort impliqué dans la refactorisation manuelle» semble faux, sauf si vous voulez dire que vous ne laisserez même pas votre compilateur vous aider!
Rex Kerr

8

Le refactoring a été inventé dans les langages dynamiques. Les outils de refactorisation automatisés ont été inventés dans des langages dynamiques. Les IDE ont été inventés dans des langages dynamiques. Plusieurs méthodologies agiles ont été inventées dans des langages dynamiques.

Je ne vois vraiment aucun problème.


"Smalltalk n'est pas très différent de Python en ce qui concerne la saisie. Il est cependant très différent en ce qui concerne l'outillage." - Peut-être que cela commence à changer, voir jetbrains.com/pycharm/features/index.html
igouy

3

N'oublions pas que la façon de travailler "Agile", connue sous le nom d' Extreme Programming (XP), a été créée sur un projet Smalltalk (et Smalltalk compte certainement comme un langage "dynamique").

Voici une étude de cas d'utilisation industrielle d'un outil de refactoring fourni avec un langage typé dynamiquement:

Une très grande application Smalltalk a été développée à Cargill pour soutenir le fonctionnement des silos à grains et les activités de négoce de matières premières associées. L'application client Smalltalk possède 385 fenêtres et plus de 5 000 classes. Environ 2 000 classes de cette application ont interagi avec un cadre d'accès aux données précoce (vers 1993). Le cadre a effectué dynamiquement un mappage des attributs d'objet aux colonnes de la table de données.

L'analyse a montré que, bien que la recherche dynamique ait consommé 40% du temps d'exécution du client, elle n'était pas nécessaire.

Une nouvelle interface de couche de données a été développée qui obligeait la classe affaires à fournir l'attribut d'objet au mappage de colonne dans une méthode explicitement codée. Les tests ont montré que cette interface était plus rapide de plusieurs ordres de grandeur. Le problème était de savoir comment changer les 2 100 utilisateurs de classe affaires de la couche de données.

Une grande application en cours de développement ne peut pas geler le code alors qu'une transformation d'une interface est construite et testée. Nous avons dû construire et tester les transformations dans une branche parallèle du référentiel de code à partir du flux de développement principal. Lorsque la transformation a été entièrement testée, elle a ensuite été appliquée au flux de code principal en une seule opération.

Moins de 35 bogues ont été trouvés dans les 17 100 changements. Tous les bugs ont été rapidement résolus en trois semaines.

Si les modifications avaient été effectuées manuellement, nous estimons qu'il aurait fallu 8 500 heures, contre 235 heures pour développer les règles de transformation.

La tâche a été terminée dans 3% du temps prévu à l'aide de règles de réécriture. Il s'agit d'une amélioration d'un facteur 36.

de "Transformation d'une couche de données d'application" Will Loew-Blosser OOPSLA 2002

Aussi - "Outils pour faire des changements impossibles - expériences avec un outil pour transformer de grands programmes Smalltalk"


1

Vos principes me semblent corrects .

Les langages fortement typés comme C # sont de bons candidats pour une base de code qui a constamment besoin d'être refactorisée. Fondamentalement, la plupart des outils de refactorisation (comme Resharper, JustCode, etc.) sur le marché sont très efficaces dans les langages de programmation typés statiquement.

Que disent les projets du monde réel sur l'utilisation des langages typés dynamiquement pour la méthodologie agile?

Pour une équipe de développement qui pratique la méthodologie Agile / Scrum, il est très utile (même critique) d'avoir un bon ensemble d'outils de refactorisation sous armure. Sinon, tous les changements soudains dans le sprint à venir peuvent être un cauchemar à modifier ou à reconcevoir.

Ainsi, la méthodologie agile n'offre aucun avantage aux langages typés statiquement ou dynamiques une fois. Il offre une approche itérative pour créer une application solide.


4
Les langages dynamiques avaient des outils de refactorisation automatisés bien avant que C # n'existe, et quand le Bloc-notes était encore l'IDE Java le plus puissant.
Jörg W Mittag

4
Cette réponse n'est absolument pas étayée par mon expérience. Les langages dynamiques sont généralement plus rapides à faire que les langages plus conventionnels typés statiquement (je dois apprendre Haskell ou ML ou quelque chose comme ça parfois). Ils sont également beaucoup plus rapides à modifier en cas de besoin soudain, ce qui m'a conduit à conclure que Common Lisp était le meilleur langage lorsque vous ne saviez pas vraiment ce que vous faisiez. De plus, où pensez-vous que le refactoring a commencé?
David Thornley

1
pourquoi le pensez-vous, par exemple javascript est un langage dynamique, mais Re-sharper ne fait pas le même travail astucieux qu'avec C #. Deuxièmement, je n'ai PAS dit que "les langages dynamiques sont plus lents à faire les choses".
Yusubov

D'après les personnes qui vous ont apporté IntelliJ IDEA - PyCharm - "Renommer le refactoring permet d'effectuer des changements de code globaux en toute sécurité et instantanément. Les changements locaux dans un fichier sont effectués sur place. Les refactorisations fonctionnent dans les projets Python et Django simples. Utilisez Introduce Variable / Field / Constant et Inline Local pour améliorer la structure du code au sein d'une méthode, Extract Method pour décomposer des méthodes plus longues, Extract Superclass, Push Up, Pull Down et Move pour déplacer les méthodes et les classes. " jetbrains.com/pycharm/features/index.html
igouy

@igouy, je fais référence à Resharper et JustCode dans ma réponse. Ainsi, c'est vrai pour le contexte auquel il est fait référence.
Yusubov
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.