Si mon équipe a peu de compétences, devrais-je baisser les compétences de mon code? [fermé]

Par exemple, il existe un fragment 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 facile à comprendre pour tous les membres de mon équipe, leur niveau de JS étant bas.

Devrais-je pas utiliser cette astuce alors? Cela rend le code moins lisible par les pairs, mais plus lisible que ce qui suit selon n'importe quel 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, ils peuvent alors apprendre quelque chose. Mais le cas est souvent qu’ils voient cela comme "essayer d’être intelligent".

Alors, devrais-je baisser le niveau de mon code si mes coéquipiers ont un niveau plus bas que moi?

Ok, voici mon point de vue sur ce sujet vaste et compliqué.

Avantages pour garder votre style de codage:

• Des éléments comme x = x || 10idiomatiques 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 de lire avec des professionnels hautement qualifiés.
• Vous apprécierez plus votre travail. Personnellement, j’apprécie créer de jolis codes. Je pense que cela me procure beaucoup de satisfaction dans mon travail.
• Généralement, cela 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 pour garder votre style de codage:

• Les programmeurs de niveau inférieur auront plus de difficulté à suivre. Ce sont souvent les personnes chargées de la maintenance de votre code et celles qui devront lire ce que vous écrivez.
• Les mainteneurs de code, souvent le code JavaScript provient d'autres langues. Vos programmeurs sont peut-être compétents en Java ou en C # mais ne comprennent pas comment et quand JavaScript diffère exactement. Ces points sont souvent idiomatiques - une expression de fonction immédiatement appelée (IIFE) est un exemple d'une telle construction.

Mon opinion personnelle

Vous ne devriez pas baisser les compétences de votre code. Vous devriez aspirer à écrire un code expressif, clair et concis. Si vous avez des doutes sur le niveau de votre équipe, informez- les . Les gens sont plus que disposés à apprendre que vous ne le pensez et à adapter de nouveaux concepts s’ils sont convaincus qu’ils sont meilleurs.

S'ils pensent que vous êtes simplement "intelligent", essayez de défendre votre point de vue. Soyez prêt à admettre que vous vous trompez parfois, et quoi qu'il en soit, essayez de maintenir la cohérence des styles dans votre environnement de travail. Cela aidera à éviter l'hostilité.

Le plus important est de rester cohérent.

Le code d'une équipe doit être écrit comme si une personne l'avait codé. Vous devez absolument vous mettre d' accord sur 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 manière "moins intelligente", c'est le chemin à suivre.

Bien commenter

Devez-vous baisser les compétences de votre code? Pas nécessairement, mais vous devriez certainement augmenter la compétence de vos commentaires . Veillez à inclure de bons commentaires dans votre code, en particulier autour des sections que vous pensez être plus compliquées. N'utilisez pas autant de commentaires que le code devient difficile à suivre, mais assurez-vous de bien préciser le but de chaque section.

La réalité est qu’être un peu plus bavard avec des commentaires peut être utile avec des membres d’équipe moins expérimentés, mais que ceux qui ont les compétences les plus faibles avec les ignorent, surtout s’il y en a trop, 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 en tant que norme. Si vous pensez que quelque chose comme cette forme de défaut de paramètre doit être compris de tous et utilisé à chaque fois, écrivez ces idées et transmettez-les à votre responsable d'équipe. Il est possible que tout ce que vous aurez à enseigner à vos coéquipiers soit une simple réunion au cours de laquelle vous discuterez des normes que vous avez proposées.

Comme une autre réponse déjà énoncée, maintenez-le cohérent .

Apprendre à un homme à pêcher ...

Enseigner à vos coéquipiers est probablement le meilleur moyen d'aider toutes les personnes impliquées. Dites clairement que si quelqu'un a une question sur un morceau de code avec votre nom dans le journal de validation ou les horodatages, il doit se sentir libre de vous en parler. Si votre équipe dispose de révisions de code, il s'agit d'une excellente occasion d'expliquer à vos coéquipiers tout code éventuellement commenté pouvant prêter à confusion . Si votre équipe n'a pas de révision de code, pourquoi pas? Allez-y!

Vous devez cependant faire attention. Vous n'êtes peut-être pas toujours là pour enseigner aux gens et vous pourriez même oublier ce que vous essayiez à l'origine de faire dans une section de code donnée.

Astuces "Clever"

Il est certes 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 résoudre des problèmes qui pourraient donner lieu à des solutions plus courantes. Ceci est important même lorsque vos coéquipiers sont intelligents. Vous ne voulez pas faire en sorte que le code prenne trop de temps à saisir ou à avoir des effets secondaires subtils mais importants qui pourraient être omis. En général, il est préférable d'éviter les astuces "intelligentes" lorsqu'il existe des alternatives appropriées. Vous ne savez jamais qui pourrait avoir à gérer le code sur toute la ligne. Souvent, les anciennes versions de nous-mêmes ne se souviendront pas des détails ou des raisons de ces astuces.

Si vous constatez que vous devez mettre en œuvre une astuce intelligente, suivez au moins les conseils suivants ...

BAISER

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 penser. En fait, certaines des solutions les plus brillantes à un problème sont les plus simples, et certaines des solutions les plus compliquées aboutissent sur TheDailyWTF . Garder votre code simple et concis peut faciliter la prise de certaines des décisions les plus intelligentes, voire contre-intuitives.

Il semble y avoir une grande aversion pour la création d’une fonction dans JS. Cette aversion incite les gens à faire preuve d'intelligence et à utiliser des astuces ridicules simplement pour garder les éléments dans une ligne, comme cela aurait été le cas pour un appel de fonction. Bien entendu, le nom de la fonction dans un appel sert également de documentation supplémentaire. Nous ne pouvons pas associer un commentaire à une expression délicate, car cela éviterait de le faire et nous l'appelons simplement "idiome js" et tout à coup, cela se comprend.

Javascript est extrêmement accessible, la plupart des gens ne mangent pas les spécifications du petit-déjeuner comme nous le faisons. Ainsi, ils ne comprendront jamais quelles sont les hypothèses cachées et les cas extrêmes d’un idiome.

x = x || 'default_value';

Le joe moyen soit ne comprend pas cela ou a mémorisé que c’est l’idiome de la valeur par défaut. Les deux sont nuisibles, en fait le dernier l'est encore plus. Il ne comprendra pas les hypothèses et les cas extrêmes ici. Il ne se souciera pas de lire le cahier des charges et de le comprendre jamais.

Quand je regarde ce code je vois « si elle est nullou undefined, réglez ensuite à cette valeur par défaut. Bien qu'il traitera également implicitement +0, -0, NaN, falseet ""ne pas les valeurs appropriées. Je dois rappeler que 3 mois à partir de maintenant , quand que les besoins changer. Je vais probablement l’oublier. "

L’hypothèse implicite est extrêmement susceptible de provoquer un bogue dans l’avenir. Lorsque votre base de code regorge d’astuces de ce type, il n’ya aucune chance que vous les gardiez toutes dans votre tête lorsque vous songez à ce qu’une modification affectera. Et ceci est pour le "JS pro", le joe moyen aurait écrit le bogue même si les exigences étaient d’accepter une valeur falsy pour commencer.

Votre nouveau fragment de code a une syntaxe plus familière, mais le problème ci-dessus persiste.

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 extrêmes et le code client est toujours aussi beau et lisible.

Maintenant, comment faites-vous la différence entre des fonctionnalités de langage avancées telles que le passage d’une fonction en argument ou un truc astucieux comme || "default"?

Les astuces intelligentes fonctionnent toujours avec des hypothèses cachées qui pourraient être ignorées lors de la création initiale du code. Je n'aurai jamais à modifier un IIFE en autre chose car une exigence a changé, elle sera toujours là. Peut-être qu'en 2020, je pourrai utiliser des modules réels, mais oui.

| 0ou la version culte de cargaison ~~numutilisée pour les revêtements de sol suppose des bornes d’entiers positives signées et de 32 bits.

|| "default" suppose que toutes les valeurs de falsy sont les mêmes que de ne pas transmettre un argument du tout.

Etc.

Vous ne devriez pas réduire vos compétences en programmation, mais vous devrez peut-être ajuster votre écriture de code. Le but, avant tout, est de rendre votre code clair pour les personnes qui doivent le lire et le maintenir.

Malheureusement, il est difficile de juger si un style particulier est "intelligent" ou juste comme 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 ne seront pas d'accord. Étant donné que les deux solutions offrent effectivement des performances d'exécution égales (lisez: l'utilisateur ne saura 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 à mieux 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 par mes propres ordres.

Directive générale

Lorsque vous travaillez en équipe, vous n'êtes pas le public cible d'un morceau de code. Votre public est constitué des développeurs de votre équipe. N'écrivez pas de code qu'ils ne peuvent pas comprendre sans bonne raison.

1. À moins d'un inconvénient spécifique, tout le code doit être écrit en suivant un modèle ou une directive spécifique qui facilitera la maintenance par les développeurs qui le maintiendront. (Mise en garde: suivre de mauvaises habitudes simplement parce qu'elles sont actuellement dans la base de code est une pratique terrible.)
2. Si vous pouvez trouver une bonne raison d'utiliser un idiome spécifique à une langue qui ne soit pas facilement lisible par le public cible, ajoutez un commentaire. Si vous estimez que vous devez ajouter un commentaire à chaque ligne, 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 écrite par des développeurs java. Son style est donc très semblable à celui de java. Nous avons un ensemble de scripts Perl et un cadre qui a été écrit par un «gourou de Perl» qui a depuis quitté notre entreprise. Ce code contient bon nombre des idiomes les plus obscurs de Perl et aucun de nos développeurs, y compris moi-même, ne peut lire ce code Perl sans effort. Nous le maudissons souvent pour cela. :)

Si vous écrivez un bon code mais que vous pensez que vos collègues actuels ou futurs peuvent avoir des difficultés à 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 ni embarrasser personne dans une discussion de groupe.

Je n'appellerais pas votre exemple un tour, mais juste idiomatique. Si vous devez l'utiliser, cela dépend non seulement du niveau actuel de votre équipe, mais de la présence de (au moins certains) de vos coéquipiers disposés à apprendre de nouveaux idiomes. Bien sûr, vous devriez discuter de ce sujet avec eux et ne pas leur imposer ce style. Et vous ne devriez pas leur demander d’apprendre chaque jour 5 nouvelles choses ou "astuces". Mais honnêtement, si vous avez seulement des coéquipiers qui ne veulent pas apprendre quelque chose de nouveau, même si c'est si simple et si petit que cet idiome, vous devriez envisager de passer à une autre équipe.

En lisant cette question et les réponses et discussions ultérieures, il semble y avoir deux points. Le premier: est-il possible d’utiliser des fonctionnalités linguistiques avancées? La seconde: comment puis-je faire cela sans apparaître comme si je "montrais"?

Dans le premier cas, il est judicieux d'utiliser des améliorations et des fonctionnalités avancées. Par exemple: en C #, vous n'avez pas à utiliser les expressions Linq ou Lambda, mais la plupart des gens le font car cela rend le code plus ordonné et plus facile à comprendre, une fois que vous savez réellement ce qu'il fait. Au début, ça a l'air étrange.

Les gens s'habituent aux habitudes et, dans de nombreux cas, ils utilisent la même méthode pour faire le travail. Je suis aussi coupable que le prochain homme. 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 nous amène au deuxième point et c’est probablement là que vous rencontrerez peut-être le plus de résistance.

Pour la personne qui utilise le site Web, ils ne se soucient pas du style utilisé Tout ce qui compte pour eux, est-ce que ça marche? Est-ce rapide? Donc, s'il n'y a pas d'avantage en termes de performances, il n'y a pas de bonne ou de mauvaise manière dans l'exemple que vous donnez. Votre manière de rendre le code plus lisible ou non? Cela peut se faire une fois que vos collègues sont habitués.

Alors, comment introduisez-vous ces changements? Essayez de discuter avec vos collègues dans le sens suivant: saviez-vous que cette fonction peut être écrite de cette façon? Les revues de code et la programmation en binôme peuvent être un bon moment pour permettre une «pollinisation croisée» des idées. C'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 du temps à comprendre ce qui les motive, à comprendre leurs antécédents, puis à comparer et 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.

N'allez pas travailler pour la Royal McBee Computer Corp alors, car qui dira que vous n'êtes pas un programmeur inexpérimenté?

Bien sûr, il est bon d’écrire du code court et succinct et il pourrait être utile dans un environnement javascript (jusqu’à ce que quelqu'un produise un compilateur Js à télécharger sur les navigateurs, mais c’est une autre histoire).

Cependant, ce qui est important, c’est la capacité de votre code à survivre 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'est vous! (Je l'ai fait, bien sûr, la plupart des gens l'ont fait aussi, honnêtement, je blâme les délais trop agressifs).

C’est la seule chose importante à garder à l’esprit, alors même si je dirais oui, allez-y avec cet opérateur si cela fonctionne et est clair, et vos développeurs «inexpérimentés» (bien que cela leur soit péjoratif, je sais des 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 pourrait y avoir plus que des coïncidences)

Quoi qu'il en soit, si vous pouviez lire l'histoire de Mel , vous vous rendriez compte que les astuces ne sont pas les meilleures choses à intégrer dans un code, même si Mel était un véritable programmeur de premier ordre. Cela fait payer à tout argument où quelqu'un dit qu'il peut écrire un bon code et que tous les autres doivent en apprendre davantage pour suivre le rythme.

Eh bien, pour commencer, cela ressemble à 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 devriez éviter le code simplement parce que les autres ne le comprendraient pas - vous devriez l'écrire de la manière la plus claire et la plus 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 "quiconque le comprendra-t-il".

Ecrivez clairement que vous n’avez aucune difficulté à comprendre et laissez les autres travailler pour améliorer leurs compétences - ne vous handicapez pas afin de ne pas épargner aux autres un problème hypothétique.

Je voudrais discuter avec mes coéquipiers du type de normes de codage que nous souhaitons, car il s’agit surtout de savoir comment faire ce que nous pouvons faire de plusieurs façons pour notre base de codes. S'il y avait un consensus, ce serait ma tentative initiale de réponse.

Si ce n’est pas le cas, j’examinerai probablement le type de norme proposée qui a du sens et la mettrai en pratique une fois que je l’aurai clarifiée avec la direction et une partie de l’équipe. L’idée ici est de s’assurer que la gestion est acceptable avec cette idée et que je ne me contente pas de faire ce que je veux et que je force ensuite tout le monde à l’accepter.

Je regarderais cela plus comme la question du type de normes et de pratiques de votre équipe plutôt que de simplement le niveau de compétence car il y a plusieurs façons d'évaluer le code. Comment bien 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 dans les yeux de celui qui regarde.

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 de sauvegarder le code source sous la forme de sexps (oui, comme pour lisp). Ensuite, la source est lue, l'éditeur la déparre dans la syntaxe et la typographie (vous savez, les espaces, les tabulations, les virgules), la forme que l'utilisateur préfère.

De cette façon, vous pouvez taper et lire x = x || 10et les autres programmeurs le liront comme

if (0 == x) { x = 10;}

Emacs a toutes les pièces pour le faire facilement.

Plutôt que de simplifier le code, pourquoi ne pas améliorer la qualité de l'équipe? La formation, l’encadrement, l’éducation et l’amélioration des pratiques d’embauche peuvent grandement contribuer à l’amélioration continue.
L'étatisme, la pourriture du code, le refus d'améliorer et d'innover parce que quelqu'un ne veut pas travailler à l'amélioration de soi-même ne font que causer des problèmes sur toute la ligne, et le plus tôt possible.

Bien sûr, dans le cas spécifique que vous montrez, vous essayez simplement d’être intelligent et d’écrire délibérément du code obfusqué, ce qui n’est jamais une bonne idée. Le code doit d’abord et avant tout être lisible, facilement compréhensible, et non pas écrit pour montrer à quel point vous êtes habile à créer quelque chose dans le moins de déclarations possible (sauf cas particuliers, comme lorsque davantage de déclarations conduiraient à une performance inacceptable, auquel cas de nombreux commentaires sont appelés pour).