Blog
Réponse à l'article 'Software Should Be Easier To Build, Not Harder - My Dream For The Future Of Development'
Il y a quelques jours, l'architecte de la société dans laquelle je travaille m'a envoyé un lien avec comme commentaire "je trouve qu'il n'a pas tord". Le lien en question est un article écrit par un MVP, posté sur csharpcorner, qui, pour résumer, explique que Microsoft va dans le mauvais sens en rendant les logiciels de plus en plus complexes à développer (c'est très résumé, je vous conseille d'aller lire cet article si vous comptez aller au bout de celui-ci), mais l'idée principale est là.
Pour être honnête, je n'ai jamais fait de Visual Basic, donc je ne sais pas exactement de quoi il parle quand il fait référence aux VBX par exemple, mais j'ai connu les différentes solutions de "développement rapide" Microsoft, comme le Drag'n'Drop d'éléments en ASP.NET, ou les edmx, qu'il semble regretter, et je préfère de loin les solutions actuelles. De mon point de vue, les solutions permettant de développer plus rapidement ont toujours fait perdre bien plus de temps qu'elles n'en faisaient gagner, car elles n'étaient efficaces qu'au sein d'un périmètre restreint, dans des cas simples bien identifiés, et étaient complexes à adapter à des besoins spécifiques. Le drag'n'drop de composants et de sources de données n'étaient réellement productifs que pour des applications basiques de lecture/écriture de grilles de données. Une des idées principales de son article et que le développement d'applications avec les outils Microsoft est d'une complexité croissante au fil des années, reproche fait à Microsoft que je trouve injuste. Tout d'abord, je me souviens de projets en ASP.NET où les projets de réécriture/interprétation d'URL mobilisaient à eux-seuls des équipes entières, parfois pendant des semaines. Sur ce mêmes projets, il fallait gérer énormément de problématiques purement techniques qui n'avaient finalement aucune raison d'être, comme les postback, le poids des viewstate et j'en passe, autant de points d'attention sur lesquels il fallait garder une vigileance constante. Le MVC a été en soi une vraie révolution, car parfaitement adapté au développement web, il a enfin permit aux développeur de ne se concentrer que sur leur métier, évitant ainsi d'être pollué par tout un tas de complications sans aucune valeur ajoutée fonctionnelle. ASP.NET Core a continué dans cette direction en repensant le socle et proposant des briques techniques simplifiant considérablement le travail du développeur, le module d'injection de dépendance en est le meilleur exemple.
Certes, la plupart des applications sont plus difficiles à développer aujourd'hui qu'hier, mais le contexte n'est plus du tout le même qu'il y a 30 ans. Est-ce la faute de Microsoft si aujoud'hui, la plupart des visites web ont lieu depuis des smatphones, qui ont tous leurs caractéristiques propres ? Est-ce la faute de Microsoft si le parc hardware s'est considérablement enrichi, augmentant de manière importante la complexité d'un projet les adressant tous ? D'ailleurs, si c'est Microsoft qui était incompétent et allait dans le mauvais sens, une solution miracle aurait déjà vu le jour, ce qui n'est pas le cas. Je trouve qu'il a raison quand il dit que Microsoft s'éloigne progressivement, depuis plusieurs années, du RAD (Rapid Application Development), mais est-ce une erreur ? Personnelement je ne pense pas, bien au contraire. Les outils de Rapid Application Development amenaient toujours avec elles leur lot de contraintes et de limites, alors que les solutions actuelles vous permettent de bâtir exactement ce dont vous avez besoin. Il regrette les EDMX, alors que le model builder d'Entity Framework Core est tellement puissant. Certes, il ne fait pas de schéma et ne permet pas de modéliser un modèle de données uniquement avec des clics gauche/clic droits souris, mais il est à l'image des outils de développement Microsoft d'aujourd'hui, il vous permet de faire exactement ce que vous voulez, à condition de le maîtriser. Pour un schéma, il faudra aller voir ailleurs, mais il n'est pas fait pour ça, et pour ma part je trouve qu'un schéma n'a rien à faire là. Avec les outils de développement de Microsoft aujourd'hui, vous partez d'une page blanche, certes, mais vous allez où vous avez envie d'aller, de la manière qui vous plaît.
David McCarter termine son article en pointant du doigt la qualité de la documentation, une documentation pourtant assez fournie, bien organisée, et qui plus est open-source. Si vous lui trouvez un manque, vous êtes libre de le combler, à quoi bon râler ?
Moi aussi, mon rêve pour le futur du développement de logiciels est de voir naître un outil permettant en quelques clics de souris de mettre au point un logiciel complexe, compatible google chrome/android/iphone/ipad/freebox/windows tablet/windows10/firefox/montres connectées sans oublier les vêtements connectés mais à défaut de cela, avoir des outils me permettant de déveloper des logiciels en me concentrant uniquement sur les problématiques métiers, même s'ils nécessitent un peu de temps et de travail pour en comprendre le fonctionnement, est déjà un bon début. Concernant l'outil du début de phrase, je n'ai absolument aucun espoir; D'une part, il est certain que le parc hardware n'en est qu'au début de sa diversification et continuera de considérablement se développer et, d'autre part, je pense que comme c'est le cas avec les Hommes, les outils qui font tout, rapidement qui plus est, le font toujours mal.