Au cours des deux dernières décennies, la technologie et les choix dont nous disposons en tant que développeurs ont évolué très rapidement.
C’est ahurissant de réfléchir aux changements dramatiques dans le génie logiciel à Chariot Solutions, fondée en 2002, ainsi que dans l’ensemble de l’industrie à cette époque. Au début du nouveau millénaire, les smartphones n’étaient qu’une étincelle dans les yeux des ingénieurs.
Qu’est-ce qui a changé en 20 ans ?
Considérez le paysage lorsque Chariot a commencé. Notre équipe écrivait beaucoup de code Java 1.4 (ou antérieur), développait dans des IDE tels que JBuilder, NetBeans et Eclipse, déployait sur des serveurs d’applications propriétaires (Tomcat et l’open source étaient un luxe pour les entreprises qui adoptaient le mouvement open source qui se répandait rapidement) , et en utilisant des API comme Hibernate et Struts lorsque nous pouvions les faire approuver.
Il existait de nombreux logiciels propriétaires, des bases de données telles que Microsoft SQL Server, Oracle et Sybase, aux serveurs d’applications coûteux tels que WebSphere et WebLogic, en passant par les systèmes de contrôle de version commerciaux tels que ClearCase, PVCS et Source(un)Safe. Les livres et les manuels étaient partout. Il n’y a pas eu de Stack Overflow. En bref, vous avez dû faire beaucoup de lecture et d’expérimentation pour monter de niveau.
Quelques temps forts à retenir :
- Java 2 Standard Edition 1.4 a été récemment publié
- Les Jakarta Commons et Tomcat ont été établis et très occupés
- Hibernate était nouveau – il n’avait qu’un an !
- Mac OS 10.2, alias Jaguar, venait de sortir
- Jira vient d’être présenté
- Amazon vendait des livres en ligne ; AWS était encore à quatre ans
- Les gens essayaient toujours de créer des interfaces graphiques Java, mais les applications Web (et éventuellement mobiles) rendaient cela inutile
- Le téléphone le plus intelligent disponible était le Handspring Treo – un PalmPilot et une monstruosité de téléphone portable !
J’ai été chez Chariot pendant 15 des 20 dernières années, et bien qu’il soit impossible de résumer complètement, mon temps a permis de réfléchir aux grands changements.
Estimation et gestion de projet
Ken Rimple.
La plupart des équipes d’ingénierie logicielle n’exécutent pas de projets de développement logiciel comme elles le faisaient en 2002. Elles n’utilisent plus beaucoup les diagrammes Microsoft Project GANTT, car il est très difficile de savoir combien de temps les tâches individuelles prendront en amont. Vous devez comprendre suffisamment bien les exigences pour estimer les, et c’est rarement possible, vous mettez donc constamment à jour un plan de projet Microsoft très détaillé, et il se diversifie rapidement de la réalité, au point d’être inutile.
Les petites équipes peuvent développer des logiciels plus utiles en publiant à plusieurs reprises de petites mises à jour pour s’attaquer à des histoires plus petites. Au fur et à mesure que le projet réduit les exigences plus importantes, nous parvenons à une meilleure compréhension et les clients obtiennent réellement ce dont ils ont besoin.
Aujourd’hui, la plupart des organisations utilisent une sorte de processus de développement itératif avec des méthodologies légères comme Kanban, Agile ou Scrum. L’estimation est toujours difficile, mais les efforts à grande échelle ne choisissent généralement plus autant une date de livraison finale, car les équipes qui se développent progressivement obtiennent des commentaires et une compréhension en cours de route. C’est une énorme amélioration.
L’open source est désormais la norme. Il n’en a pas toujours été ainsi
En 2002, nous devions encore justifier l’open source sur nos projets. Nous avons même eu une série de blogs et de podcasts à ce sujet, jusqu’en 2010. L’open source commençait tout juste à prendre pied dans certains projets, et il ne faisait que remplacer les serveurs propriétaires (vous vous souvenez de WebSphere ?) et les API (je vous regarde, WebLogic Intégration) quelques années plus tard.
En Java, le Spring Framework a accéléré l’adoption de l’open source en 2004 (pour le contexte, vérifier une brève leçon d’histoire de Spring Framework avec Rod Johnson et son travail sur Scala en 2012). De nos jours, nous ne clignons même pas des yeux lorsque nous sélectionnons une API open source plutôt qu’une commerciale. La principale préoccupation est de choisir ceux qui conviennent. (Découvrez ce podcast mettant en vedette Joël Confino en 2010 sur la sélection d’un projet open source. Certaines choses ne changent jamais.) Il est important d’en trouver un qui est stable et qui a suffisamment de support et d’utilisation pour que vous n’ayez pas à vous soucier de sa mort juste après avoir commencé à l’utiliser.
Automatisez toutes les choses (si possible !)
Les meilleures équipes d’ingénierie sont multidisciplinaires, impliquant régulièrement des développeurs aux compétences variées, des testeurs, des experts métier et des parties prenantes. La plupart des équipes automatisent également les builds, les tests, les déploiements d’applications et surveillent les plates-formes pour évoluer en fonction de la charge. Une excellente conférence sur le fait d’être un programmeur pragmatique a été donnée lors de notre Philadelphie ETE 2017 par Andy Hunt et il plonge dans la criticité de l’automatisation, des tests et de la CI.
C’est un monde polyglotte
En 2002, la majeure partie de l’industrie se concentrait sur Java et .NET.
Aujourd’hui, nous avons une prolifération de langages, de frameworks et de plates-formes, le déploiement dans le cloud devenant de rigueur. Les machines virtuelles de la vieille école étaient courantes, mais désormais, les conteneurs de Docker/Kubernetes isolent les logiciels en services, plutôt que des machines virtuelles complètes, ce qui facilite la mise à l’échelle de certaines parties de votre plate-forme en cas de besoin. Pour un bon aperçu de certaines des options à l’époque – depuis lors, les performances de Lambda ont augmenté et les démarrages à froid peuvent être atténués un peu plus facilement – consultez Chariot’s Keith Grégoire sur le choix de la bonne infrastructure informatique AWS à partir de 2019.
Le mouvement sans serveur promet de supprimer les plates-formes et de vous permettre simplement de déployer du code sans gérer la plate-forme elle-même. Comme exemple de la façon dont nous abordons les technologies émergentes, nous voyons de la valeur dans les endroits où cela facilite la vie du développeur ou du client (des services tels que Serverless Databasing avec l’API Aurora Data, 2021 Serverless RDS sur AWS est un excellent exemple), et avec l’œil vers l’endroit où il est le plus pratique, pas comme un marteau pour enfoncer chaque clou (voir ma propre vision sceptique sans serveur, sans Schmerverless du sans serveur pour tout dans mon 2021 DevOps de la banlieue de Philadelphie discussion de rencontre).
Oh, et curieusement, LISP n’est pas mort. La langue perdure, mais a été repensée par Riche Hickey en tant que plate-forme Clojure : un langage et une plate-forme inspirés de Lisp qui s’exécutent dans la machine virtuelle Java (entre autres). Pour ceux qui veulent utiliser des techniques de programmation fonctionnelle vieilles de 50 ans qui sont encore pertinentes aujourd’hui, consultez ClojureScript à l’ère du texte dactylographié, une conférence de Philly ETE 2021 par le légendaire David Nolen sur ClojureScript.
Les applications mobiles n’existaient même pas en 2002
En 2002, les téléphones étaient pour la plupart des téléphones, et ils pouvaient avoir un carnet d’adresses, un calendrier et une liste de tâches.
L’iPhone, iOS puis Android ont fait exploser les portes à leur arrivée sur les lieux. Chariot a sauté au début, avec une équipe de développeurs qui ont adopté, appris, puis finalement consulté d’abord avec iOS, puis Android, pour produire des applications pour nos clients.
Ces plates-formes ont énormément évolué au fil des ans, changeant de langage (iOS d’Objective-C à Swift, Android de Java à Kotlin), subissant de nombreux changements dans leur langage de conception, leurs outils, leurs SDK et leurs fonctionnalités), ce qui a conservé notre équipe mobile sur leurs jouets depuis plus d’une décennie maintenant.
Nous surveillons les plates-formes d’applications Web mobiles non natives telles que React Native et Flutter, et avons utilisé des outils tels que PhoneGap et Ionic où des interfaces utilisateur légères et simples sont nécessaires pour interagir avec du matériel spécialisé.
Les 20 prochaines années…
Ce bref retour en arrière peut aider les développeurs actuels et les entreprises qu’ils servent à comprendre le paysage du développement logiciel dans le passé, le présent et le futur. Que vous soyez développeur ou que vous aidiez vos développeurs à prendre des décisions techniques, le changement se produit à grande vitesse. Comme Steve Jobs a déclaré dans son discours d’ouverture de Stanford: «Vous ne pouvez pas relier les points en regardant vers l’avenir; vous ne pouvez les connecter qu’en regardant vers l’arrière.
-30-