7 pratiques de codage clés pour les développeurs agiles

Le développement de logiciels agiles ne concerne pas seulement les principes et les pratiques agiles. Pour réussir à publier un logiciel qui a un impact positif sur les utilisateurs finaux, résout la dette technique et se déploie de manière fiable, l'équipe de développement doit également tenir compte de ses pratiques de codage et de ses normes d'architecture qui favorisent l'agilité.

Une considération encore plus importante est en jeu pour les organisations technologiques. Aussi difficile que soit le développement de logiciels, il est encore plus difficile de déployer régulièrement des améliorations et des mises à niveau sur une période prolongée. Les pratiques Devops CI / CD et IAC (infrastructure as code) abordent en partie un facteur critique car l'automatisation permet des moyens fiables et reproductibles de déployer des applications. Ajoutez des tests continus, et les équipes de développement ont un moyen de valider que les modifications de code n'ont pas d'impact sur les fonctionnalités existantes.

Cependant, à mesure que les applications vieillissent, les développeurs d'origine passent à d'autres projets et parfois à d'autres entreprises. Lorsque de nouveaux développeurs rejoignent l'équipe, ils doivent apprendre l'architecture du logiciel et comprendre le code avant de pouvoir le modifier de manière fiable et efficace.

De plus, les développeurs qui créent des applications souhaitent souvent en développer de nouvelles. Il peut sembler confortable et sûr de rester attaché aux applications que vous développez, mais être attaché à votre code n'est pas sain pour votre carrière ou votre organisation.

La meilleure façon de passer à de nouvelles et passionnantes initiatives de développement logiciel est de rendre votre architecture, votre application et votre code facilement supportables par d'autres développeurs. Les équipes agiles et les développeurs doivent établir et appliquer des pratiques de codage qui soutiennent le développement logiciel continu.

1. Ne réinventez pas la roue

La première règle de codage: ne codez pas quelque chose qui n'a pas besoin d'être codé! Comment?

  • Pensez à poser des questions sur les exigences. Pourquoi une fonctionnalité est-elle importante? Qui en profite? Plus précisément, explorez les options non codantes pour résoudre le problème. Parfois, la meilleure solution n'est pas du tout une solution.
  • Un membre de votre organisation a-t-il déjà codé une solution similaire? Peut-être y a-t-il un microservice qui a juste besoin d'une amélioration ou une bibliothèque de logiciels qui a besoin d'une mise à jour mineure? Assurez-vous de parcourir la base de code de votre organisation avant de coder quelque chose de nouveau.
  • Existe-t-il des solutions tierces, y compris des outils SaaS abordables ou des options open source, qui répondent aux exigences minimales?
  • Avez-vous examiné les référentiels de codage ouverts tels que GitHub pour des exemples de code et des extraits de code qui répondent aux exigences de conformité de votre organisation?

2. Envisagez des options de développement low-code

Si vous avez besoin de coder une solution, alors peut-être que d'autres plates-formes low-code peuvent permettre de développer les capacités plus efficacement par rapport au codage dans des langages de développement tels que Java, .Net, PHP et JavaScript.

Les plates-formes low-code telles que Caspio, Quick Base, Appian, OutSystems et Vantiq fournissent toutes des outils pour développer des applications avec peu de code et parfois même sans codage du tout. Chaque plate-forme se spécialise dans différentes capacités et convient donc à une classe d'applications spécifique. Caspio, par exemple, facilite l'intégration de formulaires et de flux de travail dans des sites Web. Quick Base possède de solides capacités de flux de travail et d'automatisation, et l'architecture événementielle de Vantiq convient à l'IoT et à d'autres applications de données en temps réel.

Le codage est parfois nécessaire, mais les développeurs doivent également maîtriser une ou plusieurs options de développement à faible code et les considérer pour des cas d'utilisation appropriés.  

3. Automatisez les tests

Au-delà de l'écriture de code qui répond aux exigences, l'une des choses les plus importantes que les développeurs doivent faire est de le tester. Les pratiques de développement axées sur les tests et les outils de test automatisés ont mûri, et les équipes de développement doivent inclure les tests unitaires, de régression, de performance et de sécurité dans leurs estimations agiles.

En plus d'avoir des tests pour valider les versions et les versions, ces tests contribuent également à rendre le code plus supportable. Les tests sont de la documentation et établissent un contrat sur la façon dont le code est censé se comporter. Lorsque de nouveaux développeurs rejoignent des équipes et implémentent par inadvertance un mauvais changement, les tests continus interrompent la construction et fournissent des commentaires significatifs au développeur afin de résoudre rapidement le problème.

4. Externaliser tous les paramètres de configuration

Il ne devrait y avoir aucune excuse pour les développeurs de coder en dur les paramètres système, les noms d'utilisateur et les mots de passe, ou d'autres informations de configuration dans le code. J'ai vu des développeurs prendre des raccourcis tout en développant des prototypes qui se frayaient un chemin dans des environnements de production. Dans les architectures d'aujourd'hui, cela ne devrait jamais être fait. Le codage en dur n'est pas une dette technique mais une pratique de codage paresseuse et irresponsable qui peut avoir des conséquences importantes. Si le code devient accidentellement accessible, il crée une vulnérabilité de sécurité si les points de terminaison ou les informations d'identification d'accès sont exposés.

Pour aller plus loin, lorsque le code hérité est en cours d'élaboration, le traitement des configurations et paramètres codés en dur devrait être une priorité de dette technique non négociable.

5. Suivez les conventions de dénomination et incluez des commentaires pour rendre le code lisible

J'ai déjà travaillé avec un développeur incroyablement talentueux qui ne connaissait pas bien l'anglais et qui n'était pas le meilleur dactylo. Il instancierait des objets avec des noms comme a , b et c , puis créerait des variables locales nommées zz , yy , xx . Il s'engagerait à nettoyer cela avant la sortie, mais rarement suivi.

Vous ne devriez pas avoir besoin d'une programmation en binôme ou en foule pour reconnaître que c'est une pratique terrible.

Les équipes doivent adopter des conventions de dénomination telles que le JavaScript Style Guide de Google et le Java Style Guide et s'engager à commenter le code au moins au niveau modulaire et idéalement au niveau de la classe. En outre, les organisations devraient envisager d'utiliser des outils d'analyse de code statique qui fournissent des commentaires aux développeurs lorsque le code doit être refactorisé pour des facteurs de structure et de lisibilité.

6. Vérifiez fréquemment le code dans le contrôle de version

Si vous ne consignez pas le code dans le contrôle de version quotidiennement ou plus fréquemment, cela peut créer des conflits et d'autres blocages qui ont un impact sur l'équipe. Une petite erreur peut amener les équipes agiles à manquer leurs engagements de sprint ou à créer du travail supplémentaire pour résoudre les dépendances.

Les équipes doivent se mettre d'accord sur les conventions d'archivage du code qui n'est pas prêt pour la production. Les approches conventionnelles incluent les indicateurs de fonctionnalités et le branchement Git.

7. Évitez de coder les héros et les complexités

La plupart des développeurs que je connais sont devenus des ingénieurs logiciels professionnels parce qu'ils aiment résoudre les problèmes de codage. Le codage est un art, une science et un artisanat, et les meilleurs développeurs recherchent des attributions de codage stimulantes et des implémentations élégantes.

Sauf qu'il y a une ligne grise entre la résolution de tâches commerciales et techniques difficiles et le codage héroïque qui laissent aux prochains développeurs un code difficile à comprendre et compliqué à maintenir.

Pour ceux d'entre nous qui codent depuis un certain temps, nous nous souvenons de la commodité des one-liners Perl ou de l'utilisation de modèles imbriqués en C ++. Il y a parfois de bonnes raisons d'utiliser ces approches, mais si un nouveau groupe de développeurs ne comprend pas ces techniques, il est plus difficile de changer le code. Des pratiques de codage parfois simples mais moins élégantes sont meilleures.

Stimuler l'agilité dans le développement de logiciels agiles

Les rituels intégrés dans le développement Scrum et Agile, y compris les engagements, les standups, les revues de sprint et les rétrospectives, sont désormais des pratiques éprouvées pour permettre la collaboration en équipe et favoriser une mise en œuvre réussie. Mais pour faire preuve d'agilité sur une longue période, les développeurs doivent assumer des responsabilités et des pratiques de codage qui permettent un support et une extensibilité à plus long terme du code qu'ils développent.

Les équipes de développement doivent avoir une vision critique de leurs pratiques de codage. Ce n'est pas seulement assez bon pour une démonstration et une sortie aujourd'hui; il est également crucial de permettre aux autres de gérer facilement l'application et le code.