La taille d'un projet rend-elle le déploiement plus risqué?
Je discutais ce point avec mon patron l'autre jour. Il affirme que plus la base de code est grande, plus le déploiement est risqué.
J'ai soutenu que ce n'était pas vrai, bien que je vois pourquoi il pourrait penser cela. D'après mon expérience, la taille de la base de code n'a pas d'importance si vous suivez des principes solides et avez de bons tests.
J'ai essayé de donner des exemples de voitures modernes et de leur fiabilité même s'il existe des milliers de pièces mobiles. C'est parce que chaque morceau fait son travail et seulement son travail et il le fait bien.
Suis-je fou, ou est-ce juste une de ces choses contre-intuitives que certaines personnes ont du mal à accepter?
Lorsqu'un produit logiciel classique prend de la taille au fil des ans, il y aura certainement plus d'endroits où les bogues peuvent se cacher et des occasions où des interactions plus complexes et imprévues peuvent se produire - c'est là que votre patron a raison.
D'autre part, les contre-mesures contre la dégradation de la qualité impliquent souvent encore plus de code sous forme de
tests automatisés,
déploiements automatisés,
plus de validations en produit,
gestion améliorée de la configuration,
générateurs de code
fonctionnalité redondante
couches de sécurité supplémentaires
etc. Et vous, cela nécessite également des améliorations de processus comme les révisions de code, les tests manuels, la documentation, etc.
Ainsi, le risque d'un déploiement (quoi que cela signifie) dépendra dans une certaine mesure de la taille de la base de code, mais pas seul - cela dépend aussi si votre système a trouvé le bon équilibre entre le code qui est nécessaire pour certaines fonctionnalités et le code pour soutenir ces autres mesures pour maintenir la qualité globale élevée.
"Suivre des principes solides et faire de bons tests" - comme vous l'avez écrit - est un bon début, mais loin d'être suffisant à long terme. Plus un système contient de fonctionnalités, plus il deviendra important d'appliquer tous les moyens connus d'assurance et de gestion de la qualité.
Donc, en bref: les deux perspectives que vous avez décrites contiennent une part de vérité, mais elles me semblent toutes deux trop simplifier les choses.
Disons que vous avez 1% de chances qu'un module donné ait un bug critique. Si vous avez deux modules qui doivent tous les deux fonctionner pour que votre système fonctionne, vous avez maintenant une chance de 1,99% de voir votre système tomber en panne. Si vous avez trois de ces modules, vous avez maintenant 2,97% de chances que votre système tombe en panne. C'est l'ingénierie de fiabilité de base.
J'ai simplifié à l'excès, mais le principal point à retenir est que la fiabilité du système est pire que la fiabilité de chaque composant critique individuel, et s'aggrave avec chaque composant critique supplémentaire. Si vous souhaitez augmenter la fiabilité d'un système, vous devez spécifiquement concevoir une défaillance d'un composant pour ne pas affecter le système dans son ensemble. Par exemple, en exécutant des services redondants sur des machines physiquement séparées.
L'exemple est pauvre
Une voiture moderne est compliquée mais très fiable pour la même raison que Lego peut fabriquer des structures compliquées tout en restant solidaires.
Ils sont tous deux limités aux interactions 4D.
Il y a bien sûr quelques autres principes en jeu tels que:
- Interfaces bien définies
- Produit en masse
- Assurance qualité des composants
Comparez cela au code logiciel. Le 3e, le 400e et peut-être toutes les lignes entre 2001 et 69876 peuvent influencer la variable A qui influence alors ...
La dimensionnalité étourdit l'esprit.
Maintenant, si vous écrivez du code et vous limitez aux faibles dizaines de dimensions, et implémentez d'autres principes comme: des interfaces bien définies, la production de masse et l'assurance qualité, vous pouvez en effet approcher les niveaux de fiabilité trouvés dans les voitures.
En fait, ces systèmes existent, comme l'avionique de vol dans les avions. Ceux-ci sont modulaires avec des interfaces bien définies, chaque module est lui-même redondant avec chaque doublon produit indépendamment par des équipes concurrentes, et l'assurance qualité est proposée à chaque composant et assemblage.
Risque
Votre patron a raison de supposer qu'une base de code plus importante est plus risquée, car cette ligne supplémentaire peut augmenter la dimensionnalité du logiciel. Une dimensionnalité plus élevée crée un espace de résultat plus grand dont la qualité doit être garantie.
Comme il n'y a que peu de temps dans le monde, seule une grande partie de cet espace de résultat peut être vérifiée. Plus cette différence est grande, plus la base de code est risquée, car il est moins probable que les opérations quotidiennes restent dans la région vérifiée.
Vous avez raison en ce que l'application de bonnes pratiques d'ingénierie vous permet de réduire la dimensionnalité interne et, par conséquent, la taille de l'espace de résultat. Il vous permet également de vérifier les régions de l'espace de résultat de manière plus fiable et plus rapide.
Je pense que vous pouvez également convenir que le code le plus fiable est le code qui n'existe pas.
Avec deux programmes par ailleurs égaux, le plus gros a évidemment plus de risques.
Mais quand avez-vous déjà deux programmes aussi bien programmés?
Ce que vous essayez de faire valoir, c'est que votre grand programme a été créé plus intelligemment que le programme moyen et qu'il manque une quantité proportionnelle de booboos.
Ce qui n'est probablement pas un argument convaincant pour un manager. Je vous suggère d'argumenter pour mesurer le risque en enregistrant les déploiements, les changements, les bugs, les retours en arrière, etc.