Quelles caractéristiques ou fonctionnalités rendent le code maintenable?
J'avais l'habitude de penser que je savais ce que c'était, jusqu'à ce que je commence vraiment à y penser ... "maintenable" ... qu'est-ce qui rend le code maintenable exactement?
Pour moi, si le code doit être maintenable, cela signifie que nous pouvons nous attendre à revoir le code pour y apporter une sorte de changement à l'avenir. Le code est toujours "modifiable", quel que soit son état. Cela signifie-t-il que le code doit être facile à modifier? Cependant, si notre code était évolutif/extensible, il ne serait pas nécessaire de le changer directement, car il "changera" (s'adaptera) gratuitement et automatiquement.
J'ai également vu la maintenabilité du code utilisée de manière interchangeable avec les normes de codage. En utilisant un modèle ou un style de codage cohérent, cela rend-il vraiment le code plus facile à gérer? Plus lisible et plus cohérent? Bien sûr, mais comment cela améliore-t-il la maintenabilité?
Plus j'essaie d'y réfléchir, plus je suis confus. Quelqu'un a une explication appropriée?
La maintenabilité n'est pas une propriété binaire, qu'elle soit maintenable ou non. C'est un continuum. En gros, la maintenabilité est inversement proportionnelle à la quantité de temps qu'il faut à un développeur pour effectuer un changement et au risque que ce changement casse quelque chose. L'amélioration de la lisibilité, du couplage ou de la cohérence contribue à la maintenabilité, car il ne faudra pas autant de temps pour effectuer un changement donné. La maintenabilité est plus facile à reconnaître par son absence, comme lorsque quelque chose que vous pensiez devoir prendre une heure finit par prendre une semaine.
Les normes de codage aident à ce que votre base de code soit cohérente, donc plus facile à gérer qu'une base de code qui contient plusieurs styles de codage. Quelque chose de plus facile à comprendre est plus facile à entretenir.
Pour moi, un code maintenable signifie vraiment un code qui se lit comme un livre et qui est bien documenté.
Le code maintenable est testé à l'unité (et fonctionnel/intégration si nécessaire) de sorte que si un changement est introduit qui introduit un effet d'entraînement, il est détecté rapidement et tôt, avant même que le code ne soit enregistré.
Pour moi, le code maintenable ne tire pas parti des fonctionnalités du langage original que 0,1% de la population de programmation connaît (c'est-à-dire un exemple simple: utiliser un XOR swap au lieu d'une variable temporaire juste parce que l'auteur pense "c'est cool".
Le code maintenable met également en œuvre des principes architecturaux solides: SEC , SOLIDE , etc. Il utilise modèles de conception et algorithmes connus pour résoudre les problèmes appropriés.
La maintenabilité du code est la synergie réalisée lorsque nous appliquons tous ces axiomes de codage, règles de base, principes, etc. C'est plus de l'art que de la science. Dans la mesure où nous avons préparé une quantité appropriée de toutes ces choses, la base de code est maintenable. Le code n'est pas maintenable (oui/non, activé/désactivé, soit/ou) simplement parce que vous pouvez le modifier (ou non).
Cependant, le test acide de maintenabilité tente de changer le code. Dans la mesure où le code résiste, ou ne résiste pas, votre interaction avec lui définit sa maintenabilité.
La maintenabilité a des "capacités". Y compris, mais sans s'y limiter
- lisibilité
- compréhensibilité
- changeabilité
- testabilité
- fiabilité
- autres?
Comment pouvons-nous atteindre ces capacités?
Grâce à l'application de tous les principes et directives du logiciel dont vous n'avez jamais ou peut-être jamais entendu parler. Par exemple:
- Bons commentaires
- variable descriptive, méthode, noms de classe
- Limitez les méthodes à une page au maximum
- Maximisez la cohésion et minimisez le couplage
- encapsuler ce qui reste le même
- encapsuler ce qui change
- directives de mise en page/de mise en forme du code appliquées de manière cohérente
- Un seul point d'entrée et un seul point de sortie.
- ... et beaucoup, beaucoup, plus ...
Pour une bonne maintenabilité, il faut les considérer tous, tout le temps, à tous les niveaux du code, et les appliquer dans un mélange (pas "le") approprié. De plus, et je ne saurais trop insister sur ce point, aucun principe ne fonctionne mieux (ou très bien du tout, peut-être) seul.
Cherchez vos routes vers Damas
Il y a plusieurs années, deux choses se sont rencontrées. Un ensemble de programmes qui étaient littéralement incontrôlables et ma découverte de Code Complete par Steve McConnell. Ce livre était ma bible en réécrivant tout ce code pire qu'échec et la comparaison "avant et après" du code n'était rien de moins qu'une révélation.
Trouvez vos routes vers Damas. C'est un environnement riche en cibles.
Lire Code terminé
Je ne saurais trop insister sur la qualité de ce livre pour l'apprentissage des principes fondamentaux du développement logiciel.
Le code maintenable est un code qui présente une cohésion élevée et un faible couplage. La cohésion est une mesure de la façon dont le code est lié, lisible et compréhensible. Le couplage est une mesure de la façon dont le code est lié, un faible couplage signifie que le changement de la façon dont A fait quelque chose ne devrait pas affecter B qui utilise A. En général, un couplage inférieur signifie une cohésion plus faible, et vice versa, donc un développeur doit trouver un équilibre approprié entre le deux.
La maintenabilité est en soi une mesure de la facilité à modifier le code, une maintenabilité plus élevée signifie moins de temps pour effectuer un changement. Les normes de codage sont un moyen d'atteindre une maintenabilité élevée et sont développées à la suite d'expériences antérieures, elles ne sont pas universelles et dépendent des préférences des développeurs.
Posez-vous quelques questions.
(ou, comme certains peuvent le dire, passons ensemble à travers certains scénarios )
À quel point ce sera difficile pour vous de comprendre ce que vous avez écrit?
- La semaine dernière?
- Le mois dernier?
- L'année dernière?
- Dans 27 ans?
À quel point sera-t-il difficile pour un collègue de comprendre ce que vous avez écrit?
Dans le cas malheureux, tout le monde dans votre équipe n'est pas disponible, mais un correctif doit durer quelques heures, et le seul gars disponible pour le travail est un stagiaire d'été, quelle est la probabilité de réussite?
Et alors:
- à quel point sera-t-il difficile d'appliquer un correctif de sécurité à un morceau de code aléatoire?
- à quel point sera-t-il difficile de changer une incompréhension logique des exigences?
- à quel point sera-t-il difficile de prendre en charge la question de l'utilisabilité/UX/cosmétique?
- sera-t-il difficile de s'adapter au paysage juridique en constante évolution?
- à quel point sera-t-il difficile d'intégrer de nouvelles fonctionnalités commercialisables?
- à quel point sera-t-il difficile de porter le tout sur une architecture différente?
Et le meilleur de tous:
- sera-t-il difficile d'adapter l'ensemble du géant à un nouvel ensemble d'exigences pour un client ayant des besoins similaires, mais ...?
C'est plus ou moins la maintenance. Ce dernier consiste plus à transformer l'application en produit, peut-être, mais c'est un besoin assez typique à soulever, avec le temps.
"Les meilleures pratiques":
- Commentaires
- Documentation
- Diagrammes
- Indentation cohérente
- Modèles de codage
Sont tous destinés à faire durer votre code plus longtemps.
Les modèles de codage, en particulier, aident à la maintenance en rendant la lecture de code de moins en moins découverte, et de plus en plus en "Oh oui, je l'ai déjà vu, donc la partie que je cherche car devrait être ... par ici ".
Ils doivent évidemment être utilisés avec prudence et ne jamais être copiés/abusés juste pour le plaisir.
Ce n'est pas LEGO, c'est plus une source d'inspiration.
Il y a de fortes chances que si vous ne pouvez pas associer l'utilisation d'un modèle à des avantages de maintenabilité, il ne les utilise pas correctement. Mais soyez assuré qu'en tant que moyen de comparer différentes solutions et de permettre des temps de réponse plus rapides en cas de maintenance, elles sont théoriquement solides.
Je suis surpris que personne n'ait mentionné mesures de complexité McCabe . Une métrique de haute complexité est une véritable odeur de code en matière de maintenabilité. Il est parfois nécessaire qu'une routine soit "complexe" mais indique généralement du code qui sera très difficile à maintenir.
En regardant cette autre façon, tout le code est maintenable. Le facteur de différenciation se résume à l'effort requis pour maintenir le code et le montant de la dette technique que le code représente dans un état donné.
Un code bien factorisé nécessite peu d'efforts pour le maintenir, et lorsque vous avez besoin de le modifier, il n'imposera pas de coût de ressources important. Code qui est difficile à lire, trop "intelligent" pour son bien, mal factorisé ou qui ne correspond pas à l'intention pour laquelle il a été écrit, ce sont les types de code qui entraînent des coûts plus élevés à maintenir ou à contourner. si le coût: l'avantage rend plus opportun d'éviter la maintenance directe. Ne pas conserver un code médiocre augmente considérablement votre dette technique et augmente la probabilité que le code soit finalement considéré comme trop coûteux à entretenir.
Le fait d'étiqueter le code comme maintenable ou non maintenable peut entraîner des pertes importantes pour votre entreprise et peut entraîner la stigmatisation de l'échec du projet à suivre ses développeurs comme une mauvaise odeur pendant des années. Changer la langue pour être davantage sur l'effort et moins sur la perception de la maintenabilité peut être plus utile à long terme, en aidant à concentrer les efforts sur le problème avant qu'il ne devienne très difficile à gérer.
Lorsque vous travaillez avec d'autres développeurs qui ont besoin d'aide pour comprendre ce que signifie la maintenabilité, je leur demanderai: "Si votre application se bloque à 3h00 du matin et que vous êtes appelé hors du lit pour le réparer, est-ce ce code que vous voudriez regarder ensuite? ? " Vous seriez surpris de voir comment cela peut changer le point de vue des gens.
maintenir le code signifie prendre ce code et le modifier pour corriger un bogue ou ajouter une fonctionnalité
le code maintenable facilite ce processus
rendre le code maintenable signifie le rendre facile à comprendre (les noms des variables descriptives, les commentaires et la documentation aideront ici) et apporter des modifications faciles à effectuer (les modèles peuvent rendre cela plus facile, mais cela dépend des besoins réels)
J'ai défini la maintenabilité comme: une mesure de l'effort requis pour changer la fonctionnalité d'un logiciel d'application. Une mesure de "l'effort" doit inclure le temps, les ressources et l'expertise.
En général, tout gestionnaire de développement logiciel connaît cette définition de "l'effort" telle qu'elle s'applique à la création de logiciels. Le terme "modifier la fonctionnalité" s'applique aux améliorations et aux corrections de bogues. On pourrait également dire que le code maintenable est conçu pour être exploité.
Il faut un certain effort pour créer un logiciel maintenable. Pour ce que ça vaut, j'ai récemment commencé un blog sur le sujet.
Maintenable est - dans une certaine mesure - subjective. Cependant, c'est du code qui est écrit moins avec l'ego de l'écrivain à l'esprit et plus avec la reconnaissance qu'à un moment donné, quelqu'un devra probablement revoir ce code et le modifier pour des raisons actuellement indéfinies. Très peu de bases de code restent statiques pendant des années.
Ce qu'une personne considère comme maintenable peut être très différent du point de vue d'une autre à certains égards, mais je pense que cela devrait inclure:
- pas de pièges cachés pour les imprudents à l'avenir
- la logique et la justification doivent être documentées
- il doit être conforme à certaines normes locales documentées
Nous avons des discussions ici sur le sujet de la documentation et des commentaires de temps en temps.
Le code dont les attributions et la logique sont faciles à suivre devrait pour la plupart être facile à mettre à jour selon les besoins, avec quelques mises en garde sur les considérations de conception d'origine (qui ne devraient jamais être documentées correctement).