Comme l'a justement remarqué le légendaire écrivain Jules Verne: "Un minimum bien utilisé est tout à fait suffisant." À notre époque, le concept d'un minimum bien utilisé s'applique au code. C'est triste, mais vrai: dans le monde moderne du code, il y en a trop. Pour être plus précis, il y a trop de code inutile, parmi lesquels le code utile suffoque simplement.
Compte tenu de ce qui précède, le code inutile est mauvais par défaut. Il se détériore avec le temps. Cela nécessite un soutien continu. Il contient des bogues que vous devez rechercher. Lorsque de nouvelles fonctions apparaissent, l'ancien code doit leur être adapté. Plus vous avez de code, plus il peut y avoir d'erreurs. Plus la vérification ou la compilation prend de temps, plus le nouvel employé comprendra votre système.
Et en plus de tout ce saut, le code est écrit par les programmeurs. Plus c'est, plus il faut de programmeurs. À mesure que le nombre de programmeurs augmente, le coût de la communication entre eux augmente, ce qui contribue davantage au coût de développement et de maintenance du code.
Pour tous ces problèmes, il existe une solution: écrire moins de code. Cette approche présente de nombreux avantages:
- Moins de code à développer = moins de coûts de développement
- Moins de code en développement = moins de coûts de maintenance
- Moins de code en développement = moins de bugs
- Moins de code à développer = tests plus efficaces
Et le plus important: moins vous forcez les gens à lire du code, plus il y a de chances que quelqu'un le lise.
Voici quelques façons de réduire le code.
Le principe YAGNI («Vous n'en avez pas besoin»)
Le principe «Vous n'en avez pas besoin» (il est souvent appelé YAGNI - You Aint 'Gonna Need It) signifie la règle de programmation extrême suivante: «Ne réalisez telle ou telle opportunité que lorsqu'elle est vraiment nécessaire, et non pas lorsque vous supposez qu'elle sera bientôt nécessaire. " Même si vous êtes sûr à cent pour cent que cette fonction ne pourra pas être exécutée à l'avenir, ne commencez pas à l'implémenter maintenant.
Il y a deux raisons à cette pratique:
- Vous gagnez du temps en refusant d'écrire du code qui n'est pas actuellement nécessaire.
- La qualité du code s'améliore - vous ne le polluez pas avec des fragments basés sur des suppositions plus ou moins correctes et restez dans la base de code, même si ces suppositions ne sont pas confirmées.
Le concept de YAGNI est tout à fait raisonnable quelle que soit la méthodologie de gestion de projet à laquelle vous adhérez. Une bonne architecture nécessite un équilibre des possibilités bien équilibré. Une mauvaise architecture est composée d'un tas de fonctions esquissées qui génèrent une base de code que vous êtes tourmenté à prendre en charge.
La règle de base ici est la suivante: concentrez-vous sur ce qui est clairement nécessaire et ne pensez pas à ce qui risque de se produire.
N'écrivez pas de code invulnérable
Un code invulnérable est un code idéal, un code qui fonctionnera dans toutes les données d'entrée et toutes les conditions. L'idée de créer quelque chose de similaire a son propre attrait, en particulier pour les développeurs ambitieux qui perçoivent l'échec dans certains scénarios comme une insulte personnelle. Cependant, écrire (ou essayer d'écrire) du code invulnérable est une idée vide, car tout dans le monde a sa propre limite, et le code ne fait pas exception.
En essayant d'implémenter le module idéal, vous prescrirez des conditions supplémentaires, ajoutant ainsi de la complexité à la base de code, ce qui va à l'encontre de l'objectif même du code. Le module deviendra de plus en plus étendu au fil du temps, consommera plus de ressources et deviendra un candidat pour une maintenance négligente.
C'est pourquoi, si vous visez à écrire moins de code, vous devez vous efforcer d'obtenir la mise en œuvre la plus simple possible, à partir de la catégorie "si seulement cela fonctionnait".
Le Extreme Programming Guide mentionne deux règles d'or pour écrire du code simple:
- Tout d'abord, implémentez la nouvelle fonctionnalité de la manière la plus primitive qui puisse fonctionner. N'érigez pas de superstructures à couper le souffle, ne vous affinez pas - assurez-vous simplement que tout commence. Assurez-vous que le code passe des tests unitaires pour les nouvelles fonctionnalités (et pour les anciennes aussi, comme toujours).
- Ensuite - et c'est une partie critique de la règle - refactorisez le système et simplifiez le code autant que possible pour toutes les fonctions qui sont actuellement contenues dans le produit. Suivez le principe DRY et d'autres principes qui aident à rendre le système plus ordonné.
N'oubliez pas: nous ne recherchons pas le chemin le plus court, mais le résultat le plus simple.
En conséquence, nous commençons par diviser la méthode existante en plusieurs parties. Dans ce cas, les options de test fonctionneront sans échecs. Ensuite, nous changeons (dans le sens de la simplification) l'une des petites méthodes résultantes avec un œil sur l'option de test suivante et ainsi de suite.
N'oubliez pas que la simplicité est au cœur de l'élégance. La capacité de contrôler et d'éliminer une complexité inutile est une programmation magistrale.
N'aggrave pas le code
Cette règle peut être considérée comme le serment d'Hippocrate pour les développeurs. Les personnes impliquées dans la programmation entendent constamment des conseils pour ne pas couper les coins ronds et ne pas rechercher de solutions de contournement qui peuvent endommager le code et entraîner sa dégradation.
Les procédures de développement de logiciels, comme les procédures médicales, impliquent souvent des interférences grossières et des actions destructrices. De plus, les outils et techniques que nous utilisons sont souvent nouveaux et non vérifiés (ou insuffisamment vérifiés). De plus, nous n'avons pas d'analogue du Medical Licensing Council ou de l'Office of Product Control qui régirait les pratiques et les outils de développement que nous choisissons. Ainsi, nous exposons parfois notre patient, c'est-à-dire un logiciel, à des procédures associées à des risques inutiles, et nous ne comprenons même pas complètement ce que sont ces risques.
Parfois, dans le processus de résolution d'un problème, nous faisons plus de mal que de bien. Dans son livre "Perfect Code", qui fait partie de la littérature d'or pour les programmeurs, Steve McConnell écrit que si vous ne travaillez pas sur la racine du problème, mais sur son symptôme, vous ne faites qu'aggraver la situation - vous vous trompez, créant l'illusion que le problème est résolu .
Mais parfois, l'observation de cette règle peut être très difficile. Parfois, le code obsolète est dans un état tel qu'il est pratiquement impossible d'implémenter correctement de nouvelles fonctionnalités sans lui nuire. Par conséquent, pour être plus réaliste, vous devez reformuler un peu la règle: de "Ne pas aggraver le code" à "Si vous dégrade la qualité du code, vous devez être conscient de ce que vous faites".
C'est vrai. Si vous ne voyez pas un moyen d'implémenter les fonctionnalités nécessaires et de ne pas gâcher le code, prévenez les autres membres de l'équipe avant d'apporter des modifications. L'essentiel est que dans ce cas, vous dégradez la qualité du code intentionnellement.
Bien sûr, cela n'améliorera pas le mauvais code, mais de cette façon, vous aurez le temps de réfléchir à la situation. L'expérience montre que les gens n'atteignent souvent pas la solution optimale simplement parce qu'ils sont prêts à accepter la toute première idée qui leur vient à l'esprit. Notez que nous n'exigeons pas que vous demandiez la permission ou que vous aidiez à trouver la meilleure solution.
Un autre avantage de cette méthode est qu'elle réduit la probabilité de mauvaises surprises lors de mauvais moments - toute l'équipe sait à quels problèmes il faut s'attendre. Grâce à cela, vous pouvez travailler en équipe au sens plein du terme et faire face à cette situation en temps opportun.
Évitez les accès concurrents excessifs
La concurrence est une épée à double tranchant. Il ne doit être utilisé que si vous ne pouvez pas vous en passer.
Lorsque le code est exécuté séquentiellement, il est plus facile de comprendre et de rechercher des erreurs. Lorsque vous utilisez la simultanéité, les opérations sont effectuées simultanément ou dans un ordre déformé. Cette implémentation spécifique crée de nombreux problèmes d'identification et de correction des erreurs. Evidemment, cela complique l'architecture et l'implémentation de fonctions à la fois à plusieurs niveaux. Voici quelques problèmes que la concurrence concurrentielle mal implémentée peut provoquer:
- Condition de course: les opérations commencent à se produire de façon imprévisible
- Blocage mutuel: les objets impliqués se croisent en attendant la fin des opérations simultanées
- Manque de ressources: l'opération n'a pas accès de manière stable à la ressource nécessaire qu'elle attend
L'une des catastrophes les plus importantes associées au développement de logiciels a été causée précisément par des conditions interdépendantes incorrectement prescrites. Une erreur de programmation avec Therac-25, un appareil de radiothérapie, a entraîné la mort de quatre personnes.
Il convient de noter que la plupart des langages de programmation et des frameworks modernes fournissent des outils spéciaux pour le débogage de la concurrence. Mais, en fin de compte, tout dépend du développeur - c'est lui qui décide quand, où et comment les appliquer afin d'obtenir le meilleur résultat.
Ne heurtez pas la thésaurisation
La thésaurisation pathologique est un type de comportement caractérisé par la collecte d'un grand nombre de choses inutiles et la réticence à s'en débarrasser; cependant, les choses peuvent occuper la majeure partie de l'espace de vie, ce qui peut entraîner des blessures et du stress.
Lorsque les symptômes d'accumulation apparaissent chez les développeurs, ils commencent à s'accrocher à n'importe quel morceau de code, même s'il est déjà obsolète ou regorge de bogues. Ces développeurs ne suppriment jamais le code eux-mêmes et s'opposent généralement à cette pratique. Si vous leur en parlez directement, obtenez des réponses dans l'esprit: «Il pourrait un jour être nécessaire» ou «Sans cela, je ne peux pas effectuer l'opération X» et ainsi de suite.
Le syndrome de Plyushkin vous a-t-il déjà attaqué? Peut-être avez-vous abandonné l'idée de mettre les choses en ordre parce que vous comprenez que vous n'avez tout simplement pas assez de temps pour comprendre tout ce gâchis? Si c'est le cas, alors vous souffrez toujours de thésaurisation et le chaos total règne dans votre vie professionnelle.
L'épargne est irrationnelle. S'il vous semble que la présence d'un morceau de code est justifiée, mais que vous n'en êtes pas complètement sûr, marquez-le en conséquence pour pouvoir y revenir plus tard. Il ne sortira donc pas de votre mémoire. Quant au code, qui ne remplit pas un objectif précis et n'est pas vital, il doit être supprimé et le point.
Un bon programmeur travaille à améliorer le code de jour en jour, et au fil du temps, la qualité du code ne cesse de croître. Le code obsolète écrit par un bon programmeur se distingue toujours par sa précision - les professionnels ne laissent pas de gâchis après eux-mêmes; Après tout, le code est notre réputation et ce seront eux qui nous jugeront. Comme Robert Martin l'a dit à juste titre: "La vérité ne peut être trouvée que dans le code."