Comment vous entraîner pour éviter d'écrire du code «intelligent»?
Savez-vous ce sentiment lorsque vous venez besoin de montrer cette nouvelle astuce avec Expressions ou de généraliser trois procédures différentes? Cela ne doit pas nécessairement être à l'échelle Astronaut Architecture et en fait peut être utile, mais je ne peux pas m'empêcher de remarquer que quelqu'un d'autre 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 conçois souvent des programmes en 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'à ce que je vois des preuves du contraire, mais il est généralement trop tard. Il y a aussi une partie de moi qui préfère des hypothèses non documentées pour la duplication de code et l'intelligence de la simplicité.
Que puis-je faire pour résister à l'envie d'écrire du code "intelligent" et quand la cloche devrait-elle sonner ? Le faire mal ?
Le problème devient encore plus poussé car je travaille maintenant avec une équipe de développeurs expérimentés, et parfois mes tentatives d'écriture de code intelligent me semblent stupides même après que le temps dissipe l'illusion de l'élégance.
Le problème devient encore plus poussé car je travaille maintenant avec une équipe de développeurs expérimentés, et parfois mes tentatives d'écriture de code intelligent me semblent stupides même après que le temps dissipe l'illusion de l'élégance.
Votre solution se trouve ici. Je suppose 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 - en supposant que votre ego peut prendre le coup. (Des choses ennuyeuses, egos. Dommage que nous en ayons besoin.)
Avez-vous des revues 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é en vous-même une tendance à la conception excessive, à utiliser un marteau-piqueur pneumatique haut de gamme méticuleusement conçu (de préférence manié par une sorte d'Android automatisé) .
Vous pouvez souvent vous retrouver à vous tortiller sur votre siège pendant que votre visage devient rouge pendant les révisions du code. Endure-le. Vous apprenez.
Ensuite, une fois que vous en avez quelques-uns sous votre ceinture, faites attention aux moments où vous pensez que vous êtes peut-être en train de trop concevoir. Lorsque ces moments arrivent, demandez-vous: "Si quelqu'un m'appelle à ce sujet lors de la révision du code, puis-je défendre ma solution comme la meilleure disponible? Ou existe-t-il une solution plus simple que j'abandonne?"
Parfois, l'examen par les pairs est le meilleur moyen d'avoir un bon aperçu de 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 en premier lieu. Par conséquent, si vous écrivez le code aussi intelligemment que possible, vous n'êtes, par définition, pas assez intelligent pour le déboguer. "
Il existe généralement au moins trois solutions aux problèmes logiciels de toute importance: la voie évidente, une voie complexe non évidente (intelligente) et une voie simple non évidente (élégante). Une citation sur les auteurs est applicable ici:
Mettez de côté tout ce qui vous vient à l'esprit et alors vous êtes écrivain. Mais un auteur est celui qui peut juger de la valeur de ses propres trucs, sans pitié, et en détruire la plupart. - Colette
Vous ne pourrez pas écrire de code élégant tant que vous ne pourrez pas juger de la valeur de votre propre code, sans pitié, et en détruire la majeure partie. Si vous jugez le code élégant par le résultat final, cela semble trompeusement facile, mais cela nécessite de ralentir, de passer en revue de nombreux brouillons, de demander l'avis des autres et d'exciser ce qui ne se trouve pas directement sur la page. Cela signifie que même si votre code fonctionne parfaitement, vous vous demandez à vous-même ou à un collègue pourquoi quelque chose ne va pas, jusqu'à ce que vous soyez satisfait de la réponse. Peut-être que cela semble trop long ou répétitif, ou que vous pensez que le compilateur aurait dû être capable d'attraper un certain type de bogue. La plupart des programmeurs ayant un minimum d'expérience peuvent reconnaître du code inélégant facilement. L'astuce consiste à comprendre pourquoi.
C'est la façon méthodique d'écrire du code plus élégant. Il nécessite également fréquemment un éclair de perspicacité qui vous aide à regarder un problème d'une nouvelle manière. C'est plus difficile à atteindre, mais cela aide à ralentir et à penser à un problème avant de plonger dans le codage. Lorsque vous trouvez une bonne solution, cherchez-en une meilleure. La lecture d'un autre code aide. Prendre des cours ou lire des livres sur les meilleures pratiques aide. L'apprentissage d'autres paradigmes de programmation aide. Demander conseil à des collègues dont vous admirez le code vous aide.
Je voudrais ajouter aux réponses existantes, développer de manière TDD, donc vous écrivez d'abord des tests sur ce que votre code devrait faire, puis implémentez pour que vos tests deviennent verts. De cette façon, vous ne remplissez que les exigences imposées par les tests. Puisque vous allez écrire le test, c'est un bon moyen d'adopter une approche auto-disciplinée du développement.
Lorsque vous travaillez pour une équipe importante et dynamique qui s'étend sur de nombreuses compétences et années différentes, le développement a une progression naturelle pour être "abaissé" jusqu'au niveau le plus bas du membre de l'équipe le plus conservateur ou le plus intellectuellement déficient, actuel ou historique.
Ce n'est pas nécessairement une mauvaise chose, car le code intelligent peut être plus difficile à déboguer, plus difficile à transmettre dans une spécification technique et plus long à écrire, ce qui ralentit le temps de développement.
Il y a des moments où le code intelligent est important, comme lorsque le code intelligent donne des gains d'efficacité et de performances plus tard dans le cycle de maturité du logiciel lorsque les performances deviennent une exigence.
Le code intelligent a également un moyen de transmettre un code plus rapide à développer et plus lisible et compréhensible à une équipe qui peut ne pas être exposée à une nouvelle fonctionnalité de langage ou à un appel de bibliothèque. Par exemple, lorsque j'ai été initié à Linq par un développeur junior, j'ai eu un dégoût immédiat car inutile, difficile à déboguer, stupide et "intelligent". Après avoir joué avec moi-même et découvert à quel point les requêtes Linq peuvent être utiles et puissantes, j'ai investi du temps pour l'apprendre et mon code DAL n'a jamais été aussi propre et lisible, ainsi que plus facile à déboguer et à étendre.
Je regrette de ne pas avoir l'esprit ouvert auparavant et j'aurais aimé ne pas avoir été aussi sévère avec un développeur junior aussi "intelligent".
Mon point est que le code "intelligent" DEVRAIT être suspect, mais nous ne devons pas nous lancer en croisade contre lui car il pourrait étouffer la créativité et l'innovation.
EDIT: Je viens de réaliser que je n'ai pas entièrement répondu à votre question. Si vous avez la capacité dans votre projet d'écrire très facilement du code intelligent, alors l'équipe devrait peut-être adopter des normes de codage plus strictes pour suivre un modèle et un style uniformes et distincts. Cela vous aidera à tracer les lignes de votre bac à sable afin de ne pas vous promener dans la rue à la poursuite d'une balle.
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 repenser .
Je pense vraiment que vous devriez vous efforcer d'être intelligent, c'est un effet secondaire naturel de devenir plus compétent. Se donner une ligne directrice générale comme le% de commentaires nécessaires pour être clair est un bon moyen de se forcer à prendre du recul et à évaluer si l'utilisation de cette nouvelle chose que vous avez apprise est un choix judicieux ou juste 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, à mon rythme, à la maison.
Lorsque la nouveauté disparaît - le problème est résolu.
Je crois 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 donner une impression 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 fait la fonction (après lui avoir donné un bref contexte)? Sinon, combien d'explications devrais-je faire? Comment expliquer cela à quelqu'un qui prend du 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 des constructions de langage (LINQ par exemple) à quelqu'un qui ne le connaît pas, 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 refactorisé.
Connaissez-vous ce sentiment lorsque vous avez juste besoin de montrer ce nouveau truc 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 lorsque les nouveaux développeurs sont jetés dans un gros désordre de code speghetti non documenté à maintenir et à refactoriser. Cela leur apprendra les réalités du maintien d'un code trop `` intelligent '' qu'ils n'ont pas écrit et, espérons-le, insufflera de l'empathie pour le pauvre schmuck qui devra déboguer son code dans 5 ans.
Je pense que le sujet est bien choisi. C'est "cool" d'écrire une ligne de Perl qui fait dix mille choses à la fois, mais ça craint quand vous devez la revisiter.
Sur une note différente, intelligente ou non, le code doit être documenté. Il existe un décalage d'impédance inhérent entre les langages de programmation acceptés par l'industrie et les concepts de haut niveau auxquels nous, les humains, sommes habitués dans notre réflexion. Le code d'auto-documentation n'est tout simplement pas réalisable - jusqu'à ce qu'il devienne un langage naturel, bien sûr. Même le code Prolog doit être documenté, car, quel que soit son niveau, il est encore assez formel.
Le code impératif à grain fin sert à mettre en œuvre des plans à grain grossier - qui doivent être documentés. Je ne veux pas avoir à lire les 50 lignes de la méthode lorsqu'un commentaire rapide de la feuille de route de 3 lignes fera l'affaire.
É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 faire beaucoup pour l'auto-documentation, mais il ne peut pas vous donner tous les niveaux d'abstraction.
Et les commentaires peuvent également agir comme des sidenotes dans un livre, lorsque nous devons expliquer le raisonnement derrière une revendication dans le texte principal sans la faire dérailler.
Dans ce contexte, je trouve 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 à de la documentation, pour expliquer de manière clairsemée l'abstraction incarnée dans le texte, ou pour fournir des détours sans faire dérailler le texte principal. Avec la note que le code bien abstrait peut déjà avoir fait un long chemin vers l'auto-documentation.
Enfin, les commentaires peuvent aider le codeur à maintenir un niveau d'abstraction élevé. Souvent, je me rends compte que deux commentaires consécutifs que j'ai inclus dans une liste d'étapes ne parlent pas au 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 affectent le codage tout comme d'autres activités. Les commentaires peuvent aider à clarifier la raison d'être et les facettes de notre code, et je les trouve un compagnon agréable qui parle un langage plus doux au profit de la personne pour un changement.
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 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 quelle autre langue.
Il y a frameworks d'injection de dépendances open source pour travailler sur lesquels il suffit de demander Expression des connaissances sur les astuces, il y a F # et une merveilleuse gamme de tâches que l'on peut vouloir essayer pour.
Si vous êtes dans les mathématiques (et c'est indépendant du langage ), il y a Project Euler pour vous.
Dernier point, mais non le moindre, dans le monde .NET, il y a Mono Project qui a beaucoup de domaines qui nécessitent l'attention des développeurs , certains d'entre eux assez compliqués. Que diriez-vous de contribuer à un outil d'analyse de code .NET statique open source ? Il y a une analyse IL impliquée, ainsi que des trucs de haut niveau. Jb Evain fonctionne toujours sur quelque chose d'intéressant, que ce soit la bibliothèque de réflexion Cecil, le support Expression ou un décompilateur .NET.
Si rien ne convient, juste lancez votre propre framework de moquerie :-)
1) Se brûler avant pour savoir que c'est une mauvaise chose. Tenter de déboguer quelque chose d'il y a longtemps qui a été intelligemment écrit est très amusant. Je pense que vous avez couvert cela.
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 pouvez 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 semble le moins déroutant, je décris également 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 réessayer.
Comment? Continuez à montrer votre code à ces développeurs expérimentés. et quand on vous reproche d'être sophomorique et voyante, aspirez-la, 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 plusieurs lunes, j'étais dans la même situation - j'avais un patron qui grincait des dents à chaque fois que j'utilisais un pointeur dans Delphi ou le 'with construct', un autre qui menaçait de me virer si je n'arrêtais pas de court-circuiter tous mes booléens avec 0-1 et en utilisant des variables à lettre unique partout.
J'ai appris parce que j'ai demandé pourquoi et ils ont pris la peine de l'expliquer parce qu'ils pensaient que je pourrais représenter quelque chose - LOL ....
Est-ce que je ressens le besoin de me montrer? Non, plus maintenant. Comment l'ai-je dépassé? Comme la plupart des gens ont dépassé toute autre mauvaise habitude ... la pratique consciente et délibérée des techniques appropriées. 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, c'est-à-dire à temps et facilement entretenus, vous obtiendrez la reconnaissance que vous recherchez. Des développeurs expérimentés viendront vers vous et vous diront: "L'homme que le module que vous avez écrit était bien conçu. Je n'avais qu'à implémenter un composant pour le brancher à mon projet. par opposition à "J'ai dû retravailler tout le module que vous avez écrit juste pour l'utiliser dans un autre composant? Avez-vous même entendu parler de Bob Martin ou Ward Cunningham?"
TLDR: Vous n'êtes pas seul. La reconnaissance des compétences est mieux réalisée en tant que sous-produit de la résolution intelligente des problèmes.
Pour moi, un code trop intelligent s'efforce souvent de résoudre les besoins futurs imaginaires au lieu de se concentrer sur les besoins d'aujourd'hui. Gros piège!
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.
Aide sur les révisions de code. Passer des années à corriger le code "intelligent" des autres aide. Rester concentré sur ce dont le client a vraiment besoin aujourd'hui aide.
Les écoles et les entreprises disposent d'équipes de personnel de nettoyage et d'entretien. Le code doit également être nettoyé et entretenu! Lorsque cela est possible, nettoyez les dégâts (les vôtres en particulier)! Je pense que c'est le mieux qu'on puisse faire.