Quelle est la valeur réelle d'un style de code cohérent
Je fais partie d'une équipe de consultants mettant en œuvre une nouvelle solution pour un client. Je suis responsable de la majorité des revues de code sur la base de code côté client (React et javascript).
J'ai remarqué que certains membres de l'équipe utilisent des modèles de codage uniques au point que je pouvais choisir un fichier au hasard pour dire qui était l'auteur du style seul.
Exemple 1 (fonctions en ligne uniques)
React.createClass({
render: function () {
var someFunc = function () {
...
return someValue;
};
return <div>{someFunc()}</div>
}
});
L'auteur fait valoir qu'en attribuant un nom significatif à someFunc, le code sera plus facile à lire. Je pense qu'en insérant la fonction et en ajoutant un commentaire à la place, le même effet pourrait être obtenu.
Exemple 2 (fonctions non liées)
function renderSomePart(props, state) {
return (
<div>
<p>{props.myProp}</p>
<p>{state.myState}</p>
</div>
);
}
React.createClass({
render: function () {
return <div>{renderSomePart(this.props, this.state)}</div>;
}
});
Voici comment nous le faisons habituellement (évite d'avoir à passer l'état et les accessoires):
React.createClass({
renderSomePart: function () {
return (
<div>
<p>{this.props.myProp}</p>
<p>{this.state.myState}</p>
</div>
);
},
render: function () {
return <div>{this.renderSomePart()}</div>;
}
});
Bien que ces modèles de codage soient techniquement corrects, ils ne sont pas cohérents avec le reste de la base de code ni avec le style et les modèles auxquels Facebook (l'auteur de React) fait allusion dans des tutoriels et des exemples.
Nous devons garder un rythme rapide afin de livrer à temps et je ne veux pas surcharger l'équipe inutilement. En même temps, nous devons être à un niveau de qualité raisonnable.
J'essaie de m'imaginer comme le développeur de maintenance des clients confronté à des incohérences comme celles-ci (chaque composant pourrait vous obliger à comprendre une autre façon de faire la même chose ).
Question:
Quelle est la valeur perçue par le client et ses développeurs de maintenance d'une base de code cohérente par rapport à la possibilité de conserver et de propager des incohérences comme celles-ci?
Avantage de transfert de code
En suivant les modèles fournis par une bibliothèque, React dans votre cas, cela signifie que le produit que vous livrez sera facilement récupéré et entretenu par d'autres développeurs qui connaissent également React.
problèmes de compatibilité descendante potentiels
Certaines bibliothèques auraient une nouvelle version majeure, et la compatibilité descendante pourrait être compromise si vos modèles sont significativement différents, ralentissant/arrêtant ainsi votre future mise à niveau. Je ne sais pas comment React traiterait les nouvelles versions, mais j'ai déjà vu cela se produire.
Les nouveaux membres de l'équipe commencent à être productifs plus rapidement
Si vous suivez ce qui est fourni par l'auteur, vous embauchez probablement des développeurs talentueux en utilisant votre framework et les démarrez plus rapidement avec votre système plutôt que d'enseigner de nouveaux modèles.
Problèmes potentiels non découverts
Il pourrait y avoir à l'avenir des problèmes que vous n'avez pas encore découverts avec votre approche, qui sont résolus par l'approche de l'auteur.
Cela étant dit, l'innovation est toujours un risque, si vous pensez fermement que votre approche est meilleure et qu'elle fonctionne pour votre équipe, allez-y!
Les incohérences vous font arrêter et penser pourquoi, qui et où:
Lorsque vous lisez une partie du code et voyez qu'il utilise un style différent du reste du code, vous vous demandez - pourquoi cette partie particulière est-elle différente? Y a-t-il une raison particulière dont je dois être conscient? C'est dangereux, car s'il y a vraiment une raison pour que cette partie soit différente, vous devez en être conscient, sinon vous pourriez créer des bugs désagréables. Donc, au lieu de penser au problème d'origine qui vous a poussé à toucher ce code, vous perdez maintenant du temps à réfléchir à la raison pour laquelle il est différent, et vous ne pouvez pas le comprendre, vous allez donc voir l'auteur d'origine pour lui demander, en perdant également son temps, et pire encore - dans le processus, vous perdez tous les deux le modèle mental des problèmes sur lesquels vous travailliez.
Multipliez par tous les autres développeurs de l'équipe qui doivent toucher/lire ce code.
Lorsque vous devez ajouter à un code qui utilise plusieurs styles, vous devez vous arrêter et décider du style lequel à utiliser pour votre ajout. Vous devez prendre suffisamment de décisions qui comptent - c'est une perte de temps de perdre du temps à penser à des décisions qui n'ont pas d'importance.
Lorsque le style est cohérent, il est facile de naviguer dans le code, car la cohérence vous aide à trouver rapidement où se trouve. Avec un style incohérent, même la grepping devient plus difficile car vous ne savez pas quel style la chose que vous recherchez utilise.
Le code peut être bien écrit mais pas parfaitement cohérent, donc certains clients s'en moquent. Lorsque les choses commencent à mal tourner, voulez-vous leur donner un autre coup contre vous? Si j'embauchais une entreprise pour travailler sur un projet multi-développeur et qu'ils ne m'indiquaient pas qu'ils avaient une norme de codage et la suivaient, je serais sceptique.
Nous devons garder un rythme rapide afin de livrer à temps et je ne veux pas surcharger l'équipe inutilement.
Tant que les normes de codage ne sont pas trop folles, il ne devrait pas être si difficile pour tout le monde de monter à bord. Les projets sont bloqués parce que les gens ne savent pas quel code écrire ou non et pas à cause de la frappe et du formatage. Vous saurez que vous êtes allé trop loin quand il faut un temps disproportionné pour y adhérer. J'espère que ce n'est pas votre premier rodéo.
Effectuez votre propre test Tout ce que vous avez à faire est de changer les affectations à mi-chemin d'un développeur à l'autre et de les faire terminer le fichier de quelqu'un d'autre. Passent-ils du temps à reformater complètement les choses dans leur version? Est-ce trop difficile à suivre? Cela va empirer pour l'équipe de maintenance de votre client.
Les réponses les mieux notées ici répètent les meilleures pratiques théoriques facilement acceptables détaillant comment nous aimerions tous que nos bases de code soient. Mais le vrai code ne ressemble jamais à ça. Si vous essayez de créer cette base de code parfaite, vous échouerez presque inévitablement. Cela ne veut pas dire que nous ne devrions pas essayer de faire mieux, mais il doit y avoir une limite quant à la distance entre ce qui est réalisable et réaliste que nous fixons nos objectifs.
Trop se concentrer sur des choses mineures risque de perdre le focus sur des questions plus importantes, comme la façon de résoudre le travail de la manière la plus efficace possible.
Je ne ferais pas référence à votre premier exemple en tant que style, le style est le choix où il n'y a pas de bien ou de mal clair, dans ce cas, la fonction supplémentaire est un gonflement de code sans avantage. Il ne s'agit que de 2 lignes supplémentaires, toujours faciles à lire et faciles à corriger, donc cet exemple lui-même n'est pas un gros problème.
Le problème beaucoup plus important est le ballonnement du code alambiqué. Fonctions d'encapsuleur, hiérarchies de classes et toutes sortes d'autres constructions, où le code environnant est suffisamment complexe pour qu'il ne soit pas évident qu'elles ne servent à rien. S'il y a un gonflement évident dans le code, il y a probablement beaucoup plus de ballonnement non évident. Il est beaucoup plus difficile de faire quelque chose et plus difficile à repérer, mais c'est aussi un problème beaucoup plus important.
À propos des clients
Les clients ont tendance à se concentrer sur l'obtention d'un produit fonctionnel qui répond à leurs besoins. Même si vous avez l'un des rares clients qui s'inquiètent de la qualité du code, cela va être une priorité secondaire, et leur idée de la qualité du code pourrait ne pas être parfaitement cohérente avec la vôtre. L'entreprise cliente peut avoir ses propres programmeurs, mais c'est toujours la direction qui décidera si vous avez fait du bon travail, et la direction ne sait probablement même pas ce que signifie la qualité du code.
J'ai eu de la chance de traiter les styles de code comme je traite les styles d'écriture en anglais naturel. Il existe une vaste gamme de styles, de l'anglais conversationnel, qui imite la façon dont nous parlons dans la conversation quotidienne, à l'anglais formel, qui est souvent lourd et guindé par une signification toujours très précise.
Considérez à quoi vous aimeriez que le produit final ressemble dans ce sens. Certaines situations sont très favorables à l'utilisation de la meilleure structure du moment. D'autres nécessitent une cadence et une structure uniformes. Cela est particulièrement vrai si votre produit est meilleur que s'il était écrit en anglais formel. Les expressions familières peuvent aider dans ce cas, mais elles déchirent la sensation globale du produit.
En général, plus votre norme de codage est cohérente, moins un développeur doit déployer d'efforts pour attirer son attention sur quelque chose d'intéressant. Si vous soutenez une grande diversité de normes de codage, les développeurs doivent être plus forts lorsqu'ils annoncent qu'ils font quelque chose d'inhabituel ou d'unique. Cette tentative d'exprimer ce qu'un développeur considère comme important peut souvent éclipser la plage dynamique du code lui-même. Lorsque cela se produit, il est facile de faire glisser des bogues car il est tout simplement trop difficile de les voir.
Sur le revers de cet argument, plus vos normes de codage sont souples, plus les développeurs ont de liberté pour adapter leur syntaxe au problème. En contraste ironique avec l'argument des normes de codage pro, une trop grande standardisation peut conduire à une structure de code sur pilotis, ce qui peut également faciliter le passage des bogues.
Ce que vous cherchez, c'est le juste milieu de votre propre équipe.
Comme plusieurs autres l'ont souligné, lorsque les développeurs de maintenance doivent vous suivre, une section de code dans un style différent va les faire s'arrêter et essayer de comprendre ce qui est spécial à propos de cette section. Il y a aussi le risque très réel que le style incohérent se propage à d'autres sections, ce qui entraînera un énorme gâchis plus tard.
J'ai l'impression qu'au fond, vous connaissez déjà la réponse à cette question, et vous n'y seriez même pas confronté sans cela:
Nous devons garder un rythme rapide afin de livrer à temps et je ne veux pas surcharger l'équipe inutilement.
Cela semble toujours être le compromis universel ... le faire rapidement vs le faire correctement. Vous seul pouvez évaluer les conséquences du sacrifice de bonnes pratiques de codage sur la modification des délais des clients. Cependant, je dois être d'accord avec JeffO lorsqu'il observe que le fait de suivre un style de codage (peut-être inhabituel ou contre-intuitif) ne devrait pas ralentir votre équipe si radicalement que les délais glissent de manière significative.
Bien que je connaisse le concept depuis des années, je n'ai appris que récemment le terme " dette technique ". Vous devez vraiment considérer la dette technique qui devra finalement être payée si vous ne suivez pas un style discipliné maintenant.
Malheureusement, comme l'a indiqué eBusiness, à moins que votre client ne soit particulièrement averti sur le plan technique ou qu'il ne maintienne lui-même le code par la suite, il lui est difficile d'apprécier la valeur de normes de codage cohérentes. Cependant, tout homme d'affaires raisonnable devrait être en mesure de comprendre le concept selon lequel "un peu d'entretien préventif maintenant" (sous la forme d'un bon codage) "aidera à éviter des coûts de réparation importants plus tard" (sous la forme de temps perdu par le développeur à nettoyer plus tard le désordre).
Cela dépend beaucoup de la lisibilité des différences. Si le style de code se précipite, les différences masquent les modifications sans signification sémantique pour le programme et peuvent rendre les fusions difficiles ou impossibles.