Si mon équipe a des compétences faibles, dois-je réduire les compétences de mon code?
Par exemple, il existe un extrait de code commun dans JS pour obtenir une valeur par défaut:
function f(x) {
x = x || 'default_value';
}
Ce type d'extrait n'est pas facilement compris par tous les membres de mon équipe, leur niveau JS étant faible.
Dois-je pas utiliser cette astuce alors? Cela rend le code moins lisible par les pairs, mais plus lisible que le suivant selon tout développeur JS:
function f(x) {
if (!x) {
x = 'default_value';
}
}
Bien sûr, si j'utilise cette astuce et qu'un collègue la voit, alors ils peuvent apprendre quelque chose. Mais le cas est souvent qu'ils y voient "essayer d'être intelligent".
Alors, dois-je abaisser le niveau de mon code si mes coéquipiers ont un niveau inférieur à moi?
Ok, voici mon point de vue sur ce sujet vaste et compliqué.
Avantages pour conserver votre style de codage:
- Des choses comme
x = x || 10sont idiomatiques dans le développement JavaScript et offrent une forme de cohérence entre votre code et le code des ressources externes que vous utilisez. - Un niveau de code plus élevé est souvent plus expressif, vous savez ce que vous obtenez et il est plus facile à lire par des professionnels hautement qualifiés.
- Vous apprécierez davantage votre travail. Personnellement, je valorise la création de joli code. Je pense que cela m'apporte beaucoup de satisfaction dans mon travail.
- Généralement, il crée un style plus lisible. S'en tenir aux idiomes de la langue peut être très précieux - ce sont souvent des idiomes pour une raison.
Inconvénients de conserver votre style de codage:
- Il sera plus difficile pour les programmeurs de niveau inférieur de suivre le rythme. Ce sont souvent les personnes qui gèrent votre code et celles qui devront réellement lire ce que vous écrivez.
- Les responsables du code, souvent du code JavaScript, proviennent d'autres langues. Vos programmeurs peuvent être compétents en Java ou C # mais ne comprennent pas comment et quand JavaScript diffère exactement. Ces points sont souvent idiomatiques - un expression de fonction immédiatement invoquée (IIFE) est un exemple d'une telle construction.
Mon opinion personnelle
Vous ne devez pas réduire les compétences de votre code. Vous devez aspirer à écrire du code expressif, clair et concis. Si vous avez des doutes sur le niveau de votre équipe - éduquez-les . Les gens sont plus que disposés à apprendre que vous ne le pensez et sont prêts à adapter de nouvelles constructions lorsqu'ils sont convaincus qu'ils sont meilleurs.
S'ils pensent que vous êtes "juste intelligent", essayez de faire valoir votre point de vue. Soyez prêt à admettre que vous vous trompez parfois, et quoi qu'il en soit, essayez de garder des styles cohérents dans votre environnement de travail. Cela contribuera à éviter l'hostilité.
La chose la plus importante est de rester cohérent.
Le code d'une équipe doit être écrit comme si une personne l'avait codé. Vous vous devez absolument le faire acceptez les directives de codage. Vous devez respecter ces directives. Si les directives de codage spécifient que la lecture des paramètres facultatifs doit être effectuée de la manière "moins intelligente", alors c'est la voie.
Bien commenter
Devriez-vous réduire les compétences de votre code? Pas nécessairement, mais vous devriez augmenter définitivement les compétences de vos commentaires. Assurez-vous d'inclure de bons commentaires dans votre code, en particulier autour des sections qui, selon vous, pourraient être plus compliquées. N'utilisez pas autant de commentaires que le code devient difficile à suivre, mais assurez-vous de clarifier le but de chaque section.
La réalité est qu'être un peu plus verbeux avec les commentaires peut être utile avec les membres de l'équipe moins qualifiés, mais ceux avec les compétences les plus faibles les ignorent, surtout s'il y en a trop, alors n'en faites pas trop.
Une question de style?
L'exemple que vous avez fourni est quelque peu basique, mais aussi plutôt stylistique. Un commentaire sur chaque variable par défaut serait assez fastidieux à maintenir et à lire. Au lieu de cela, des raccourcis stylistiques ou répétés ou des modèles de code devraient probablement être établis comme standard. Si vous pensez que quelque chose comme cette forme de défaut de paramètre devrait être compris par tous et utilisé à chaque fois, notez ces idées et apportez-les à votre chef d'équipe. Il est possible que tout ce qu'il faut pour enseigner à vos coéquipiers soit une simple réunion où vous discuterez des normes que vous avez proposées.
Comme une autre réponse l'a déjà dit, maintenez-le cohérent .
Apprenez à un homme à pêcher ...
Enseigner à vos coéquipiers est probablement la meilleure façon d'aider toutes les personnes impliquées. Précisez que si quelqu'un a une question sur un morceau de code avec votre nom dans le journal de validation ou les horodatages, ils devraient se sentir libres de vous poser des questions à ce sujet. Si votre équipe a des revues de code, c'est une excellente occasion d'expliquer tout code (ahem) bien commenté à vos coéquipiers. Si votre équipe n'a pas de revues de code, pourquoi pas? Allez-y!
Vous devez cependant être prudent. Vous pourriez ne pas toujours être là pour enseigner aux gens et vous pouvez même oublier ce que vous essayiez à l'origine de faire dans une section de code donnée.
Astuces "intelligentes"
Il est certainement important de garder à l'esprit les capacités de vos coéquipiers, mais écrire du code maintenable signifie souvent ne pas utiliser de raccourcis obscurs pour des problèmes qui pourraient avoir des solutions plus courantes. C'est important même lorsque vos coéquipiers sont intelligents. Vous ne voulez pas rendre le code trop long à saisir ou avoir des effets secondaires subtils mais importants qui pourraient être manqués. En général, il est préférable d'éviter les astuces "intelligentes" quand il existe des alternatives appropriées. On ne sait jamais qui pourrait avoir à maintenir le code sur la ligne - souvent Parfois, les anciennes versions de nous-mêmes ne se souviendront pas des détails ou des raisons de ces astuces.
Si vous trouvez que vous devez mettre en œuvre une astuce astucieuse, suivez au moins le prochain conseil ...
KISS
En cas de doute, restez simple . Que le code soit simple ou non ne correspond pas nécessairement aux compétences du programmeur comme vous pourriez le faire pense. En fait, certaines des solutions les plus brillantes à un problème sont les plus simples, et certaines des solutions les plus compliquées se retrouvent sur TheDailyWTF . Garder votre code simple et concis peut rendre certaines des décisions les plus intelligentes mais peut-être contre-intuitives plus faciles à saisir.
Il semble y avoir une énorme aversion pour la création d'une fonction dans JS. Cette aversion pousse les gens à être intelligents et à utiliser des astuces ridicules juste pour garder des trucs sur une seule ligne comme aurait pu l'être un appel de fonction. Bien sûr, le nom de la fonction dans un appel sert également de documentation supplémentaire. Nous ne pouvons pas joindre un commentaire à une expression délicate, car cela irait à l'encontre du but de le faire, alors nous l'appelons simplement "idiome js" et tout à coup, il est compréhensible.
Javascript est extrêmement accessible, la plupart des gens ne mangent pas de spécifications pour le petit déjeuner comme nous. Ils ne comprendront donc jamais quelles sont les hypothèses cachées et les cas Edge d'un idiome.
x = x || 'default_value';
Le joe moyen ne comprend pas cela ou a mémorisé qu'il s'agit de l'idiome de la valeur par défaut. Les deux sont nocifs, en fait, ce dernier est encore plus nocif. Il ne comprendra pas les hypothèses et les cas Edge ici. Il ne se souciera pas de lire la spécification et de la comprendre jamais.
Lorsque je regarde ce code, je vois "s'il s'agit de null ou undefined, puis définissez-le sur cette valeur par défaut. Bien qu'il traite également implicitement +0, -0, NaN, false et "" en tant que valeurs non appropriées. Je dois me souvenir que dans 3 mois à partir de maintenant, lorsque cela doit changer. Je l'oublierai probablement . ".
L'hypothèse implicite est extrêmement susceptible de provoquer un bogue à l'avenir et lorsque votre base de code est pleine d'astuces comme celle-ci, il n'y a aucune chance que vous les gardiez tous dans votre tête chaque fois que vous pensez à ce qu'une modification affectera. Et c'est pour le "JS pro", le joe moyen aurait écrit le bogue même si les conditions étaient d'accepter une valeur falsifiée pour commencer.
Votre nouvel extrait a une syntaxe plus familière mais présente toujours le problème ci-dessus.
Vous pouvez aller avec:
function f(x) {
x = valueOrDefault(x, "default_value");
}
Maintenant, vous pouvez avoir une logique très complexe pour gérer les cas Edge et le code client est toujours beau et lisible.
Maintenant, comment différenciez-vous une fonction de langage avancée comme passer une fonction en argument ou une astuce astucieuse comme || "default"?
Des astuces intelligentes fonctionnent toujours sous certaines hypothèses cachées qui pourraient être ignorées lors de la création initiale du code. Je n'aurai jamais à modifier un IIFE pour autre chose car une exigence a changé, elle sera toujours là. Peut-être en 2020 quand je pourrai utiliser de vrais modules mais oui.
| 0 Ou la version culte du fret ~~num Utilisée pour le revêtement de sol suppose des limites entières positives et signées 32 bits.
|| "default" Suppose que toutes les valeurs de falsification sont identiques à ne pas passer du tout un argument.
Etc.
Vous ne devriez pas inférieur vos compétences en programmation, mais vous devrez peut-être ajuster comment vous écrivez le code. Le but, avant tout, est de rendre votre code clair aux personnes qui doivent le lire et le maintenir.
Malheureusement, il peut être un peu un jugement de décider si un style particulier est "intelligent" ou simplement une utilisation avancée. Le code de la question en est un bon exemple - votre solution n'est pas nécessairement meilleure que l'autre. Certains diront que c'est le cas, d'autres seront en désaccord. Étant donné que les deux solutions ont des performances d'exécution égales (lire: l'utilisateur ne connaîtra jamais la différence), choisissez le style avec lequel l'équipe dans son ensemble est le plus à l'aise.
Dans certains cas, vous devez leur apprendre de meilleures façons de coder, mais à d'autres moments, vous devez faire des compromis dans un souci de clarté.
Cela a peut-être déjà été dit dans une autre réponse, mais je voudrais répondre à cette question mes propres ordres.
Ligne directrice générale
Lorsque vous travaillez en équipe, vous n'êtes pas le public cible d'un morceau de code. Votre public est les développeurs de votre équipe. N'écrivez pas de code qu'ils ne peuvent pas comprendre sans raison valable.
- Sauf s'il y a un inconvénient spécifique, tout le code doit être écrit selon un modèle ou une directive spécifique qui permettra une maintenance facile par les développeurs qui le maintiendront. (Une mise en garde: suivre de mauvais modèles simplement parce qu'ils sont actuellement dans la base de code est une pratique terrible.)
- Si vous pouvez trouver une bonne raison d'utiliser un idiome spécifique à une langue qui n'est pas facilement lisible par le public cible, ajouter un commentaire. Si vous trouvez que vous devez ajouter un commentaire à toutes les autres lignes, vous souhaiterez peut-être réécrire votre code pour qu'il soit plus lisible par votre public. Je ne trouve pas utile d'être idiomatique pour être idiomatique.
Exemple spécifique
Nous avons un grand nombre de scripts Perl dans notre base de code. Nous n'utilisons généralement Perl que pour des opérations très simples et la grande majorité du code est écrit par des développeurs Java, donc il ressemble beaucoup à Java. Nous avons un ensemble de scripts Perl et un cadre qui était écrit par un "gourou Perl" qui a depuis quitté notre entreprise. Ce code contient bon nombre des idiomes Perl les plus obscurs et aucun de nos développeurs, moi y compris, ne peut lire ce code Perl sans effort prolongé. Nous le maudissons souvent pour cela.: )
Si vous écrivez du bon code mais que vous pensez que vos collègues actuels ou futurs peuvent avoir du mal à le suivre, vous devez ajouter un bref commentaire pour l'expliquer.
De cette façon, vous pourriez leur apprendre quelque chose sans insulter leur intelligence individuelle ou embarrasser quiconque dans une discussion de groupe.
N'allez pas travailler pour Royal McBee Computer Corp alors, car qui peut dire que vous n'êtes pas un programmeur inexpérimenté.
bien sûr, c'est génial d'écrire du code concis et court et il pourrait être utile dans un environnement javascript (enfin, jusqu'à ce que quelqu'un produise un compilateur js à télécharger sur les navigateurs, mais c'est une autre histoire).
ce qui est important cependant, c'est la capacité de votre code à vivre au-delà des quelques minutes qu'il vous a fallu pour l'écrire. Bien sûr, c'est rapide et facile et vous pouvez le découper et passer à autre chose, mais si vous devez y revenir des années plus tard, c'est à ce moment-là que vous pourriez penser "quel muppet a écrit ceci", et réaliser que c'était vous! (Je l'ai fait, bien sûr, la plupart des gens l'ont fait aussi. Je blâme les délais trop agressifs, honnêtement).
C'est la seule chose importante à garder à l'esprit, alors même si je dirais oui - allez avec cet opérateur particulier si cela fonctionne et est clair, et vos développeurs `` inexpérimentés '' (bien que cela leur soit dérogatoire, j'en sais beaucoup de développeurs inexpérimentés qui connaissent tous les opérateurs et astuces car ils ont mémorisé divers tutoriels et références de pages Web, ils écrivent le pire code même s'ils connaissent chaque petite astuce ... il peut y avoir plus que de la coïncidence)
Quoi qu'il en soit, si vous pouviez lire l'histoire de Mel , vous vous rendriez compte que les astuces ne sont pas la meilleure chose à mettre dans un code, même si Mel était un vrai programmeur de premier ordre. Cela met à contribution tout argument où quelqu'un dit qu'il peut écrire du bon code et que tout le monde doit en savoir plus pour suivre.
Je n'appellerais pas votre exemple une astuce, mais juste idiomatique. Si vous devez l'utiliser, cela dépend à mon humble avis non pas tant du niveau actuel de votre équipe, mais si (au moins certains) vos coéquipiers sont prêts à apprendre de nouveaux idiomes. Bien sûr, vous devez discuter de ce sujet avec eux et ne pas leur appliquer ce style. Et vous ne devriez pas leur demander d'apprendre chaque jour 5 nouvelles choses ou "trucs". Mais honnêtement, si vous n'avez que des coéquipiers qui ne sont pas prêts à apprendre quelque chose de nouveau, même si c'est si simple et si petit que cet idiome, vous devriez envisager de changer pour une autre équipe.
En lisant cette question et les réponses et discussions qui ont suivi, il semble y avoir deux points. Le premier: est-il OK d'utiliser des fonctionnalités linguistiques avancées? La seconde: comment puis-je faire cela sans apparaître comme si je me "montrais"?
Dans le premier cas, il est logique d'utiliser des améliorations et des fonctionnalités avancées. Par exemple: en C #, vous n'avez pas à utiliser d'expressions Linq ou Lambda, mais la plupart des gens le font parce que cela rend le code plus ordonné et plus facile à comprendre, une fois que vous savez réellement ce qu'il fait. Au début, cela semble étrange.
Les gens s'habituent aux modèles et, dans de nombreux cas, les gens utilisent la façon de faire définie juste pour faire le travail. J'en suis aussi coupable que le prochain. Nous avons tous des délais. À certains égards, vous êtes coupable d'introduire de nouvelles idées et de nouvelles façons de penser! Cela revient au deuxième point et c'est probablement là que vous rencontrerez le plus de résistance.
Pour la personne qui utilise le site Web, elle ne se soucie pas du style utilisé. Tout ce qui l'intéresse, c'est que cela fonctionne? C'est rapide? Donc, s'il n'y a aucun avantage en termes de performances sur votre chemin, il n'y a pas de bonne ou de mauvaise façon dans l'exemple que vous donnez. Votre façon de faire rend-elle le code plus lisible ou non? Cela pourrait le faire une fois que vos collègues y seront habitués.
Alors, comment introduisez-vous ces changements? Essayez d'avoir des discussions avec vos collègues dans ce sens: saviez-vous que cette fonction peut être écrite de cette façon? Les révisions de code et la programmation par paires peuvent être de bons moments pour permettre une "pollinisation croisée" des idées. Il est difficile pour moi de prescrire quoi faire parce que je ne connais pas l'environnement dans lequel vous travaillez. Je trouve que certains programmeurs peuvent être très défensifs et résistants au changement. Encore une fois, je suis coupable de cela. La meilleure façon de travailler avec ces types de programmeurs est de passer un peu de temps à apprendre ce qui les fait vibrer, d'apprendre leur expérience, puis de comparer et de contraster vos styles et expériences avec les leurs. Cela prend du temps mais c'est du temps bien dépensé. Si possible, essayez de les encourager.
Eh bien, pour commencer, cela ressemble à un JS de base pour moi.
Mais en général - vous ne devriez pas utiliser de hacks intelligents, pour paraphraser "le débogage est deux fois plus difficile que la programmation. Si vous écrivez du code aussi intelligent que possible, vous êtes par définition incapable de le déboguer".
Cela ne signifie pas que vous devez éviter le code simplement parce que les autres ne le comprennent pas - vous devez écrire le code de la manière la plus claire et cohérente possible. Mais vos critères de clarté devraient être "est-ce que je comprendrai cela en première lecture dans un an", et non "est-ce que quelqu'un peut le comprendre".
Écrivez d'une manière claire, que vous n'avez aucune difficulté à comprendre et laissez les autres travailler à augmenter leurs compétences - ne vous handicapez pas afin de sauver d'autres problèmes hypothétiques.
Je discuterais avec mes coéquipiers du type de normes de codage que nous voulons avoir, car il s'agit principalement de savoir comment faire quelque chose qui peut être fait de plusieurs façons pour notre base de code. S'il y a consensus, ce serait ma première tentative de réponse.
Si ce n'est pas le cas, je considérerais probablement quel type de norme proposée est logique et commencerais à mettre cela en pratique une fois que j'aurai approuvé cela avec la direction et une partie de l'équipe. L'idée ici est de s'assurer que la direction est d'accord avec cette idée et que je ne vais pas simplement faire mon propre truc et forcer tout le monde à le prendre.
Je regarderais cela plus comme la question de quel type de normes et de pratiques votre équipe a-t-elle plutôt que simplement un niveau de compétence car il existe de nombreuses façons d'évaluer le code. Dans quelle mesure les autres peuvent-ils le maintenir est l'un de ces critères.
Le problème est que vous voulez une bonne lisibilité de la source, mais la lisibilité est aux yeux du spectateur.
Je dirais que nous avons besoin de meilleurs outils pour résoudre ce problème. Rien de complexe, remarquez, nous avons la technologie pour le faire depuis plus de 50 ans. Incluez un analyseur dans l'éditeur et demandez à l'éditeur d'enregistrer la source sous forme de sexps (oui, tout comme LISP). Ensuite, la source est lue, l'éditeur l'annule dans la syntaxe et la typographie (vous savez, les espaces, les tabulations, les virgules), sous la forme que l'utilisateur préfère.
De cette façon, vous pouvez taper et lire x = x || 10 et d'autres programmeurs le liront
if (0 == x) { x = 10;}
emacs a toutes les pièces pour le faire facilement.