Aperçu
- « Manges tes légumes! »
- « Faites du sport plusieurs fois par semaine !
- « Brossez-vous les dents et passez la soie dentaire tous les jours !
Telles sont les exhortations que chaque enfant a entendues (de nombreuses fois !) et qu’il a appris à détester. Cependant, ce ne sont pas des pratiques conçues uniquement pour faire souffrir : ce sont des encouragements pour développer et maintenir une bonne hygiène. Dictionary.com définit l’hygiène comme « une condition ou une pratique propice à la préservation de la santé, comme la propreté ». Un péché, « Si vous faites ces choses régulièrement, vous réduisez les risques que de mauvaises choses arrivent à votre santé à l’avenir.« Même si devoir continuer à se brosser les dents quotidiennement est une douleur, devoir faire arracher lesdites dents par le dentiste en raison d’une négligence de ces soins va être beaucoup plus douloureux !
C’est un concept qui peut être facilement appliqué à l’ingénierie logicielle. Les projets logiciels ont leurs propres aspects de maintenance en dehors des principales tâches de développement de code : documentation, gestion des dépendances, déploiement, etc. Soutenir ces aspects n’est peut-être pas le travail le plus excitant ou le plus stimulant sur le plan intellectuel, mais tout comme l’hygiène humaine, telle est la nature du soutien à l’hygiène d’un projet : ne pas le faire pourrait causer une douleur majeure au développeur à l’avenir. Ainsi, lors de l’élaboration des pratiques et des activités d’une équipe de développement de logiciels, essayez de prendre l’habitude d’élaborer un plan pour maintenir l’hygiène du projet via des activités planifiées régulièrement qui peuvent être intégrées au plan de développement du projet.
Notions
Dépendances
De nos jours, pratiquement tous les projets logiciels sont construits à l’aide de bibliothèques de logiciels externes : des frameworks tiers comme Spring ou Django au langage de programmation dans lequel le code du projet est écrit (Java, C++, Python, etc.). Ces bibliothèques externes, naturellement, sont elles-mêmes des projets logiciels ; dans la majorité des cas, les développeurs à l’origine de ces projets les maintiennent activement et publient de nouvelles versions du code à différents moments.
Points à considérer
- Comment l’équipe du projet saura-t-elle qu’une nouvelle version a été publiée pour l’une des dépendances logicielles du projet ? La vérification manuelle des nouvelles versions peut être un processus ardu ; des outils de détection automatisés comme Dependabot peuvent réduire ou éliminer ce type de labeur.
- Une fois qu’une nouvelle version d’une dépendance logicielle est publiée, quel sera le protocole pour évaluer quand l’intégrer au projet ? À l’exception des changements de rupture insolubles, une nouvelle version d’une dépendance logicielle doit être intégrée dès que possible pour un projet. Bien qu’il n’apporte pas de valeur immédiate au projet, il renforce l’habitude de maintenir le code du projet à jour conformément aux dépendances qu’il utilise. S’en tenir à une version plus ancienne d’une dépendance parce que « ça marche », c’est bien – jusqu’à ce que ce ne soit plus le cas. Un jour, l’annonce d’Internet peut arriver qu’il est absolument nécessaire de mettre à niveau ; soudainement, il pourrait être nécessaire de sauter plusieurs années de versions de dépendance. Ce qui aurait pu être une série de petits changements dans le code du projet de temps en temps est maintenant un grand ensemble de travaux non planifiés qui doivent être effectués hier.
Dépréciations
Comme mentionné ci-dessus, les logiciels sont souvent dans un état constant d’amélioration et de raffinement ; parfois, cela ne signifie pas uniquement ajouter du nouveau code et de nouvelles fonctionnalités, mais également supprimer du code et des fonctionnalités. Idéalement, les développeurs de logiciels indiqueront le code et les fonctionnalités qu’ils ont l’intention de supprimer en les marquant comme obsolètes.
Points à considérer
- Lorsque le code d’une dépendance externe est obsolète, quel sera le protocole pour le remplacer ? Considérez les drapeaux de dépréciation comme un geste de bonne volonté : les développeurs de la dépendance externe ont annoncé qu’ils apporteraient un changement de code qui nécessitera des changements dans le code qui utilise la dépendance, mais ils donneront aux utilisateurs externes le temps de préparer leur propre code pour le changement. Profitez de cette courtoisie et planifiez également comment et quand effectuer les ajustements appropriés, car une nouvelle version de la dépendance externe sera publiée dans laquelle ce code obsolète n’existera plus.
- Une fois qu’une dépendance logicielle est obsolète, quel sera le protocole pour la remplacer ? Parfois, la dépréciation se produit non seulement sur des parties spécifiques du code d’un projet logiciel, mais sur l’ensemble du projet lui-même. Un exemple en est la bibliothèque Hystrix de Netflix, pour laquelle la société a annoncé en 2018 qu’elle cesserait le développement actif. Lorsque de tels cas se produisent, il est conseillé de consacrer du temps à rechercher comment remplacer son utilisation dans le code d’un projet, principalement pour les mêmes raisons qu’avec les dépendances de code : éventuellement, un événement comme une vulnérabilité de sécurité annoncée peut obliger la mise à niveau, à laquelle les travaux deviendraient nécessaires mais n’auraient pas non plus été prévus.
Flux de travail
Le cycle de vie du développement logiciel contient de nombreuses étapes en plus du développement logiciel lui-même : test, code linting, déploiement, etc. Fréquemment, ce qui était autrefois des étapes qui nécessitaient une action manuelle pour être réalisées sont tombés sous la responsabilité de programmes logiciels à configurer puis à exécuter dans le cadre d’un processus automatisé. En effet, le concept d’automatisation des différentes parties du cycle de vie du développement logiciel – maintenant connu sous le nom de DevOps – s’est rapidement développé au cours de la dernière décennie pour devenir son propre cheminement de carrière.
Points à considérer
- Comment l’équipe déterminera-t-elle si des processus du workflow de développement peuvent être automatisés ? Les systèmes d’intégration/déploiement continus tels que CircleCI et Jenkins offrent déjà une multitude de fonctionnalités pour automatiser diverses parties du cycle de développement ; cependant, il existe parfois des possibilités de créer une automatisation supplémentaire dans un projet en dehors des environnements CI/CD. Par exemple, si un projet inclut le développement de plusieurs microservices, il peut être utile de consacrer du temps à rechercher si la création d’un équivalent local à un service d’initialisation programmatique comme Spring Initializer pourrait être utile.
- Comment l’équipe évaluera-t-elle si des étapes du flux de travail pourraient être réorganisées ? Même si une étape de vérification telle que le linting de code peut déjà être une partie définie du processus CI/CD automatisé, déplacer cette étape dans une partie antérieure du processus de développement pourrait réduire le temps d’exécution entre le développeur créant des modifications et découvrant si ces modifications pourraient Soyez améliorés. Git fournit des crochets dans lesquels il exécutera un script avant ou après une étape du processus Git ; dans ce scénario, l’étape de linting de code pourrait être exécutée dans le hook de pré-commit afin que le développeur soit immédiatement informé d’une odeur de code potentielle au lieu de recevoir ultérieurement un message du CI/CD.
- Si des parties du workflow de développement ont été désactivées, quand l’équipe réexaminera-t-elle si elles peuvent être réactivées ? Parfois, les étapes du cycle de vie du code ou du développement doivent être désactivées pour diverses raisons, par exemple une dépendance de test externe qui est soudainement devenue non fiable. Il devrait toutefois s’agir d’une mesure expressément temporaire. Si elle n’est pas résolue, la raison pour laquelle la mesure était censée être temporaire pourrait éventuellement être oubliée, et la mesure se figerait et deviendrait juste un autre « c’est comme ça » qui pourrait potentiellement empêcher la détection d’autres problèmes. Il est utile de planifier une vérification périodique de la base de code du projet et du processus de développement pour détecter si une mesure « temporaire » est effectivement devenue permanente de facto et ce qui devrait être fait pour résoudre le problème sous-jacent.
Documentation
Ah, écrire de la documentation – la tâche préférée du développeur de logiciels ! /s Cependant, même si le travail de documentation n’est peut-être pas la plus agréable des activités, les efforts finiront par porter leurs fruits. Les connaissances tribales (c’est-à-dire ne pas y avoir accès) et se retrouver du mauvais côté du bus sont deux obstacles potentiels à la productivité du groupe dans un projet, et plus la documentation produite pour le projet est importante, plus les risques d’obtenir entravée peut être atténuée, en particulier dans les cas où il n’est pas possible d’augmenter le facteur bus par des moyens « organiques » (c’est-à-dire en affectant plus de personnes au projet).
Points à considérer
- Comment et quand l’équipe évaluera-t-elle si un développeur n’ayant aucune connaissance du projet peut configurer son environnement uniquement en lisant la documentation du projet ? Sur les projets en cours de développement, la réponse peut toujours être « non » au sens le plus strict du terme, car les projets logiciels non triviaux auront suffisamment d’aspects pour qu’éventuellement *certaines* parties de la documentation deviennent obsolètes. Cependant, c’est un effort louable de s’efforcer d’obtenir autant de « oui » que possible, de peur que la mentalité de « il n’est pas possible de se tenir à jour, alors pourquoi s’embêter » s’installe et que la documentation vieillisse jusqu’à l’inutilité éventuelle. . Un bon exercice ici consiste à fournir à un développeur expérimenté sur le projet un environnement nettoyé et à lui demander de configurer son environnement via la méthode décrite ci-dessus ; ils auront l’expérience nécessaire pour savoir quelles lacunes dans la documentation doivent être comblées et où.
- Comment et quand l’équipe évaluera-t-elle si un développeur n’ayant aucune connaissance du projet peut apprendre à contribuer au projet uniquement en lisant la documentation du projet ?En lien avec le point ci-dessus, le processus de développement d’un projet peut différer des autres de multiples façons :
Etc. Bien que ceux-ci puissent être considérés comme des connaissances innées pour quelqu’un immergé dans le projet, ce ne le sera pas pour quelqu’un de complètement nouveau dans le projet. Une procédure pas à pas avec quelqu’un qui connaît le projet pour « montrer les ficelles du métier » aidera à inculquer ces connaissances au nouveau venu, mais cela a) prend du temps au développeur expérimenté qui pourrait être autrement…