Devrais-je suivre un mauvais style de codage juste pour suivre les conventions établies sur mon lieu de travail?


102

Je travaille à mon travail depuis environ un an. Je travaille principalement dans notre interface graphique qui utilise des méthodes d'un backend C, mais je n'ai généralement pas à les traiter, sauf pour les valeurs de retour. Notre interface graphique est structurée assez raisonnablement, compte tenu de nos limites.

J'ai été chargé d'ajouter une fonction à la partie en ligne de commande du programme. La plupart de ces fonctions ont une longueur de 300 lignes et sont difficiles à utiliser. J'essaie de rassembler des morceaux pour obtenir des informations d'alarme précises, et j'ai du mal à rester organisé. Je sais que je complique davantage mes tests en le faisant dans une seule fonction longue.

Devrais-je tout conserver dans une fonction énorme, selon le style des fonctions existantes, ou dois-je encapsuler les alarmes dans leurs propres fonctions?

Je ne sais pas s'il est approprié d'aller à l'encontre des conventions de codage en vigueur ou si je devrais mordre la balle et rendre le code un peu plus compliqué à écrire pour moi-même.

En résumé, je compare

showAlarms(){
    // tons of code
}

contre

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

EDIT: Merci pour le conseil de tous, j’ai décidé que je concevrais mon code factorisé, puis que je demanderais ce qu’ils voulaient, et s’ils le voulaient tout en un, je pouvais simplement couper de mon code factorisé et le reconvertir en 1 grande fonction. Cela devrait me permettre de l'écrire et de le tester plus facilement, même s'ils veulent tout le code dans une seule définition.

MISE À JOUR: Ils ont fini par être satisfaits du code pondéré et plus d'une personne m'a remercié d'avoir créé ce précédent.


117
Il est tout à fait douteux que la société pour laquelle vous travaillez considère que vos fonctions doivent compter 300 lignes, car «c'est ce que nous avons toujours fait». Ce ne sont pas des "conventions de style de codage"; c'est juste un mauvais style.
Robert Harvey

64
C’est le genre de chose que vous devriez discuter avec les autres membres de votre équipe pour déterminer quelles pratiques vous considérez comme des conventions qu’ils considèrent importantes pour tout le monde et quelles sont les choses que quelqu'un vient de faire et que vous ne faites pas. besoin d'imiter. Il y aura sans doute un peu des deux.
Servy

17
@beginnerBinx Cela dépend simplement de la façon dont vous le formulez. Ne le dites pas comme suit: "X fait quelque chose de vraiment stupide, dois-je aussi faire cette chose stupide?" mais plutôt comme quelque chose comme: "Je remarque que X fait cette seule chose, y a-t-il une raison particulière pour laquelle il le fait ainsi; serait-ce un problème si je ne faisais pas la même chose en écrivant Y?" Il leur appartient ensuite de décider s’ils veulent s’opposer à l’ancien code ou expliquer pourquoi ils doivent le faire de cette façon (à contrecœur ou avec enthousiasme).
Servy

11
Un bon ou un mauvais style est souvent discuté et rarement convenu. L'enseignement universitaire est que les fonctions doivent être courtes, mais si cela masque le sens, ne le faites pas. Le test devrait être la clarté, plutôt que de suivre sans réfléchir un ensemble de règles.
Rapidement

9
Les personnes aléatoires sur Internet ne peuvent pas lire vos coéquipiers, donc toutes les réponses que vous obtenez ici ne sont que les préférences personnelles de chacun. Tu devrais parler à ton équipe. La fonction longue est-elle un principe de conception délibéré? Voudraient-ils que vous continuiez le style de longue fonction ou voudriez-vous écrire ce que vous considérez comme le plus propre?
JacquesB

Réponses:


102

C'est vraiment entre vous et vos coéquipiers. Personne d'autre ne peut vous dire la bonne réponse. Cependant, si je peux oser lire entre les lignes, le fait que vous appeliez ce style "mauvais" donne des informations suggérant qu'il est préférable de le ralentir. Très peu de styles de codage sont en fait "mauvais". Il y en a que je ne voudrais pas utiliser moi-même, mais ils ont toujours une comptine ou une raison. Cela suggère, pour moi, que l'histoire ne se limite pas à ce que vous avez vu jusqu'à présent. Poser des questions serait un très sage appel. Quelqu'un peut savoir quelque chose que vous ne connaissez pas.

Je me suis heurté personnellement à cela lors de ma première incursion dans le codage critique en temps réel. J'ai vu le code comme ceci:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

En tant que développeur OO C ++ brillant et brillant que j'étais, je les ai immédiatement informés des risques de bogues qu'ils rencontraient en verrouillant et en déverrouillant manuellement les mutex, plutôt que d'utiliser RAII . J'ai insisté pour dire que c'était mieux:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

Beaucoup plus simple et plus sûr, non?! Pourquoi obliger les développeurs à se rappeler de déverrouiller leurs mutex sur tous les chemins de contrôle quand le compilateur peut le faire pour vous!

Eh bien, ce que j’ai découvert par la suite, c’est qu’il y avait une raison de procédure à cela. Nous devions confirmer que, effectivement, le logiciel fonctionnait correctement et qu'il existait une liste limitée d'outils que nous étions autorisés à utiliser. Mon approche avait peut-être été meilleure dans un environnement différent, mais dans l'environnement dans lequel je travaillais, mon approche pourrait facilement multiplier le travail de vérification de l'algorithme, car je venais d'introduire un concept C ++ de RAII dans une section de code. cela a été tenu à des normes qui étaient vraiment plus enclins à la pensée de style C.

Donc, ce qui me paraissait mauvais, carrément dangereux, le style de codage était en fait bien pensé et ma "bonne" solution était en fait la solution dangereuse qui allait poser problème à l'avenir.

Alors demandez autour de vous. Il y a sûrement un développeur senior qui peut travailler avec vous pour comprendre pourquoi ils le font de cette façon. Ou bien, un développeur expérimenté peut vous aider à comprendre les coûts et les avantages d'un refactor dans cette partie du code. De toute façon, demandez autour de vous!


60
On peut soutenir que la partie la plus dangereuse de l'exemple de mutex est le manque apparent de commentaires de code expliquant pourquoi il ne pouvait pas utiliser RAII. Accordé, si ce verrouillage / déverrouillage explicite est partout dans la base de code, il pourrait être difficile d’ajouter un commentaire pour chaque instance. Dans ce cas, il faudrait peut-être rédiger un document de base avec lequel les nouveaux développeurs doivent être familiarisés.
Kelvin

10
Bien sûr, il est toujours bon de parler à une personne âgée et la refactorisation doit être effectuée avec soin (et avec des tests). Et bien sûr, la concurrence / mutex est une bête spéciale en soi. Mais lors de la visualisation de fonctions comportant plus de 300 lignes, je ne voudrais pas investir trop de temps dans la recherche d'une "raison technique cachée" pour laquelle ces fonctions sont trop volumineuses. La raison pour laquelle les fonctions deviennent trop longues sont toujours les mêmes et elles ne sont pas techniques.
Doc Brown

8
@DocBrown Ce n'est pas parce qu'ils ne sont pas techniques qu'ils ne sont pas des raisons. Il est important que les développeurs se rappellent qu’ils font partie d’une machine plus grande. (Je ne compte pas le nombre de fois où j'ai dû réapprendre cette leçon.)
Cort Ammon

4
@ DocBrown De toute façon, ce sont les développeurs seniors avec qui on devrait parler. J'ai choisi l'exemple que j'ai fait parce qu'il est facile de trouver d'innombrables arguments pour expliquer pourquoi un code stupide est stupide. Il est plus difficile de trouver les arguments pour lesquels un code qui a l'air stupide n'est pas stupide.
Cort Ammon

3
@DocBrown D'après vos commentaires et réponses, je pense pouvoir dire que la différence de nos opinions réside dans le fait que vous partez du principe que le code est déjà "mauvais", sur la base des preuves que vous avez données, alors que je préférerais prenez des chemins qui explorent si le code est "mauvais" en premier.
Cort Ammon

84

Honnêtement, croyez-vous qu’avoir des fonctions difficiles à utiliser, avec 300 lignes, n’est qu’une question de style? Donc, suivre le mauvais exemple pourrait garder le programme global dans un meilleur état en raison de la cohérence? Je suppose que vous ne le croyez pas, sinon vous n’auriez pas posé cette question ici.

Je suppose que ces fonctions sont si longues parce que dans notre entreprise, il y a beaucoup de programmeurs médiocres qui empilent les caractéristiques, sans se soucier de la lisibilité, de la qualité du code, de la désignation correcte, des tests unitaires, de la refactorisation, et ils n'ont jamais appris à créer des abstractions appropriées. . Vous devez décider vous-même si vous voulez suivre ce troupeau ou si vous voulez être un meilleur programmeur.

Addendum, en raison des commentaires: "300 lignes" et "difficile à utiliser" sont des indicateurs puissants de mon humble avis pour un code incorrect. Selon mon expérience, il est très peu probable qu'il existe une "raison technique cachée" pour laquelle un tel code ne puisse pas être mis en oeuvre de manière plus lisible, comparable à l'exemple de la réponse de Cort Ammon. Cependant, je suis d'accord avec Cort, vous devriez en discuter avec les responsables de l'équipe, non pas pour trouver des raisons obscures expliquant pourquoi le code ou ce "style de style" ne peut pas être modifié, mais pour savoir comment le code peut être remanié en toute sécurité sans casser des choses. .


127
Même les programmeurs compétents commettent ces crimes dans des délais serrés.
Gardenhead

13
@gardenhead, je peux comprendre de ne pas refactoriser une fonction de 300 lignes pour gagner du temps, mais il n’existe aucun moyen possible d’écrire une fonction de 300 lignes pour vous faire gagner du temps.
Dangph

39
@gardenhead: quand je vais chez un chirurgien parce que j'ai besoin d'une aide urgente, je m'attends toujours à ce qu'il prenne le temps de se laver les mains avant de commencer à jouer sur moi. C'est une chose que beaucoup de gens doivent apprendre dans notre entreprise pour acquérir de réelles compétences: laissez toujours le code dans un état meilleur qu'il ne l'était auparavant et cela améliorera également la capacité de respecter les délais. Les fonctions de 300 lignes se développent généralement de jour en jour, par des personnes indifférentes, et elles utiliseront toujours "la date limite" comme excuse.
Doc Brown

17
@Dangph, cela vous fait gagner du temps lorsque vous ajoutez seulement 5 lignes à la fonction au lieu de la refactoriser. Celles-ci augmentent généralement lorsque la fonction initiale est longue (plus de 30 lignes) et que le prochain programmeur pense "ce n'est pas mon code, je ne refactoriserai pas pour le casser, ajoutez simplement quelques lignes ici et là".
Džuris

7
@Juris, si je comprends bien, la question concerne la création d'une nouvelle fonction, pas la refactorisation des fonctions existantes. Si vous écrivez une nouvelle fonction, vous ne gagnerez pas de temps en la transformant en une seule fonction monstre.
Dangph

42

Non.

Dans le livre Pragmatic Programmer, l'auteur parle de la théorie de la fenêtre brisée .

Cette théorie dit:

Considérons un bâtiment avec quelques fenêtres cassées. Si les fenêtres ne sont pas réparées, les vandales ont tendance à casser quelques fenêtres de plus. Finalement, ils peuvent même pénétrer dans le bâtiment et, s’il est inoccupé, devenir des squatters ou allumer des feux à l’intérieur.

Ou considérons un trottoir. Une litière s'accumule. Bientôt, plus de déchets s'accumulent. Finalement, les gens commencent même à laisser des sacs d'ordures dans les restaurants à emporter ou même à cambrioler des voitures.

Dans le livre, l'auteur écrit un parallèle entre cette théorie et le code. Une fois que vous avez trouvé un code comme celui-ci, vous vous arrêtez et vous vous posez la même question.

Et la réponse est non.

Une fois que vous avez quitté cette fenêtre cassée (dans notre cas, un code incorrect), cela aura pour effet que tout le monde laissera des fenêtres cassées

Et un jour, le code va s'effondrer.

Donnez une copie de Clean Code et Clean Coder à tout le monde.

Et pendant que vous êtes dans le sujet, une copie de TDD est également une bonne copie .


6
Que se passe-t-il si la base de code est une serre avec seulement des fenêtres brisées?
Alan Shutko

8
@AlanShutko Ensuite, assurez-vous que votre CV est à jour? Trouver un autre employeur maintenant .
David Montgomery

12
Le code "s'effondre" rarement. Il devient de plus en plus difficile d'ajouter de nouvelles fonctionnalités, cela prend de plus en plus de temps et les estimations pour nettoyer le code vont augmenter - ce qui signifie qu'il est encore plus difficile d'obtenir du temps nécessaire pour le nettoyage nécessaire.
Doc Brown

8
Wow, quelle analogie arbitraire semble être la théorie de la "fenêtre cassée".
Samthere

4
TDD n'a rien à voir avec ça. Que vous optiez pour une conception de pilote Business / Domaine / Test / Nothing / qui ne change rien, suivez les bases du code propre. Désolé, mais c'est vraiment fatigant de voir "TDD" cité partout où ce n'est même pas dans le sujet
Walfrat

25

Oui, vas-y. Structure! = Style

Vous parlez de structure, pas de style. Les directives de style ne prescrivent pas (généralement) une structure, celle-ci étant généralement choisie pour son adéquation à un problème spécifique, et non pour une organisation.

Faites attention

Assurez-vous simplement que vous ne causez pas de conséquences négatives dans d'autres domaines qui ne vous ont peut-être pas été causés. Par exemple,

  • Assurez-vous de ne pas compliquer les différences ou les fusions de code, car vous avez effacé toute ressemblance avec le code existant.
  • Assurez-vous que les flux d'exception remontent correctement et que les traces de pile ne sont pas polluées par une énorme pile de bêtises illisibles.
  • Assurez-vous de ne pas exposer accidentellement des points d'entrée publics qui poseraient des problèmes s'ils étaient appelés directement (ne les mettez pas sur la carte et / ou ne les exportez pas).
  • N'encombrez pas l'espace de noms global, par exemple si vos petites fonctions requièrent toutes une sorte de contexte global précédemment déclaré dans la portée de la fonction locale.
  • Assurez-vous de consulter tous les journaux et demandez-vous si vous étiez dans l'équipe de support si les journaux générés par votre code seraient déroutants s'ils étaient entrelacés avec les journaux de tout code que vous ne touchez pas.
  • Assurez - vous que vous ne respectiez style existant, par exemple , même si elles utilisent la vieille école notation hongroise et rend vos yeux saignent, restent compatibles avec la base de code général. La seule chose plus pénible que de lire la notation hongroise est de lire du code qui utilise une douzaine de types de notation différents selon qui a écrit quoi.

Sois gentil

N'oubliez pas que vous faites partie d'une équipe. Même si un bon code est important, il est également essentiel que les membres de votre équipe soient en mesure de gérer les informations que vous avez écrites lorsque vous partez en vacances. Essayez de vous en tenir à un flux qui aura du sens pour les gens qui sont habitués à l'ancien style. Ce n’est pas parce que vous êtes le type le plus intelligent de la salle que vous devriez parler au-dessus des têtes!


"Essayez de vous en tenir à un flux qui aura du sens pour les gens qui sont habitués à l'ancien style." - Alors, conseillez-vous de programmer de la même manière que tout ce que le clown incompétent faisait auparavant? L'ajout de la fonction 300 lignes ne va pas faciliter la tâche.
BЈовић

11
Je n'ai pas dit de s'en tenir à un flux similaire. J'ai dit s'en tenir à un flux qu'ils comprendront.
John Wu

2
Bon conseil. Lorsque j'ai refactoré une seule commande en 5 fonctions dans cette réponse, j'ai modifié subtilement la sémantique en pré-calculant les valeurs dans une expression logique qui, à l'origine, n'étaient calculées que conditionnellement. Les critiques l'ont bien compris ;-). Le conseil sérieux est de revoir et de tester à fond. Chaque changement peut introduire des erreurs, ce qui peut être la raison principale pour laquelle personne ne les a faites.
Peter A. Schneider

6

Je ne vois pas cela comme une convention de code. Je vois cela comme une personne qui ne comprend pas comment écrire un code maintenable facile à comprendre. Je diviserais votre code en différentes fonctions au fur et à mesure que vous suggéreriez et renseigneriez votre équipe sur les avantages de le faire tout en essayant de comprendre pourquoi elles estimaient que les fonctions à 300 lignes étaient acceptables. Je serais très intéressé d'entendre leur raisonnement.


1
" Il n'y a pas de raison, c'est juste notre politique. "

5

La réponse est dans la révision du code.

La vraie question est de savoir si vous introduisez du code bien factorisé, serez-vous le seul à vouloir travailler avec?

Comme la plupart des gens ici, je pense que les fonctions de 300 lignes sont une abomination. Cependant, emmener Windex dans une décharge ne fera pas beaucoup de bien. Le problème n'est pas le code, ce sont les codeurs.

Il ne suffit pas d'avoir raison. Vous devez vendre des gens sur ce style. Au moins en le lisant. Si vous ne le faites pas, vous finissez comme ce pauvre type: viré parce que vos compétences sont trop élevées par rapport à vos collègues

Commencer petit. Demandez autour de vous et découvrez si quelqu'un d'autre favorise les petites fonctions. Mieux encore, fouillez autour de la base de code et voyez si vous pouvez savoir qui écrit les plus petits (vous constaterez peut-être que le code le plus laid est le code le plus ancien et que les codeurs actuels écrivent un meilleur code). Parlez-leur à ce sujet et voyez si vous avez un allié. Demandez-leur s'ils connaissent quelqu'un d'autre qui ressent la même chose. Demandez-leur s'ils connaissent quelqu'un qui déteste les petites fonctions.

Rassemblez ce petit groupe et discutez des changements à apporter. Montrez-leur le type de code que vous souhaitez écrire. Assurez-vous qu'ils peuvent le lire. Prenez toutes les objections au sérieux. Faites les changements. Obtenez votre code approuvé. Vous avez maintenant le pouvoir d'une réunion derrière vous. Encore quelques-uns d'entre eux et vous pouvez produire un document d'une page qui accepte explicitement le nouveau style que vous avez introduit.

Les réunions sont des choses étonnamment puissantes. Ils peuvent produire du poids. L'influence est ce que vous utiliserez pour combattre ceux qui s'opposent à ce mouvement. Et c'est ce que c'est à ce stade. Un mouvement. Vous vous battez pour le droit d'améliorer le statu quo. Les gens ont peur du changement. Vous aurez besoin de parler doux, cajole et prod. Mais avec un peu de chance, vous finirez par être accepté.


5
S'il faut autant de socialisation et de multiples réunions pour convaincre les développeurs qu'une méthode 300 lignes est trop longue, alors je ne pense pas que parler va aider. Le problème avec l'approche ci-dessus est que si vous demandez la permission d'écrire un bon code, vous êtes sur la défensive. Mais si vous écrivez simplement du bon code et prenez le temps de modifier le code existant, quiconque s'objecte est sur la défensive pour expliquer en quoi une méthode à 300 lignes est bonne et justifier de passer le temps qu'il faut pour le remettre en place.
Brandon

3
Je peux vous dire que si j'étais invité à une série de réunions pour discuter de lignes de code par limite de fonction, je trouverais un moyen d'échapper à ces réunions. Il n'y a pas de chiffre exact et vous ne serez jamais d'accord avec les gens. Parfois, il faut montrer aux gens un meilleur moyen.
Brandon

Parfois, diviser une fonction énorme (et mieux nommer les choses, ajouter des commentaires et de la documentation au fur et à mesure que je la comprends, est la première étape nécessaire avant de procéder à un changement en toute sécurité.
JDługosz

@Brandon Vous ne voulez probablement pas que cela sonne ainsi, mais ce que j'entends dire, c'est que vous avez raison et que tout le monde peut s'en occuper. Tant que votre code fonctionne, cela n'a pas d'importance si le reste de l'équipe ne le comprend pas. Ce n'est certainement pas la peine de prendre le temps de leur apprendre quoi que ce soit. Vous êtes parfaitement heureux de les voir continuer à créer des fonctions de 300 lignes pendant que vous écrivez du code à votre manière.
candied_orange

1
@CandiedOrange Je ne voulais certainement pas aller contre l'équipe. Ce que je voulais dire, c'est que certains sujets sont mieux appris en les voyant en action, mais essayer de faire en sorte qu'une équipe prenne une décision démocratique sur le style ne sera pas productif. J'ai vu la cohérence utilisée comme une excuse pour écrire du code illisible. Résultat? Code plus illisible. Je pourrais organiser une série de réunions pour en discuter ou simplement régler le problème, puis montrer aux gens les résultats.
Brandon

3

Parfois, il faut suivre le courant.

Comme vous l'avez dit, vous avez été chargé d'implémenter une fonction dans une base de code existante.

Peu importe le gâchis, et je crois comprendre qu'il est tentant de le nettoyer. mais dans le monde des affaires, vous n'avez pas toujours la possibilité de refactoriser le code.

Je dirais simplement faire ce que vous avez été invité à faire et aller de l'avant.

Si vous estimez qu’il vaut la peine de refactoriser ou de réécrire, remettez-le à la discussion avec l’équipe.


2
Si vous demandez une autorisation pour chaque refactoring, vous aurez pour toujours un code non maintenable, ce qui est dangereux pour une entreprise. Les gestionnaires ne se penchent que sur le coût d'une modification, mais rarement sur le coût d'une non- modification.
Brandon

5
OP a été invité à écrire une fonction ne modifiant pas des centaines de lignes de code
meda

2
@meda exactement! Je suis dans la même situation. Je développe de nouveaux modules pour l'intranet de la société et je découvre ce que l'on pourrait décrire comme "des années de négligence irremplaçable", les logiciels de serveur et les bibliothèques n'ayant pas été mis à jour depuis 2006. Je ne suis pas censé nettoyer ce gâchis , mais il me faut plus de temps pour coder à cause des limitations. (Imagine MySQL 5.2, MySQL 5.0). Je ne peux rien mettre à jour car le code existant ne fonctionnera probablement pas sur les versions les plus récentes en raison d'un code obsolète.
Roetnig

3
"Si ce n'est pas cassé, ne le répare pas." J'ai une voiture de 20 ans qui coule un peu d'huile. Ça vaut le coup de dépenser de l'argent? Non fiable? Oui.

3

Avant d'affirmer que les pratiques sont mauvaises, je commencerais par comprendre les raisons pour lesquelles de grandes méthodes et d'autres pratiques peuvent paraître mauvaises.

Ensuite, vous devrez vous assurer que la couverture du test est assez élevée ou vraiment élevée (dans la mesure du possible sans refactorisation majeure). Si ce n'est pas le cas, je travaillerais pour que la couverture soit vraiment élevée même si vous n'avez pas écrit le code. Cela aide à établir un rapport et la nouvelle équipe à vous prendre plus au sérieux.

Une fois que vous avez ces bases couvertes, personne dans leur bon esprit ne vous défierait. En tant qu'objet bonus, effectuez des micro-analyses comparatives et cela ajoutera vraiment à votre cas.

Souvent, la manière dont vous le formulez contribue grandement à changer la culture du code. Mener par l'exemple. Ou mieux encore, attendez un morceau de code que vous puissiez écrire - refactor et unit testez l'enfer et l'alto - vous serez entendu.


Je ne suis pas en train de refactoriser le code actuel, je suis juste en train d'écrire une nouvelle fonction. pas été fait dans cette partie de la base de code.
Justin

1
Ont-ils des règles pour vous assurer d'écrire de nouvelles méthodes sur plus de 300 lignes? sinon, je l'écrirais de la bonne façon. mais je ferais tout mon possible pour m'assurer de les tester, y compris les branches. J'ai vécu des expériences similaires et généralement vous les gagnez. Le truc est de le faire au fil du temps et de construire une relation.
skipy

3

Ce type de question est essentiellement " s'il te plaît, lis mes pensées à mes coéquipiers ". Les personnes aléatoires sur Internet ne peuvent pas faire cela, alors toutes les réponses que vous obtiendrez sont simplement des opinions personnelles des gens sur le style de codage. Le consensus est que des méthodes plus courtes sont préférables, mais vous semblez déjà le penser vous-même, donc inutile de reformuler cela.

Ainsi, la base de code actuelle semble utiliser un style de codage différent de celui que vous préférez. Que devrais tu faire? D'abord, vous devez comprendre:

  1. Est-ce une décision de conception délibérée prise en charge par votre équipe actuelle?
  2. Veulent-ils que vous suiviez ce style?

Il n'y a qu'une seule façon de le savoir. Demander .

Il peut y avoir plusieurs raisons pour avoir de longues fonctions. Cela peut être dû au fait que l’équipe estime que les longues fonctions valent mieux que les multiples fonctions courtes. Cela pourrait également être dû au fait qu’il s’agit d’un code hérité, et l’équipe préfère que le nouveau code suive un design plus épuré. Ainsi, l’un ou l’autre choix pourrait vous causer des problèmes en tant que développeur, si vous ne parlez pas à l’équipe et ne comprenez pas son raisonnement.


1
Je suis tout à fait d’accord et ajoute: «Pourriez-vous vous faire virer ou avoir des ennuis pour ne pas suivre ce que d’autres ont fait?" Alors la réponse est oui! Après chaque mauvaise chose, l’entreprise vous demande de faire et de vous en occuper.
Rob

1

Il y a différents niveaux de "style".

À un niveau, faisant généralement partie des conventions de codage, cela signifie où placer des espaces, des lignes vides, des crochets et comment nommer des éléments (casse mixte, caractères de soulignement, etc.).

À un autre niveau, le modèle de programmation, qui évite parfois la statique ou utilise des interfaces sur des classes abstraites, explique comment exposer les dépendances, voire éviter certaines fonctionnalités du langage ésotérique.

Ensuite, il y a les bibliothèques et les frameworks utilisés par le projet.

Parfois, il y aura une limite maximale sur la taille de la fonction. Mais il y a rarement une limite minimale! Donc, vous devriez trouver quelles sont les choses que les pouvoirs jugent importantes et essayer de les respecter.

Vous devez déterminer si l'équipe est opposée à la refactorisation du code existant, ce qui doit être fait indépendamment de l'ajout d'un nouveau code lorsque cela est possible.

Cependant, même s'ils ne veulent pas refactoriser le code existant, vous pourrez peut-être introduire des couches dans des abstractions pour le nouveau code que vous ajoutez, ce qui signifie qu'avec le temps, vous pourrez développer une meilleure base de code et éventuellement migrer l'ancien code. son entretien demande.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.