Il y a vingt ans, je travaillais dans le domaine de la technologie, dix ans plus tard, je suis allé au poste de direction, et maintenant je suis retourné à la technologie, cette fois dans le rôle de consultant. Certains changements m'ont rendu très heureux, tandis que d'autres m'ont tout autant surpris. Ci-dessous, je parlerai brièvement des principales choses qui m'ont presque tué dans la fleur de l'âge.
Belle première: Unix et les développeurs réunis
Tout au long des années 1980 et au début des années 1990, la plupart des développements de logiciels professionnels ont été réalisés sur des postes de travail Unix coûteux tels que Sun Sparc ou NeXT. Dans les années 90, le marché a été capturé par WinTel et tout le monde a commencé à coder sur Windows en utilisant des outils de grands fournisseurs comme MS Visual Studio, ou quelques options gratuites comme Eclipse. Linux à cette époque était encore considéré comme quelque chose de plus pour les amateurs dans le monde du bureau.
En 2001, j'ai travaillé dans une startup. Il n'y avait qu'un seul développeur Linux pour toute notre équipe et il a eu du mal à couper l'accès aux outils de contrôle de version et au client de messagerie Outlook. Il nous envoyait généralement un code par lettres et nous demandait de le remplir. Je me souviens que j'avais moi-même utilisé XEmacs à l'époque - eh, le bon vieux temps.
Avance rapide vers le présent. Unix est devenu une plate-forme très populaire parmi les développeurs, en particulier ceux sur Mac, en raison du fait qu'il utilise le noyau Unix. De plus, il existe une chose telle que Linux sur Windows. A cet égard, contrairement à beaucoup d'autres, mon retour à l'informatique n'a pas été semé d'embûches. C'est drôle que beaucoup de mes jeunes collègues gèrent à peine Windows, et sous Linux, ils se sentent beaucoup plus confiants.
La gestion des versions n'est plus un métier
Il était une fois, la création de branches, la fusion et la résolution de conflits était un sacré travail qui nécessitait souvent l'intervention d'un spécialiste des versions dédié. À l'époque où ClearCase régnait sur le marché du contrôle de version, il y avait suffisamment de travail de fork, de fusion et de publication pour une grande équipe - du moins d'après mon expérience chez HP en 2002.
L'idée qu'un développeur puisse soumettre lui-même des demandes de modification est en fait assez récente. Apparemment, on lui a donné le début de la transition du développement vers Linux et une nouvelle vague de systèmes de contrôle de version distribués: BitKeeper, Git, etc. Les systèmes hérités tels que ClearCase, CVS, SVN ou PerForce n'avaient pas la capacité d'apporter leurs propres modifications afin qu'elles soient reflétées dans toutes les personnes impliquées dans le flux de travail. Soit le propriétaire du référentiel l'a fait, soit la personne en charge de la gestion des versions, soit chaque développeur a tout organisé pour lui-même. Maintenant, le processus a été grandement simplifié, et il est maintenant possible d'établir un travail conjoint en équipe sans participants supplémentaires.
Où sont les équipes QA? Tests unitaires et intégration continue
J'ai entendu parler pour la première fois des tests unitaires et de l'intégration continue par Kent Beck, l'un des auteurs du Manifeste Agile et créateur de la méthodologie de programmation extrême . Il y a vingt ans, ses idées étaient révolutionnaires, mais elles n'ont pas immédiatement atteint le statut de norme en développement qu'elles ont maintenant.
À mon avis, c'est dommage qu'il n'y ait plus l'accent sur l'intégration continue dans Agile et Scrum. Mais je suis déjà heureux que cette pratique soit devenue très populaire aujourd'hui. J'ai assisté à cette conférence et je me souviens que Joshua Bloch, auteur de Java Collections, est monté sur scène pour parler d'intégration continue, et il a dit: "Merci (Agile ou JUnit) d'avoir donné un charme à l'intégration continue." Et il avait raison. Autrefois, écrire des tests était considéré comme ennuyeux et peu de gens le faisaient. Par conséquent, les patrons ont embauché des personnes spéciales, des ingénieurs QA, qui recherchaient des erreurs pour les développeurs! Devenez fou, cette lafa était ...
Les tests unitaires et l'intégration continue ont presque éliminé le besoin de ces personnes - maintenant, les développeurs sont responsables de l'écriture des tests eux-mêmes, et l'infrastructure d'intégration continue lance tout à temps et signale les erreurs. Cela rend le logiciel plus fiable et raccourcit le cycle de développement. En outre, les innovations ont aidé les développeurs à acquérir une vision plus holistique des choses et à apprendre à écrire du code afin qu'il puisse être facilement testé.
Docker: plus de désordre sur le chemin de la production
Les conteneurs, à savoir Docker, ont supprimé tous les éléments inutiles de la gestion des packages et minimisé les problèmes environnementaux qui surviennent lorsque le code passe les tests et entre en production. Auparavant, cependant, vous devrez faire appel à un bon ingénieur DevOps pour configurer l'écosystème Docker.
Dans l'ancien temps, il arrivait que le système ait été créé dans un environnement complètement différent dans lequel il était censé être déployé (enfin, c'est-à-dire, par exemple, ils écrivaient du code sur Windows et déployé sous Unix). Cela a inévitablement causé des bogues et accumulé du travail supplémentaire à chaque cycle de test-version.
De plus, dans le passé, un spécialiste des versions, des tests ou du DevOps prenait le code d'une balise dans le contrôle de code source et décidait quoi faire de la compilation, des tests et de la migration. Habituellement, cela révélerait tout un tas de chemins et de variables codés en dur, des bibliothèques manquantes et des fichiers qui devaient être retravaillés ou modifiés pour fonctionner correctement.
Docker a simplifié le processus et créé les conditions d'une intégration continue et d'un déploiement continu en remettant, encore une fois, les fonctions pertinentes entre les mains des programmeurs.
Open Source: trop de possibilités
Dans le monde des logiciels open source, le choix est désormais, franchement, en abondance. J'étais en train d'installer Jenkins ici et je voulais l'intégrer à BitBucket. Une recherche de plugins pour «bitbucket» a donné plus de quatre cents résultats, dont beaucoup sont open source.
Cela crée deux problèmes:
- Il est plus difficile de choisir parmi un grand nombre d'options
- Avec une telle abondance, certains des instruments s'éteindront définitivement et leur soutien cessera.
Mais il y a aussi des avantages: il n'est presque pas nécessaire de créer vous-même l'infrastructure et les outils de base - trouvez ce dont vous avez besoin dans le prêt à l'emploi et utilisez-le. Il y a vingt ans, vous deviez écrire des bibliothèques et des structures de données pour les opérations les plus courantes, et c'était même amusant quelque part. Aujourd'hui, il existe tellement de bibliothèques et de frameworks différents pour chaque langage que 99% des développeurs peuvent vivre sans écrire un seul B-tree, ou table de hachage, ou même un connecteur OAuth.
Agile et Scrum ont conquis le monde
Il y a vingt ans, Agile était déjà bien vivant (le Manifeste Agile est sorti en 2001), mais sa popularité a commencé à croître plus tard - y compris en dehors de l'informatique, et parfois sous une forme déformée. Il est devenu un adage favori dans les cercles de direction: «Les entreprises doivent rester agiles, sinon elles ne survivront pas».
Je me souviens des moments où le cycle de publication a duré assez longtemps (trois mois, et c'est dans une startup). Après son retour de la réunion, au cours de laquelle il a analysé les spécifications ligne par ligne, le développeur pouvait s'asseoir à la table et jouer tranquillement pendant plusieurs semaines sans craindre de devoir rendre compte de la façon dont les choses allaient. Et maintenant, tous les jours des rallyes debout, des sprints toutes les deux semaines - vous ne pouvez pas vraiment vous détendre!
Agile a également redistribué les fonctions administratives - les développeurs communiquent désormais directement avec les utilisateurs ou les chefs de produit. Asseyez-vous en silence ne fonctionnera plus. En conséquence, la capacité de communiquer est devenue beaucoup plus précieuse qu'auparavant.
Enfin, le rythme de développement s'est accéléré avec Agile. Il ne s'agit même pas de réunions debout et d'autres entreprises Scrum. Les outils eux-mêmes ont commencé à nous faire gagner du temps: tableaux blancs dans Jira, demandes de changement, outils de développement et de déploiement continus - tout cela permet de travailler plus rapidement. D'une part, cela ajoute aux soucis quotidiens, et d'autre part, vous ressentez le retour sur le fait que vous déployez les produits en peu de temps et accomplissez les tâches de manière globale.
Pour terminer
Si vous avez également quitté IT et que vous pensez revenir, je vous soutiens et vous souhaite bonne chance. Personnellement, j'ai volontiers mis à jour mes compétences (même si j'ai failli mourir en cours de route). Les principes fondamentaux de la programmation sont restés les mêmes, donc je pense que je vais y arriver d'une manière ou d'une autre. Mais la boîte à outils a beaucoup changé, ce qui affecte la productivité.
Vous avez probablement attrapé un thème récurrent dans l'article: un développeur moderne a un éventail de tâches beaucoup plus large qu'il y a vingt ans. Il écrit du code, fait le contrôle de version, teste ce qu'il a écrit, travaille avec des conteneurs, etc. Bien sûr, le cerveau bout parfois, mais vous n'avez plus besoin de créer vous-même des listes chaînées.