article.md 13KB
title: Le futur du développement logiciel slug: le-futur-du-developpement-logiciel date: 2007-10-30 17:11:42 type: post vignette: images/logos/readwriteweb.png contextual_title1: ★ Résolutions : rediriger, économiser et débattre contextual_url1: 20120131-resolutions-rediriger-economiser-et-debattre contextual_title2: ★ Résolutions : découvrir, concrétiser et transmettre contextual_url2: 20110112-resolutions-decouvrir-concretiser-et-transmettre contextual_title3: ★ Bilan après une année de freelance contextual_url3: 20090102-bilan-apres-une-annee-de-freelance
Voici une traduction de l'article intitulé The Future of Software Development écrit par Alex Iskold et publié sur Read/WriteWeb qui reprend les bases et qui va remotiver tous les développeurs qui me lisent ;-). Je manque de temps en ce moment pour publier mais il y a pas mal de choses en gestation qui devraient évoluer au cours de la semaine.
En 1975, Frederick Brooks a écrit un livre sur la gestion de projets informatiques intitulé The Mythical Man-Month (le mythe du mois-homme). Dans cet ouvrage, il démontre brillamment qu'ajouter des personnes à un projet de développement va le ralentir et non l'accélérer. La raison évoquée est qu'ajouter de nouvelles personnes induit une augmentation non linéaire du temps consacré à la communication.
Cinq années avant le livre de Brooks, une méthodologie du développement logiciel appelée le « cycle » en cascade (Waterfall model) est inventée. Cette approche applique les idées de l'ingénierie (mécanique, civile, etc) au logiciel. L'idée était de commencer par recueillir les spécifications, puis faire le design, puis l'implémenter, enfin le tester, et finalement obtenir un logiciel de manière linéaire.
Il a coulé beaucoup d'eau sous les ponts depuis et nous avons beaucoup appris dans le développement logiciel. Le modèle en cascade est maintenant désuet car il est trop rigide et irréalisable. Dans la vraie vie, les projets de logiciels sont mal définis et ont des fonctionnalités en constante évolution, ce qui ne permet pas de tout envisager dès le départ. Les meilleurs logiciels sont aujourd'hui développés et entretenus grâce à des méthodes agiles. Ces techniques permettent aux ingénieurs de réajuster constamment le logiciel en fonction du marché et des exigences des clients.
Avec l'avènement des langages de programmation modernes (Java, PHP, Python et Ruby), les nombreuses bibliothèques et un nombre sans précédent d'infrastructures de services comme Amazon, nous sommes arrivés à un nouveau pallier de l'évolution. Digg, del.icio.us, YouTube et les autres sont les enfants d'une nouvelle ère du web développée par une poignée de développeurs. Pour concevoir un logiciel aujourd'hui, vous n'avez besoin que de quelques bons développeurs. Dans cet article, nous retraçons l'historique de cette évolution et analysons les possibilités futures.
Pourquoi le modèle en cascade a-t-il échoué ?
Les néophytes pensent qu'une application est facilement modifiable. Comme ça reste relativement abstrait, les gens pensent que les logiciels peuvent être paramétrés et mis à jour en un claquement de doigts. Bien évidemment, ce n'est pas le cas. La conception, comme tout système mécanique, a un design et une structure ; ce n'est pas aussi simple que ça en a l'air.
Depuis toujours, l'accélération de l'économie requiert des modifications constantes des logiciels. Les anciennes méthodes de développement ne sont plus du tout adaptées au marché actuel. Lorsque l'on utilise le modèle en cascade, ces modifications sont impossibles, le cycle de développement est trop long, les logiciels sont des usines à gaz et finissent par coûter une fortune, pour le plus souvent ne pas fonctionner correctement au final.
Le problème c'est que le modèle en cascade est arrogant. L'arrogance vient du fait que nous pensions pouvoir concevoir l'application parfaite au premier essai. Le second problème, c'est que la vie d'un projet logiciel suit une évolution non linéaire. C'est en partant de ce constat que l'on s'est tourné vers les méthodes agiles de développement.
Les méthodes agiles ou l'évolution des logiciels
Au début des années 90, un bon nombre de méthodes de développement agiles ont vu le jour. Bien qu'elles diffèrent dans le détail, elles amorcent une réflexion profonde sur la manière dont doit être mené un projet de développement. Tout d'abord, les développements doivent être réactifs aux changements. Les besoins d'aujourd'hui peuvent évoluer, et l'industrie logicielle doit pouvoir répondre à une telle évolution. Pour y parvenir, les promoteurs de telles méthodes prônent le retour à la simplicité. Concevoir aujourd'hui un système simple qui satisfait les besoins actuels et prêt à s'adapter en fonction des exigences de demain.
Deux techniques, initiées par les méthodes agiles, doivent être prises en considération : la généricité et les tests. La généricité, élégamment décrite par Martin Fowler dans son grand classique est l'idée d'améliorer le design du code actuel sans en changer le résultat.
La généricité est ce qui permet aux systèmes agiles d'être évolutifs, tout en restant élégants. Tout comme un décorateur d'intérieur change constamment celui-ci et améliore votre vie quotidienne, les développeurs agiles agissent sur le cœur de l'application de façon à en améliorer la qualité globale. Le code est en constante mutation de façon à obtenir en définitive le plus simple et le meilleur système adapté aux besoins.
Pour s'assurer de la non-incidence de ces changements perpétuels sur le résultat final, les méthodes agiles ont introduit les tests unitaires. À chaque nouvelle extension du projet, la base de test grossit proportionnellement. Chaque test porte sur un unique composant du système et s'assure de la validité de son fonctionnement. Généralement, les tests sont lancés à chaque modification et requièrent une correction immédiate si un échec est signalé.
Les systèmes conçus à l'aide de méthodes agiles ont davantage de chances de réussir car ils sont évolutifs et adaptés au problème. Comme des organismes vivants, ces systèmes sont continuellement refaçonnés afin de s'adapter aux contraintes. Aucun doute là-dessus, les méthodes agiles ont eu un impact majeur sur notre manière de concevoir un logiciel aujourd'hui : dynamiquement et de manière continue.
L'utilisation des bibliothèques
Parallèlement à la découverte de nouvelles méthodes de développement, de meilleurs langages de programmation sont arrivés à maturité. C a été remplacé par C++, puis vint Java. Perl était génial, mais PHP et Python on su tirer parti de ses erreurs. Plus récemment est apparu Ruby, qui est devenu très populaire grâce à sa manière expressive de déclarer le code. En raison de cette évolution, nous disposons aujourd'hui de nombreux langages excellents et virtuellement équivalents. (NdT : je ne suis pas vraiment d'accord avec ce paragraphe mais les langages et les éditeurs, ça ne se discute pas...)
Alors que le choix du langage de programmation est un sujet sensible, en fait ça ne dépend pas à proprement parler du langage mais des bibliothèques qui font la différence. C++ n'aura jamais la bibliothèque standard que détient Java. Oui Java est le langage le plus simple mais les gens utilisent C++ depuis une décennie sans problème. Ce qui avantage Java, c'est la richesse de ses bibliothèques réutilisables. Et c'est la même chose pour PHP. Il a été le langage de prédilection des développeurs web grâce à ses bibliothèques dédiées au web et aux interactions avec les bases de données.
En plus des bibliothèques accompagnant ces langages modernes, le mouvement open source a aussi contribué énormément à l'infrastructure de développement logiciel. La fondation Apache a elle seule a produit énormément de briques réutilisables de grande qualité. Nous arrivons à une période où nous disposons des fondations solides pour bâtir des systèmes complexes. Nous avons les méthodes et les outils, et après ?
Le futur du développement logiciel : les petites équipes
Depuis les débuts du développement logiciel, les gens s'excriment afin de déterminer comment concevoir de bons systèmes le plus rapidement possible. De plus en plus de personnes se sont mises à plancher sur le problème, ne faisant qu'empirer les choses. Mais avec la récente explosion des applications web sociales nous avons assisté à la naissance d'un intéressant phénomène : une poignée de développeurs est maintenant capable de bâtir des systèmes utilisés par des millions d'utilisateurs. Comment est-ce possible ?
Le secret vient du fait qu'il ne faut que quelques hommes pour accomplir des tâches ardues. Avec un peu de discipline et une tonne de passion, de bons ingénieurs sont en mesure de concevoir des systèmes d'une grande complexité.
Équipés d'un langage de programmation moderne, de bonnes bibliothèques et de méthodes agiles, quelques développeurs intelligents dans leur garage arrivent tout simplement à faire beaucoup plus qu'une armée de développeurs médiocres.
Nous allons assister à des changements au cours des prochaines années :
- Les ingénieurs qualifiés et passionnés vont être très demandés et vont gagner beaucoup plus. NdT : comment ne pas être d'accord ?! ;-)
- Les développeurs qui n'ont pas des qualités de programmeur avérées vont devoir se recycler.
- Les changements qui sont en train de s'opérer dans le domaine des applications sociales va gagner le monde de l'entreprise.
- La délocalisation du développement va devenir désuette.
- L'informatique va devenir un domaine compétitif et prestigieux.
Conclusion
Ironiquement, on a fait le tour avec le mythe du mois-homme. Ce qui était vrai 20 ans auparavant est toujours vrai, mais pour d'autres raisons. Un environnement exceptionnel regroupant des langages et des bibliothèques combinés à des méthodes de développement agiles ont permis de briser les dogmes anciens du développement logiciel. Une poignée de bons développeurs peut dorénavant concevoir des systèmes d'une grande complexité. L'homme des cavernes est finalement arrivé jusqu'au développement logiciel !