Quelle est la valeur réelle d'un style de code cohérent

Je fais partie d'une équipe de consultants qui met en œuvre une nouvelle solution pour un client. Je suis responsable de la majorité des critiques de code sur la base de code côté client (React et javascript).

J'ai remarqué que certains membres de l'équipe utilisaient des modèles de codage uniques, à un point tel que je pouvais choisir un fichier au hasard en disant 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 affirme qu'en attribuant un nom significatif à someFunc, le code sera plus facile à lire. Je crois qu'en ajoutant la fonction et en ajoutant un commentaire, 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 procédons habituellement (en évitant de passer des états et des 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 compatibles 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 pour pouvoir respecter les délais et je ne veux pas alourdir inutilement l'équipe. Dans le même temps, nous devons avoir un niveau de qualité raisonnable.

J'essaie de m'imaginer en tant que développeur de la maintenance client confronté à de telles incohérences (chaque composant peut nécessiter que vous compreniez une autre façon de faire la même chose).

Question:

Quelle est la valeur, telle que perçue par le client et ses développeurs de maintenance, d’une base de code cohérente par rapport à de telles incohérences comme celles-ci peuvent rester et s’étendre?

Avantage du transfert de code

Suivre les modèles fournis par une bibliothèque, Reactdans votre cas, signifie que le produit que vous livrez sera facilement récupéré et géré par d’autres développeurs qui sont également familiarisés avec React.

Problèmes de compatibilité avec les versions antérieures

Certaines bibliothèques ont une nouvelle version majeure et la compatibilité avec les versions antérieures peut être compromise si vos modèles sont très différents, ce qui ralentit / arrête votre future mise à niveau. Je ne suis pas sûr de savoir comment Reacttraiter les nouvelles versions, mais je l'ai déjà vu auparavant.

Les nouveaux membres de l'équipe commencent à être productifs plus rapidement

Si vous suivez ce qui est fourni par l'auteur, vous embaucherez probablement des développeurs talentueux utilisant votre infrastructure et vous les lancerez plus rapidement avec votre système plutôt que d'enseigner de nouveaux modèles.

Problèmes potentiels non découverts

Il se peut que, dans le futur, des problèmes que vous n'avez pas encore découverts avec votre approche soient résolus par l'approche de l'auteur.

Cela étant dit, l'innovation est toujours un risque, si vous sentez que votre approche est meilleure et qu'elle fonctionne pour votre équipe, foncez!

Les incohérences vous font vous arrêter et penser pourquoi , lequel et où :

• Lorsque vous lisez une partie du code et constatez qu'il utilise un style différent du reste du code, vous vous demandez pourquoi cette partie est-elle différente? A-t-il une raison particulière que je dois connaître? 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 de vilains bugs. Ainsi, au lieu de penser au problème initial qui vous a amené à toucher ce code, vous perdez maintenant du temps à vous demander pourquoi il est différent, et vous ne pouvez pas le comprendre, vous devez donc demander à l'auteur original de le lui demander, perdant ainsi son temps, et Pire encore: vous perdez tous les deux le modèle mental des problèmes sur lesquels vous travailliez.

  Multipliez-le par tous les autres développeurs de l'équipe qui doivent toucher / lire ce code.

• Lorsque vous devez ajouter un code utilisant plusieurs styles, vous devez vous arrêter et décider quel style utiliser pour votre ajout. Vous devez prendre suffisamment de décisions qui comptent - c’est une perte de temps que de perdre du temps à penser à des décisions sans importance.

• Lorsque le style est cohérent, il est facile de naviguer dans le code, car la cohérence vous aide à trouver rapidement où des choses se trouve. Avec un style incohérent, même le 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, ainsi certains clients ne s'en soucieront pas. Quand les choses commencent à aller mal, voulez-vous leur donner un autre coup contre vous? Si j'engageais une entreprise pour travailler sur un projet multi-développeurs et qu'elle ne m'indique pas qu'elle possède une norme de codage et qu'elle la respecte, je serais sceptique.

Nous devons garder un rythme rapide pour pouvoir respecter les délais et je ne veux pas alourdir inutilement l'équipe.

Tant que les normes de codage ne sont pas trop dingues, il ne devrait pas être si difficile pour tout le monde d’adhérer. Les projets sont bloqués parce que les gens ne savent pas quel code écrire ou ne pas écrire et pas à cause de la frappe et du formatage. Vous saurez que vous êtes allé trop loin quand il faut un temps démesuré pour adhérer. J'espère que ce n'est pas votre premier rodéo.

Effectuer votre propre test Tout ce que vous avez à faire est de changer d'affectation à mi-parcours d'un développeur à un autre et de lui demander de terminer le dossier de quelqu'un d'autre. Est-ce qu'ils passent 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.

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 allant de l'anglais conversationnel, qui imite la façon dont nous parlons chaque conversation quotidienne, à l'anglais formel, qui est souvent lourd et dont le sens est toujours très précis.

Réfléchissez à ce que vous souhaitez que le produit final ressemble à cela. Certaines situations sont très favorables à l’utilisation de la structure la mieux adaptée à l’époque. D'autres exigent une structure et une cadence uniformes. Cela est particulièrement vrai si votre produit est le meilleur, même s'il a été écrit en anglais formel. Les expressions familières peuvent aider dans ce cas, mais elles déchirent l’atmosphère globale du produit.

En général, plus votre norme de codage est cohérente, moins les développeurs doivent déployer d'efforts pour attirer leur attention sur quelque chose d'intéressant. Si vous soutenez une grande diversité de normes de codage, les développeurs doivent faire plus de bruit 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 occulter la plage dynamique du code lui-même. Lorsque cela se produit, il est facile de laisser passer des bugs, car il est tout simplement trop difficile de les voir.

D'un autre côté, plus vos normes de codage sont souples, plus les développeurs ont toute liberté pour adapter leur syntaxe au problème. Contrairement à l'argument des standards pro-codants, une normalisation trop poussée peut conduire à une structure de code plus stable, ce qui facilite également le passage des bogues.

Ce que vous recherchez, c'est le juste milieu de votre propre équipe.

Comme plusieurs autres personnes l'ont souligné, lorsque les développeurs de maintenance doivent vous suivre, une section de code d'un style différent va les amener à 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 soit propagé à d'autres sections, entraînant un désordre énorme plus tard.

J'ai l'impression qu'au fond de vous, vous connaissez déjà la réponse à cette question et que vous n'y seriez même pas confronté s'il n'y avait pas cela:

Nous devons garder un rythme rapide pour pouvoir respecter les délais et je ne veux pas alourdir inutilement l'équipe.

Cela semble toujours être le compromis universel… faire vite contre bien faire les choses. Vous seul pouvez évaluer les conséquences de l’abandon des bonnes pratiques de codage sur la modification des délais. Cependant, je suis d'accord avec JeffO lorsqu'il constate que le fait de suivre un style de codage (peut-être inhabituel ou contre-intuitif) ne devrait pas ralentir votre équipe de manière si radicale que les délais s'écoulent considérablement.

Bien que je connaisse le concept depuis des années, ce n’est que récemment que j’ai appris le terme « dette technique ». Vous devez vraiment prendre en compte la dette technique qui devra éventuellement être payée si vous ne suivez pas un style discipliné maintenant.

Malheureusement, comme eBusiness l'a indiqué, à moins que votre client soit particulièrement avisé sur le plan technique ou qu'il conserve 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 saisir le concept selon lequel "un peu de maintenance préventive maintenant" (sous la forme d’un code correct) "contribuera à éviter des coûts de réparation importants plus tard" (sous la forme d’une perte de temps de développement par la suite désordre).

Les réponses les plus votées ici répètent les meilleures pratiques théoriques facilement agréables, détaillant comment nous voudrions 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 exister une limite quant à la mesure dans laquelle nous nous fixons nos objectifs de manière réaliste.

Si vous vous concentrez trop sur des tâches mineures, vous risquez de perdre le focus sur des problèmes plus importants, tels que la résolution du travail de la manière la plus efficace qui soit.

Je ne vous appellerais pas premier exemple en tant que style, style étant les choix où il n’existe aucun choix clair ou faux, dans ce cas, la fonction supplémentaire est le gonflement du code sans aucun avantage. Il ne s'agit que de 2 lignes supplémentaires, toujours faciles à lire et à corriger. Cet exemple n'est donc pas un gros problème.

Le problème beaucoup plus important est le gonflement du code compliqué. Fonctions wrapper, 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. Si le code contient un volume évident, il en existe probablement beaucoup plus. Il est beaucoup plus difficile de faire quelque chose et plus difficile à repérer, mais aussi un problème beaucoup plus important.

A propos des clients

Les clients ont tendance à se concentrer sur l’obtention d’un produit fonctionnel répondant à leurs besoins. Même si l'un des rares clients qui s'inquiète de la qualité du code, il s'agira d'une priorité secondaire et leur idée de la qualité du code pourrait ne pas correspondre parfaitement à la vôtre. La société cliente peut avoir ses propres programmeurs, mais ce sont toujours les responsables qui décideront si vous avez fait un bon travail et ceux-ci ne savent probablement même pas ce que signifie la qualité du code.

Cela concerne beaucoup la lisibilité des diffs. Si le style de code est perturbé, les différences masquent les modifications sans signification sémantique pour le programme et peuvent rendre les fusions difficiles, voire impossibles.