7 péchés du développement logiciel

Le problème peut être encore plus grave avec les informations personnelles telles que les dates de naissance ou d’autres détails. Certains domaines, tels que les dossiers financiers ou les dossiers médicaux, sont fortement réglementés, ce qui facilite le non-respect des règles.

Une bonne architecture logicielle implique une planification préalable pour minimiser la quantité de données stockées. Il protège tout le monde et peut réduire les frais de stockage, tout en accélérant même le système en réduisant la quantité de données en mouvement.

Externaliser le mauvais travail

Le débat sur la création ou l’achat de logiciels est un débat séculaire sans conclusion définitive. Pourtant, les développeurs de logiciels font souvent de mauvais choix. Peut-être qu’il existe une solution parfaitement bonne à un bon prix et qu’ils sont trop fiers pour mettre de côté leur pile personnalisée avec son équipe interne coûteuse. L’inverse se produit également. Certains gestionnaires achètent la gamme de produits d’un fournisseur externe uniquement pour voir le fournisseur augmenter considérablement les prix une fois le verrouillage terminé.

Malheureusement, décider quels outils externes utiliser constitue un défi constant pour les équipes de développement de logiciels et leurs responsables. Embaucher la bonne source extérieure est génial, mais adopter le mauvais fournisseur est un ticket pour une prison au prix élevé.

Éviter les tests

Les développeurs de logiciels efficaces et leurs responsables savent que les tests constituent un défi constant et font tout autant partie du travail que l’écriture de code récursif ou la conception d’une structure de données élégante. Les tests doivent être inclus dès le début, car les tests unitaires et les tests d’intégration sont essentiels pour garantir la viabilité du code tout au long du processus de développement.

Mais les tests sont également importants pour la manipulation de charges importantes. Il est trop facile d’écrire du code qui fonctionne correctement sur notre bureau lorsque nous sommes le seul utilisateur. Si l’application compte des centaines, des milliers, voire des centaines de milliers d’utilisateurs, vous devez vous assurer que le code est efficace et que le déploiement est capable de gérer une grande échelle.

De nombreuses équipes font appel à des testeurs d’assurance qualité qui surveillent les types d’erreurs commises par les programmeurs. Ils savent, par exemple, mettre un paramètre à zéro juste pour voir s’il provoque une erreur de division par zéro. Ils savent qu’il faut acheter 3,14159 chemises ou -4000 chaussettes juste pour voir si cela enfreint le code. Cette attention portée aux tests est essentielle lorsque les cas d’utilisation deviennent si compliqués qu’il est difficile pour un seul humain de penser à toutes les variantes et d’écrire un code propre qui les anticipe toutes.

Sous-estimer le pouvoir de la planification

La plupart du code nécessite une certaine dévotion à la planification. Hélas, la plupart des codeurs veulent souvent simplement se lancer et lancer du code de mitraillage.

Un de mes amis me dit qu’il lui a fallu plusieurs années pour reconnaître que la meilleure étape est de s’arrêter, de planifier, de tester les plans et de planifier encore. Rédiger des plans peut sembler fastidieux, mais il peut être 10 fois plus rapide d’essayer des idées en pensant de manière abstraite. Il est désormais un manager très performant.

Planifier signifie également inclure la contribution des autres équipes et parties prenantes. Ce seront eux qui utiliseront le code à l’avenir, donc passer du temps à discuter du projet et à connaître leurs besoins évitera bien des frustrations par la suite. C’est la meilleure façon d’éviter bon nombre des péchés énumérés ici.