3 conseils pour appliquer « Mesurer deux fois, couper une fois » au génie logiciel

Il y a un dicton que j’ai appris quand j’étais jeune : « Mesurez deux fois, coupez une fois. C’était un sage conseil que j’entendais souvent lorsque je construisais quelque chose avec mon père ou lorsque j’étais sous la tutelle d’un ingénieur senior au club de robotique. L’idée est que nous devrions toujours vérifier l’exactitude de nos plans avant de procéder à la mise en œuvre ; sinon, une erreur pourrait être commise qui gaspillera non seulement des matériaux mais aussi du temps. Malheureusement, suivre ce vieux conseil proverbe est aléatoire au sein de la communauté du logiciel, ce qui ne se traduit pas par un gaspillage de matériel mais par beaucoup de temps perdu. Dans l’article d’aujourd’hui, examinons trois conseils pour mieux planifier en génie logiciel afin d’éviter de perdre du temps.

Adobe Stock

Astuce n°1 – Développer une architecture logicielle

Je sais que je parle beaucoup d’architectures logicielles, mais c’est parce que j’ai découvert que cela m’aide considérablement à planifier mes conceptions et à minimiser le temps et les coûts de mon cycle de développement logiciel. Il n’y a pas que moi. J’ai également constaté la même amélioration dans les efforts de mon client. L’architecture logicielle est le modèle du logiciel qui sera construit et contient tous les composants principaux, leurs entrées, sorties et interactions.

Je vais souvent travailler avec deux architectures logicielles différentes, l’une de haut niveau et abstraite de tout matériel et l’autre de bas niveau et prenant en compte les détails du matériel. L’architecture de haut niveau aide un développeur à concevoir la logique métier évolutive et flexible pour l’application. Il est complètement indépendant de tout matériel de bas niveau, accélérateurs et détails de langage. L’architecture de haut niveau est souvent à un niveau de détail qui permet aux ingénieurs non logiciels de comprendre et d’approuver ce qui se passe dans le système. L’architecture de bas niveau, quant à elle, devient un document que le développeur peut utiliser pour implémenter le logiciel. Il fournit des modèles de conception, des recommandations pour tirer parti des composants matériels pour améliorer les performances, etc.

Astuce #2 – Expérimentez avec les éléments de conception

Quand j’étais ingénieur junior, j’ai souvent découvert que je voulais juste me lancer et commencer à écrire le code. Ce n’était pas parce que je voulais sauter un élément important du cycle de conception, c’était juste que je ne savais pas ce que je ne savais pas et que j’avais besoin de creuser dans les détails pour formuler une solution appropriée. Je soupçonne que de nombreux développeurs ont l’impression qu’ils ne peuvent pas comprendre pleinement le problème jusqu’à ce qu’ils commencent à écrire du code et c’est un sentiment que même les développeurs expérimentés et expérimentés ont.

Toute solution nécessite plusieurs bibliothèques, composants middleware, pilotes, etc., pour lesquels il peut être difficile de créer une conception efficace sans d’abord se salir les mains. Les développeurs n’ont pas à passer directement à l’écriture de code de production, mais ils devront continuellement réécrire. L’alternative est de passer du temps à creuser dans les détails pendant que l’architecture logicielle est en cours de développement. Les développeurs peuvent facilement concevoir des expériences simples pour comprendre la surcharge d’un RTOS, la rapidité avec laquelle un pilote réagira probablement, etc.

Ces expériences secondaires ne doivent pas être considérées comme du code de production, mais plutôt comme des enquêtes rapides et sales conçues pour acquérir la compréhension nécessaire pour écrire correctement le logiciel de production.

Conseil n°3 – Tirez parti des méthodologies de conception agile

Les méthodologies de conception agile se sont enracinées dans de nombreux développeurs de logiciels et heureusement pour de bonnes raisons. J’ai trouvé que tirer parti des méthodes agiles telles que le storyboard et la planification de sprint était extrêmement utile pour la planification. Les logiciels prennent presque toujours plus de temps que prévu, mais l’utilisation d’un bon outil Agile peut aider les développeurs à comprendre la charge de travail, à enregistrer leur temps à mettre en œuvre des fonctionnalités spécifiques et à maintenir leur équipe à jour électroniquement (ce qui peut aider à réduire le temps perdu en réunions).

En parlant de réunions, ma réunion préférée pour les développeurs de logiciels n’est qu’un simple stand-up de 15 minutes. J’ai constaté que beaucoup d’équipes s’enlisent à tenir réunion après réunion, ce qui peut tuer la productivité. Minimiser les réunions et limiter les réunions à 30 minutes maximum peut aider une équipe à se concentrer sur le fait d’aller droit au but et de revenir à ses claviers.

Conclusion

D’après mon expérience, j’ai constaté que la mise en œuvre du logiciel et le développement des fonctionnalités sont beaucoup plus rapides et fluides si les équipes de développement (et moi-même) prenons le temps de concevoir d’abord et de mettre en œuvre ensuite. En d’autres termes, si je planifie soigneusement ce que j’écris, je constate que j’ai beaucoup moins de retouches à faire et je gagne du temps. Cela me fait également gagner beaucoup de temps de débogage! Les conseils que nous avons examinés dans cet article devraient aider le lecteur à commencer à mesurer deux fois et à couper une fois. Bien qu’ils soient eux-mêmes de haut niveau, ils devraient susciter des idées sur les endroits où le lecteur peut chercher à creuser plus profondément.