Comment se former pour éviter d'écrire du code "intelligent"? [fermé]

75

Savez-vous ce sentiment quand vous avez juste besoin de montrer ce nouveau tour avec Expressions ou de généraliser trois procédures différentes? Cela n’a pas besoin d’être à l’ échelle Architecture Astronaut et peut en fait être utile, mais je ne peux pas m'empêcher de remarquer que quelqu'un implémenterait la même classe ou le même package de manière plus claire, simple (et parfois ennuyeuse).

J'ai remarqué que je concevais souvent des programmes en résolvant le problème , parfois délibérément et parfois par ennui. Dans les deux cas, je pense généralement honnêtement que ma solution est limpide et élégante, jusqu’à preuve du contraire, mais c’est généralement trop tard. Il y a aussi une partie de moi qui préfère les hypothèses non documentées à la duplication de code et l'habileté à la simplicité.

Que puis-je faire pour résister à l'envie d'écrire du code "astucieux" et quand la cloche sonne-t-elle pour que je me trompe ?

Le problème est de plus en plus préoccupant, car je travaille maintenant avec une équipe de développeurs expérimentés. Parfois, mes tentatives pour écrire du code intelligent me semblent fous, même après que le temps ait dissipé l'illusion d'élégance.

Dan
la source
5
légèrement hors sujet, mais thedailywtf.com/Articles/…
@ Joe: c'est très sur le sujet, merci! J'ai lu l'article mais c'est un plaisir de le redécouvrir maintenant.
Dan
33
Déboguer beaucoup de code intelligent ... cela devrait faire l'affaire.
Dan Olson
@Joe la base de données de bases de données lien dans cet article est à tomber par terre.
Jnewman
Réponse courte: le code le plus court et le plus simple l'emporte. Éliminez les doublons, mais n’ajoutez pas de calques "uniquement parce que". Le refactoring de Fowler peut vous donner un aperçu.
kevin cline

Réponses:

54

Le problème est de plus en plus préoccupant, car je travaille maintenant avec une équipe de développeurs expérimentés. Parfois, mes tentatives pour écrire du code intelligent me semblent fous, même après que le temps ait dissipé l'illusion d'élégance.

Votre solution se trouve ici. Je présume que "expérimenté" dans ce contexte signifie "plus expérimenté que vous." À tout le moins, vous les respectez clairement. C’est une opportunité d’apprentissage précieuse - dans l’hypothèse où votre ego pourrait en subir les conséquences. (Choses ennuyeuses, egos. Dommage, nous en avons besoin alors.)

Avez-vous des critiques de code avec ces gens? Si c'est le cas, s'ils ne le font pas déjà, demandez-leur explicitement de vous appeler sur vos conneries. Mentionnez que vous avez remarqué une tendance en vous à sur-concevoir, à utiliser un marteau-piqueur pneumatique haut de gamme méticuleusement conçu (de préférence manipulé par une sorte d'androïde des travailleurs de la route automatisé) lorsqu'un marteau à griffe serait plus que suffisant .

Vous pouvez souvent vous retrouver à vous tortiller sur votre siège alors que votre visage devient rouge lors de l'examen du code. Endure-le. Vous apprenez.

Ensuite, une fois que vous en avez quelques-uns à votre actif, faites attention aux moments où vous pensez que vous êtes peut-être en train de trop concevoir. Quand ces moments-là viennent, demandez-vous: "Si quelqu'un m'interroge à ce sujet lors de la révision du code, puis-je défendre ma solution comme étant la meilleure disponible? Ou y a-t-il une solution plus simple que j'abandonne?"

Parfois, l'examen par les pairs est le meilleur moyen de bien analyser votre propre travail.

BlairHippo
la source
Merci pour une très bonne réponse. Non, nous n'avons pas de révision de code, principalement parce que le projet est volumineux et que les ressources du client sont très limitées. Mais je suppose que je peux me tester en demandant "puis-je défendre ma solution comme étant la meilleure disponible" à la fin de chaque journée?
Dan
7
Aucun commentaire de code? Urk. J'écrirais quelque chose de tout à fait juste et horrifié, mais j'ai aussi travaillé dans cet environnement. Ils prennent beaucoup de temps et sont un peu pénibles pour tout le monde, mais ils sont vraiment précieux pour le projet en cours et pour votre développement personnel. Si le sujet de "Devrions-nous peut-être faire des revues de code?" jamais arrive, assurez-vous que vous êtes comme "Enfer oui!" Et s'ils ne se font pas imposer des échéances imminentes, vous pouvez demander à des collègues que vous respectez de donner du travail si vous n'êtes pas sûr d'un code-revue-lite informel.
BlairHippo
1
Eh bien, le projet est en quelque sorte une start-up et, à cause de quelques erreurs de planification, du côté du client également, nous nous trouvons face à la situation lorsque nous devons réellement livrer rapidement, sinon cela ne vaut pas la peine. Je viens de parler à notre Premier ministre et il a confirmé que les délais serrés étaient la seule raison pour laquelle nous ne procédions pas à la révision du code, du moins pour le moment. Si le démarrage réussit et que les contraintes de temps deviennent plus souples, nous ferons peut-être les examens à l'avenir.
Dan
2
Oh mon. Cela semble excitant - avec toutes les connotations bonnes et mauvaises que le mot porte avec. :-) Bonne chance mec; J'espère que vous êtes au début de quelque chose de grand.
BlairHippo
8
@BlairHippo: Je viens de suivre votre conseil, je me suis calmé et j'ai gentiment demandé au collègue qui a souligné le problème posé par mes modifications de faire des examens informels avec moi, et il a accepté. Cela a également contribué à dissiper certaines maladresses de notre conversation (comme dans "vous écrivez du code complexe et je dois la réparer .."). Merci!
Dan
20

La meilleure chose à faire est de garder à l'esprit la maxime de Brian Kernighan:

«Le débogage est deux fois plus difficile que d’écrire le code. Par conséquent, si vous écrivez le code aussi intelligemment que possible, vous n'êtes pas, par définition, assez intelligent pour le déboguer. ”

Daniel Roseman
la source
1
Je suis entièrement d'accord avec la citation, mais la question est de savoir comment surmonter la tentation d'être un garçon intelligent . On peut vous dire de ne pas manger de glace lorsque vous êtes malade, mais parfois cela n’aide en rien.
Dan
13
+1 pour une maxime que chaque code doit savoir par cœur, mais -1 pour ne pas donner à l'OP une idée de la façon de l'appliquer à son propre travail. Donc, tout cela se résume à ne pas cliquer sur la flèche.
BlairHippo
2
Excellente citation, mais pas vraiment une réponse à la question du PO.
Jim G.
5
Bonjour Daniel, nous cherchons beaucoup plus qu'une citation: le site n'a d'utilité que lorsque les questions sont associées à des réponses longues et réfléchies, riches en expériences, en faits et en références. Y a-t-il autre chose que vous pouvez ajouter de votre propre expérience?
2
-1: Ne répond pas du tout à la question du PO.
Thomas Eding
15

Il existe généralement au moins trois solutions aux problèmes logiciels importants: la méthode évidente, la méthode complexe non évidente (astucieux) et la méthode simple non évidente (élégant). Une citation sur les auteurs est applicable ici:

Déposez tout ce qui vous passe par la tête et vous devenez écrivain. Mais un auteur est quelqu'un qui peut juger la valeur de ses propres affaires sans pitié et en détruire la plupart. - Colette

Vous ne pourrez pas écrire de code élégant avant de pouvoir juger de la valeur de votre propre code, sans pitié, et d'en détruire l'essentiel. Si vous jugez le code élégant en fonction du résultat final, cela vous semblera d'une simplicité trompeuse, mais cela nécessitera un ralentissement, un nombre considérable de brouillons, la recherche des conseils des autres et la suppression de ce qui ne se trouve pas sur la page. Cela signifie que même si votre code fonctionne parfaitement, vous vous demandez, à vous ou à un collègue, pourquoi quelque chose ne va pas, jusqu'à ce que vous soyez satisfait de la réponse. Cela peut sembler trop long, ou répétitif, ou vous pensez que le compilateur aurait pu attraper un certain type de bogue. La plupart des programmeurs expérimentés savent reconnaître facilement le code non élégant. L'astuce consiste à comprendre pourquoi .

C'est la méthode méthodique pour écrire du code plus élégant. De plus, il nécessite souvent un éclair de compréhension qui vous aide à examiner un problème sous un nouvel angle. C'est plus difficile à atteindre, mais il est utile de ralentir et de penser à un problème avant de se lancer dans le codage. Lorsque vous trouvez une bonne solution, cherchez-en une meilleure. Lire un autre code aide. Suivre des cours ou lire des livres sur les meilleures pratiques peut aider. L'apprentissage d'autres paradigmes de programmation aide. Demander conseil à des collègues dont vous admirez le code aide.

Karl Bielefeldt
la source
3
Cela me rappelle la citation d'un vieux mathématicien: "Il existe pour chaque problème une solution simple, élégante et fausse".
Joris Timmermans
9

Je voudrais ajouter aux réponses existantes, développer de manière TDD, de sorte que vous écrivez d’abord des tests sur ce que votre code devrait faire, puis que vous implémentez pour que vos tests passent au vert. De cette façon, vous ne remplissez que les conditions imposées par les tests. Puisque vous passerez le test, c’est un bon moyen de développer votre propre discipline.

Matteo Mosca
la source
J'essaie vraiment de m'imposer cela chaque fois que le temps le permet.
Jnewman
Écrire des tests après est également un bon moyen de détecter d’énormes erreurs dans votre code. C'est en quelque sorte auto-critique. Mais TDD est clairement la meilleure approche si vous commencez tout juste.
Vanna
6

Lorsque vous travaillez pour une équipe nombreuse et dynamique qui couvre plusieurs compétences et années, le développement évolue naturellement vers le niveau le plus bas du membre le plus conservateur ou le plus déficient intellectuellement, actuel ou historique.

Cela n’est peut-être pas nécessairement une mauvaise chose, car un code intelligent peut être plus difficile à déboguer, à intégrer dans une spécification technique et à prendre plus de temps à écrire, ce qui ralentit le temps de développement.

Il arrive parfois qu'un code intelligent soit important, par exemple lorsqu'il fournit l'efficacité et les gains de performance plus tard dans le cycle de maturité du logiciel, lorsque la performance devient une exigence.

Le code intelligent permet également de transmettre un code plus rapide, plus lisible et plus compréhensible à une équipe qui ne risque pas d’être exposée à une nouvelle fonctionnalité linguistique ou à un appel à la bibliothèque. Par exemple, quand un développeur junior m'a présenté pour la première fois à Linq, j'ai immédiatement ressenti un dégoût: inutile, difficile à déboguer, stupide et "intelligent". Après avoir joué moi-même et découvert à quel point les requêtes Linq peuvent être utiles et puissantes, j'ai investi le temps de l'apprendre et mon code DAL n'a jamais été aussi clair et lisible, ni plus facile à déboguer et à étendre.

Je regrette de ne pas avoir eu l'esprit ouvert auparavant et j'espère que je n'aurais pas été aussi sévère avec un développeur "aussi intelligent" junior.

Ce que je veux dire, c'est que le code "intelligent" DEVRAIT être suspect, mais nous ne devrions pas nous lancer dans une croisade, car cela pourrait étouffer la créativité et l'innovation.

EDIT: Je viens de me rendre compte que je n’ai pas répondu complètement à votre question. Si votre projet a la capacité d’écrire très facilement un code intelligent, l’équipe devrait peut-être adopter des normes de codage plus strictes afin de suivre un modèle et un style uniformes et distincts. Cela vous aidera à tracer les lignes de votre bac à sable pour ne pas vous perdre dans la rue à la poursuite d'un ballon.

arbre_érable
la source
6

Si 20% (votre% peut varier) ou plus de vos lignes ajoutées doivent être de la documentation - il est temps de prendre du recul et de repenser .

Je pense vraiment que vous devriez vous efforcer d’être intelligent, c’est un effet secondaire naturel de devenir plus compétent. Vous donner une directive générale telle que le% de commentaires nécessaires pour bien vous comprendre est un bon moyen de vous forcer à prendre du recul et à évaluer si utiliser cette nouvelle chose que vous avez apprise est un choix judicieux ou tout simplement un moyen de montrer votre nouveau jouet.

DKnight
la source
3
J'ai tendance à considérer la documentation / les commentaires comme un échec. Lorsque vous avez besoin de documenter / commenter quelque chose, cela signifie d’abord que votre code n’est pas clair. Malheureusement, il s'agit d'un objectif irréaliste et nous avons besoin de documentation à un moment donné. N'oubliez pas que cette partie du code devrait être réduite au minimum.
deadalnix
@deadalnix: Ce n'est pas un mauvais point. Je soupçonne que mon% serait plus élevé que la plupart des autres parce que je code habituellement dans un langage assembleur par ailleurs mort et lourdement macro. Plus difficile à lire et chaque nouvelle recrue doit apprendre la langue, il en résulte plus de commentaires.
DKnight
2
@deadalnix - documentation expliquant comment est un signe que votre code n'est pas clair. La documentation nécessaire pour expliquer le pourquoi est indispensable. J'ai vu trop de morceaux de code que je pouvais comprendre ce qu'ils ont fait mais pas la raison pour laquelle ils ont décidé de le faire de manière non intuitive. Cela rend très difficile à maintenir.
HLGEM
@HLGEM C'est discutable. Le manque de clarté du code peut provenir de bibliothèques / API mal conçues, d’un manque de clarté au sein même de la conception, comme une mauvaise séparation des problèmes. Nous vivons dans le monde réel et nos capacités sont limitées, nous avons donc définitivement besoin de documentation, mais chaque fois que nous en avons besoin, cela signifie que quelqu'un a écrit du code imparfait. Aucune documentation n'est une chose à faire - n'y songez même pas, mais une chose à laquelle vous devez penser tout le temps pour continuer à vous améliorer dans la bonne direction.
deadalnix
@deadalnix - Le code parfait n'est jamais une solution pratique dans le monde réel.
JeffO
4

Je ne peux pas résister à essayer quelque chose d'intelligent.

Je le fais donc sur un projet de jouet, sur mon temps libre, à la maison.

Lorsque la nouveauté est épuisée, le problème est résolu.

Mike Dunlavey
la source
3

Je pense qu’une façon de savoir si votre code est trop "intelligent" est de prendre du recul et de vous poser les questions suivantes:

Si je devais imprimer une copie de ce code à quelqu'un qui n'a jamais travaillé sur ce projet / code, serait-il capable de le lire et de me décrire ce que la fonction fait (après leur avoir donné un bref contexte)? Si non, combien d'explications devrais-je faire? Comment pourrais-je expliquer cela à quelqu'un qui prend CS101?

S'il s'avère que vous devrez guider quelqu'un à travers chaque ligne ou la plupart des lignes d'une méthode ou d'une classe, c'est probablement trop intelligent. Si vous devez expliquer les constructions de langage (LINQ par exemple) à quelqu'un qui ne le connaît pas bien, c'est probablement OK. Si vous devez regarder une ligne et y réfléchir un peu avant de pouvoir l'expliquer, votre code doit être refactoré.

Becuzz
la source
J'ai entendu parler de cela "Rubber Ducking" lorsqu'il est appliqué à la résolution de problèmes; Lorsque vous êtes perplexe, essayez d’expliquer le problème à une personne qui n’en sait rien (comme, vous savez, votre duckie en caoutchouc) et voyez si la solution ne vous tombe pas sur les genoux. Je dois penser que cela fonctionnerait pour cela aussi.
BlairHippo
2

1) Se faire brûler avant pour que vous sachiez que c'est une mauvaise chose. Essayer de déboguer quelque chose d'il y a longtemps qui est intelligemment écrit est très amusant. Je pense que vous avez cela couvert.
2) Commentez votre code, expliquez ce que vous faites avant chaque section de code.
3) Si vous avez du mal à l'expliquer ou si vous ressentez le besoin d'insérer un diagramme, alors ce que vous venez de faire est trop intelligent et pourrait probablement être fait plus proprement.

Des solutions intelligentes aux problèmes peuvent être fantastiques, jusqu'à ce que vous deviez les déboguer ou les développer. Parfois, c'est la seule solution. Si vous parvenez à décrire avec précision ce qu'il fait et comment il le fait, des solutions intelligentes peuvent être acceptables.

J'utilise généralement des commentaires pour décrire ce que je fais avec une section de code. Si cela vous semble un peu déroutant, je décris aussi comment je le fais. Idéalement, le code devrait être simple et explicite. Mais si j’ai du mal à expliquer comment j’ai fait ce que je viens de faire, c’est un signe clair que je dois prendre du recul et essayer à nouveau.

Philippe
la source
2
L'astuce de commentaire fonctionne pour moi aussi. Entre autres raisons, j'inclus toujours un bloc de commentaires au-dessus des sous-routines non triviales comme une sorte de vérification finale de la santé mentale. Si je me trouve souvent obligé d'expliquer (ou même de m'excuser à l'occasion) des sections de code compliquées ou obtuses, des paramètres d'entrée étranges ou autre chose, c'est un signe d'alerte que je devrais peut-être repenser un peu la solution.
BlairHippo
@BlairHippo HA! "chèque de santé final" J'aime ça.
Philip
2

Une bonne façon de commencer à écrire du code simple est probablement de libérer la passion de l'intelligence sur un projet qui demande de l'intelligence . Le reste de la réponse est spécifique à .NET mais je suis sûr que l’on peut trouver des projets de niveau similaire dans n’importe quel autre langage.

Il existe des cadres d'injection de dépendance open source sur lesquels il suffit de demander des Expressionconnaissances en matière de trucs, de F # et de merveilleuses tâches pour lesquelles on peut vouloir l'essayer.

Si vous êtes amateur de mathématiques (et que votre langue est agnostique ), Project Euler est pour vous.

Dernier point, mais non le moindre, dans le monde .NET, Mono Project regroupe de nombreux domaines qui nécessitent l’attention des développeurs , dont certains sont assez compliqués. Que diriez-vous de contribuer à un outil d'analyse de code .NET statique open source ? Il y a une analyse de la VA impliquée, ainsi que des éléments de haut niveau. Jb Evain travaille toujours sur quelque chose d'intéressant, qu'il s'agisse de la bibliothèque de réflexion Cecil, du Expressionsupport ou d'un décompilateur .NET.

Si rien ne vous convient, démarrez simplement votre propre framework moqueur :-)

Dan
la source
2

Savez-vous ce sentiment lorsque vous avez juste besoin de montrer ce nouveau tour avec Expressions ou de généraliser trois procédures différentes?

Non

C’est l’une des raisons pour lesquelles je dis toujours que c’est une bonne chose que les nouveaux développeurs se retrouvent plongés dans un grand bazar de code non documenté à conserver et à refactoriser. Cela leur apprendra la réalité de maintenir un code trop «intelligent» qu'ils n'ont pas écrit et, espérons-le, instillera un peu d'empathie pour le pauvre con qui devra déboguer leur code d'ici 5 ans.

Grand maître b
la source
Je pense que cela est plus susceptible de les frustrer et de penser que LEUR code sera bien meilleur et élégant que les noobs qui ont écrit CE désordre. Personne n’écrit du code dans l’intention de rendre difficile sa maintenance.
Sara
2

Je pense que le sujet est bien choisi. C'est "cool" d'écrire une ligne de Perl qui fait dix mille choses en même temps, mais ça craint quand on doit la revisiter.

Sur une note différente, intelligente ou non, le code doit être documenté. Il existe un décalage inhérent d'impédance entre les langages de programmation acceptés par l'industrie et les concepts de haut niveau auxquels nous sommes habitués en tant qu'êtres humains dans notre pensée. Le code auto-documenté n’est tout simplement pas réalisable - jusqu’à ce qu’il devienne un langage naturel. Même le code Prolog doit être documenté car, quel que soit son niveau, il reste assez formel.

Le code impératif à grains fins sert à mettre en œuvre des plans à grains grossiers - qui doivent être documentés. Je ne veux pas avoir à lire toutes les 50 lignes de la méthode lorsqu'un commentaire rapide de feuille de route de 3 lignes suffira.

Édition ultérieure: un exemple plus éloquent est celui qui transcende les ordinateurs. Un livre peut être très bien écrit, mais nous voulons souvent le traiter à différents niveaux d'abstraction. Souvent, un résumé du livre fera l'affaire, et c'est ce que les commentaires peuvent offrir au code. Bien sûr, un code bien abstrait peut aller très loin dans l'auto-documentation, mais il ne peut pas vous donner tous les niveaux d'abstraction.

Et les commentaires peuvent également agir comme des notes de bas de page dans un livre, lorsque nous devons expliquer le processus de raisonnement derrière une revendication dans le texte principal sans le faire dérailler.

Dans ce contexte, j'estime que ma déclaration antérieure faisant référence au langage naturel transcendant le besoin de commentaires est incorrecte. Même le langage naturel, comme dans un livre, peut se prêter à la documentation, expliquer de manière fragmentée l'abstraction contenue dans le texte ou fournir des détours sans faire dérailler le texte principal. Avec la note, un code bien abstrait peut déjà avoir fait beaucoup pour être auto-documenté.

Enfin, les commentaires peuvent aider le codeur à conserver un niveau d'abstraction élevé. Souvent, je réalise que deux commentaires consécutifs que j'ai inclus dans une liste d'étapes ne parlent pas du même niveau d'abstraction, ce qui justifie immédiatement un regard critique sur ce que je fais avec ce code.

Certains problèmes transcendent le codage et l’affectent, tout comme d’autres activités. Les commentaires peuvent fournir cette aide pour clarifier la raison derrière et les facettes de notre code, et je les trouve un compagnon agréable qui parle un langage plus doux au bénéfice de la personne pour un changement.

Mihai Danila
la source
1

Comment? Continuez à montrer votre code à ces développeurs expérimentés. et quand vous êtes blasté d'être sophomorique et brillant, absorbez-le et demandez-leur comment ils le feraient et pourquoi (de manière non conflictuelle bien sûr).

Modifier à la lumière de -1:

Il y a bien des lunes, je me trouvais dans la même situation: j'avais un chef qui tremblait chaque fois que j'utilisais un pointeur dans Delphi ou l'expression 'with construct', un autre qui menaçait de me licencier si je n'arrêtais pas de court-circuiter tous mes booléens. avec 0-1 et en utilisant des variables d'une seule lettre partout.

J'ai appris parce que j'ai demandé pourquoi et ils ont pris la peine de s'expliquer parce qu'ils pensaient que je pourrais en arriver à quelque chose - LOL ...

Mikey
la source
1
Bonjour Mikey, nous recherchons beaucoup plus que des solutions uniques: le site n’est utile que lorsque les questions sont associées à des réponses longues et réfléchies, remplies d’expériences, de faits et de références. Y a-t-il autre chose que vous pouvez ajouter de votre propre expérience?
1

Est-ce que je ressens le besoin de montrer? Non plus maintenant. Comment ai-je passé au-delà? Comme la plupart des gens, surmontez toute autre mauvaise habitude ... pratique consciente et délibérée de techniques appropriées. Si vous le faites suffisamment, vous comprendrez la valeur des meilleures pratiques et, grâce à leur utilisation constante, vous développerez de bonnes habitudes.

Sachez également qu'en vous concentrant sur les logiciels fonctionnels, respectant les délais et faciles à gérer, vous obtiendrez la reconnaissance que vous recherchez. Des développeurs expérimentés vous diront: "Ce module que vous avez écrit était bien conçu. Je n'ai eu à implémenter qu'un seul composant pour l'insérer dans mon projet." au lieu de "j'ai dû retravailler tout le module que vous avez écrit pour l'utiliser dans un autre composant? Avez-vous même entendu parler de Bob Martin ou de Ward Cunningham?"

TLDR: Vous n'êtes pas seul. La reconnaissance des compétences est mieux obtenue en tant que sous-produit de la résolution intelligente des problèmes.

Heath Lilley
la source
0

Pour moi, un code trop intelligent cherche souvent à résoudre des exigences imaginaires futures au lieu de se concentrer sur les exigences actuelles. Big trap!

0% de code trop compliqué n'est pas un objectif réalisable. Peut-être même pas le meilleur objectif à atteindre. Un code trop compliqué est mauvais, mais vous devez essayer de nouvelles choses pour évoluer en tant que programmeur. Vous ne devriez pas les essayer sur le code de production si vous pouvez l'éviter. Contrairement aux machines, les humains font des erreurs.

Code aide à l'aide. Passer des années à réparer le code "intelligent" des autres aide. Rester concentré sur ce dont le client a vraiment besoin aujourd'hui aide.

Les écoles et les entreprises ont des équipes de nettoyage et d’entretien. Le code a aussi besoin d'être nettoyé et maintenu! Si possible, nettoyez les dégâts (les vôtres en particulier)! Je pense que c'est le mieux que l'on puisse faire.

GlenPeterson
la source
-2

En plus des bons conseils donnés jusqu'à présent (révision du code, débogage, approche TDD), vous devriez (re) lire de temps en temps les (meilleurs livres à mon humble avis) sur les bonnes pratiques de codage:

  • Programmeur pragmatique
  • Code complet
  • Code propre

et d'autres, en fonction de la technologie que vous utilisez.

m3th0dman
la source
-2

Rappelez-vous juste YAGNI - Vous n'en aurez pas besoin .

Le programmeur ne doit pas ajouter de fonctionnalités avant que cela soit jugé nécessaire

YAGNI est l’un des principes de la pratique XP consistant à "faire ce qui est le plus simple qui puisse fonctionner" (DTSTTCPW). Il est destiné à être utilisé en combinaison avec plusieurs autres pratiques, telles que la refactorisation continue, les tests unitaires automatisés en continu et l'intégration continue. Utilisé sans refactorisation continue, cela pourrait conduire à un code compliqué et à un remaniement massif ...

Selon ceux qui préconisent l’approche YAGNI, la tentation d’écrire du code qui n’est pas nécessaire pour le moment, mais qui pourrait l’être à l’avenir, présente les inconvénients suivants:

  • Le temps consacré à l'ajout, au test ou à l'amélioration des fonctionnalités nécessaires est pris.
  • Les nouvelles fonctionnalités doivent être déboguées, documentées et prises en charge.
  • Toute nouvelle fonctionnalité impose des contraintes sur ce qui peut être fait dans le futur, ainsi une fonctionnalité inutile peut empêcher les fonctionnalités nécessaires d'être ajoutées à l'avenir.
  • Tant que cette fonctionnalité n’est pas réellement utile, il est difficile de définir complètement ce qu’elle doit faire et de la tester. Si la nouvelle fonctionnalité n'est pas correctement définie et testée, elle risque de ne pas fonctionner correctement, même si cela est éventuellement nécessaire.
  • Cela conduit à un gonflement du code; le logiciel devient plus grand et plus compliqué.
  • À moins de spécifications et d'une sorte de contrôle de révision, les programmeurs pourraient ne pas connaître cette fonctionnalité.
  • L'ajout de la nouvelle fonctionnalité peut suggérer d'autres nouvelles fonctionnalités. Si ces nouvelles fonctionnalités sont également implémentées, cela peut entraîner un effet boule de neige vers le fluage des fonctionnalités ...
moucheron
la source
3
Bien que cela puisse être vrai, plus de détails en feraient une bien meilleure réponse.
ChrisF