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

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.

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.

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. ”

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.

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.

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.

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.

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.

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é.

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.

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 :-)

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.

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.

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 ...

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.

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.

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.

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 ...