Comment savez-vous que vous écrivez du bon code?
J'adore la programmation. Je joue avec le code depuis que je suis enfant. Je n'ai jamais opté pour la voie professionnelle, mais j'ai codé plusieurs applications internes pour divers employeurs, y compris un projet dans lequel j'ai été intégré dans lequel j'ai construit un système interne de gestion/reporting des transactions pour une banque. Je saisis rapidement les choses, je comprends beaucoup de concepts et je me sens à l'aise avec l'ensemble du processus de codage.
Cela étant dit, j'ai l'impression de ne jamais savoir si mes programmes sont bons. Bien sûr, ils fonctionnent - mais le code est-il propre, serré et bien écrit, ou un autre codeur le regarderait-il et me giflerait-il dans la tête? Je vois des trucs sur Stack Overflow qui m'époustouflent et font que mes tentatives de codage semblent complètement faibles. Mes employeurs sont satisfaits de ce que j'ai fait, mais sans examen par les pairs, je suis dans le noir sinon.
J'ai examiné la révision de code par les pairs, mais beaucoup de choses ne peuvent pas être publiées en raison de NDAs ou de problèmes de confidentialité. Beaucoup d'entre vous, professionnels, pourraient avoir des coéquipiers pour regarder des choses par-dessus votre épaule ou faire rebondir des idées, mais qu'en est-il des gars indépendants et solo comme moi? Comment apprenez-vous les meilleures pratiques et assurez-vous que votre code est à jour?
Ou n'a-t-il pas d'importance si c'est "le meilleur" tant qu'il fonctionne comme prévu et offre une bonne expérience utilisateur?
Le plus gros indice pour moi est:
Lorsque vous devez revenir en arrière et ajouter/modifier une fonctionnalité, est-ce difficile? Rompez-vous constamment les fonctionnalités existantes lorsque vous effectuez des modifications?
Si la réponse à ce qui précède est "oui", vous avez probablement une mauvaise conception globale.
Il est (pour moi au moins) un peu difficile de juger un design jusqu'à ce qu'il soit nécessaire de répondre au changement (dans la mesure du possible; certains codes sont tout simplement mauvais et vous pouvez le dire tout de suite, mais même cela vient avec l'expérience.)
C'est certainement une mesure assez standard où je travaille.
Quelle porte représente votre code? Quelle porte représente votre équipe ou votre entreprise? Pourquoi sommes-nous dans cette pièce? Est-ce juste une revue de code normale ou avons-nous trouvé un flux d'horribles problèmes peu de temps après la mise en ligne? Sommes-nous en train de déboguer dans une panique, examinant le code que nous pensions fonctionner? Est-ce que les clients partent en masse et les managers respirent dans nos cous ...
(Robert C Martin, Clean Code - livre qui s'ouvre avec l'image ci-dessus)
Vous savez que vous écrivez du bon code lorsque:
- Les choses sont intelligentes, mais pas trop intelligentes
- Les algorithmes sont optimaux, tant en vitesse qu'en lisibilité
- Les classes, les variables et les fonctions sont bien nommées et ont du sens sans avoir à trop réfléchir
- Vous y revenez après un week-end et vous pouvez sauter directement
- Les choses qui seront réutilisées sont réutilisables
- Les tests unitaires sont faciles à écrire
Bien que vous ayez dit que vous n'avez pas d'autres codeurs pour le faire, je vais l'inclure pour le bien des autres.
Le test de qualité du code: Demandez à un autre programmeur qui n'a jamais vu le code de le lire et d'expliquer ce que chaque module vous fait pendant que vous regardez par-dessus son épaule. Plus votre envie de vous lancer et d'expliquer quelque chose est forte, plus le code est probable. Si vous pouvez vous asseoir calmement avec la bouche fermée et qu'ils n'ont pas besoin de poser beaucoup de questions, vous êtes probablement bon.
Pour votre bénéfice, voici quelques directives générales lorsque vous n'avez pas de pair à portée de main. Ce ne sont pas des absolus, juste des "odeurs".
De bons signes
- Les méthodes ont tendance à être très courtes et exécutent idéalement une seule tâche.
- Vous disposez de suffisamment d'informations pour appeler des méthodes SANS regarder leur corps.
- Les tests unitaires sont faciles à écrire.
Mauvais signes
- Méthodes longues composées de 2-3 sous-tâches qui ne sont pas réparties dans d'autres méthodes.
- Les méthodes partagent des données par d'autres moyens que leur interface.
- Si vous modifiez l'implémentation d'une méthode (mais pas l'interface), vous devez modifier l'implémentation d'autres méthodes.
- Beaucoup de commentaires, surtout des commentaires de longue haleine.
- Vous avez du code qui ne s'exécute jamais dans votre application pour fournir une "flexibilité future"
- Grands blocs try/catch
- Vous avez du mal à trouver de bons noms de méthode ou ils contiennent les mots "OU" et "ET" (par exemple GetInvoiceOrCustomer)
- Blocs de code identiques ou presque identiques.
Voici une liste plus longue de le code sent qui devrait également être utile.
Pour moi personnellement, je pense que c'est quand j'oublie le code. En d'autres termes:
- Les bugs se produisent rarement
- Quand ils se produisent, d'autres personnes les résolvent sans me demander quoi que ce soit
- Encore plus important, personne jamais me demande quoi que ce soit concernant mon code
- Les gens n'ont pas un taux élevé de WTF/min en le lisant
- Beaucoup de nouvelles classes du système commencent à utiliser ma classe ( fan-in élevé , comme l'appellerait Steve McConnell)
- Le code est facile à modifier et/ou à refactoriser quand/si nécessaire, sans me maudire (même si c'est moi - me maudire!)
- J'adore aussi quand je suppose que c'est juste la bonne quantité d'abstraction qui semble convenir à tout le monde dans l'équipe
C'est une sensation agréable lorsque vous ouvrez un fichier que vous avez écrit il y a un an et que vous voyez tous les ajouts Nice à une classe, mais très peu modifications , et - fan-in très élevé! :)
Bien sûr, ce sont ces choses qui me font l'impression que j'écris du bon code, mais en réalité, c'est vraiment difficile à savoir. Je suppose que si les gens se moquent de votre code plus qu'ils ne se moquent de vous, il est temps de s'inquiéter.
J'ai trois règles d'or:
- Si je me sens obligé de copier/coller des blocs de code, je fais quelque chose de mal
- Si je ne peux pas prendre tout le code dans ma tête, je fais quelque chose de mal
- Si quelqu'un intervient et se perd dans mon code, je fais quelque chose de mal
Ces règles m'ont guidé pour faire de réelles améliorations architecturales, aboutissant à de petites classes/méthodes propres et maintenables.
C'est une excellente question, et je vous félicite même d'avoir posé la question.
Tout d'abord, il est bon de vous faire exploser l'esprit de temps en temps. Vous garde humble, vous fait réaliser que vous ne savez pas tout, qu'il y a des gens mieux que vous à ce sujet et vous donne quelque chose de mieux à lutter pour.
Maintenant, comment savez-vous quand vous écrivez du bon code?
- Lorsque vos classes ont chacune un seul objectif très clairement défini, séparé des autres classes avec d'autres objectifs clairement définis.
- Lorsque vos méthodes sont courtes - idéalement sous 50 lignes et certainement sous 100 - et leurs noms définissent clairement ce qu'elles font exactement . Une méthode ne doit rien faire d'autre que ce que son nom implique. Si vous dépassez 100 lignes ou si vous êtes très loin, vous pouvez probablement extraire quelque chose dans sa propre fonction.
- Lorsque votre code fournit une façon de faire quelque chose - lorsqu'il ne fournit pas l'option de zig ou de zag, mais fournit à la place un chemin linéaire unique pour chaque ligne de conduite possible, l'utilisateur peut l'envoyer.
- Lorsque vous avez fait tout ce que vous pouvez raisonnablement pour réduire le couplage entre les classes; de sorte que si la classe A dépend de la classe B et que la classe B est supprimée et que la classe C est mise en place, peu ou pas de modifications doivent être apportées à la classe A. La classe A doit être aussi aveugle que possible à ce qui se passe dans le monde extérieur.
- Lorsque vos noms de classe, de méthode et de variable peuvent être lus et immédiatement compris par quiconque rencontre le code - il n'y a pas besoin de 'pktSize' quand 'packetSize' se lit beaucoup plus facilement.
Comme d'autres l'ont dit, essentiellement, si vous faites de la programmation orientée objet, et quand vient le temps de changer quelque chose, vous trouvez que vous essayez de démêler et de rembobiner une pelote de laine, le code ne suit pas les bons principes orientés objet. .
Je recommande fortement le livre "Clean Code", si vous êtes intéressé à creuser un peu plus loin. C'est une bonne lecture pour les novices et les experts.
Je dirais que mes principaux points seraient:
- Lisibilité (pour vous et toute autre personne ayant consulté votre code)
- Maintenabilité (facile à modifier)
- Simplicité (ne complique pas les choses quand cela n'est pas nécessaire)
- Efficacité (bien sûr, votre code devrait s'exécuter rapidement)
- Clarté (si votre code est explicite, il n'y a pas besoin de commentaires la plupart du temps, nommez vos méthodes/propriétés, etc. de manière sensée, cassez le long code bas, ne copiez et collez jamais un bloc de code)
Je ne mets pas Design dans cette liste car je crois qu'un bon code peut être écrit sans coller à un modèle de conception tant qu'il est cohérent dans votre projet .
Bon article MSDN sur ce sujet: Qu'est-ce qui rend bon un bon code?
Cherchez un bon projet open source dans votre langue préférée et voyez ce qu'il fait.
Par exemple, sendmail est un endroit où chercher pour voir si vous écrivez code spaghetti . Ce n'est pas vraiment la faute de sendmail; il n'a que 20 ans, donc il contient beaucoup de cruches. Donc, si votre code ressemble au code sendmail, vous êtes probablement sur la mauvaise voie.
Je n'ai pas regardé Postfix ces derniers temps, cependant, et il est probablement très bien conçu. Donc, si votre contenu ressemble plus à postfix, vous êtes sur la bonne voie.
Quand j'ai commencé à programmer quand j'étais enfant, il n'y avait pas d'Internet et vous n'aviez rien à comparer. Mais maintenant, avec un milliard de lignes de code disponibles pour la comparaison, vous devriez commencer à vous faire une idée si vous le faites correctement ou non.
Et ce n'est pas parce que le noyau Linux est le noyau Linux qu'il est bien écrit. Garde cela à l'esprit.
C'est mon expérience depuis que je suis passé du monde universitaire de la programmation à l'industrie au cours des cinq derniers mois:
- La facilité d'utilisation est si importante que nous payons les gens uniquement pour concevoir des interfaces utilisateur. Les codeurs craignent souvent la conception de l'interface utilisateur.
- Vous trouvez que le faire fonctionner ne suffit pas
- Les optimisations deviennent plus critiques dans les scénarios du monde réel.
- Il y a mille façons d'aborder un problème. Cependant, il arrive souvent que l'approche ne prenne pas en compte des facteurs légèrement moins connus qui pourraient nuire aux performances de votre approche, tels que l'authentification de la base de données, les transactions, le fichier I/O , la réflexion, juste pour nommer un quelques aléatoires.
- La maintenabilité est un aspect très important du codage. Ce n'est pas parce que votre code est super optimisé et super dense ... qu'il est sexy. Parfois, il est simplement étiqueté comme "codage des héros".
- Les compétences en conception sont acquises et non inhérentes. Je suis sûr qu'il y a quelques enfants du cerveau là-bas, mais d'une manière générale, une conception solide en ce qui concerne les problèmes du monde réel, est forgée à travers le temps, l'enquête et, surtout, la transmission des connaissances de vos supérieurs = P
- La documentation n'est pas une commodité, c'est une nécessité.
- La même chose vaut pour tests unitaires (cela varie d'une entreprise à l'autre certes)
Je vous suggère de saisir une opportunité avec un projet open source. Vous aurez la chance de voir ce que vous savez vraiment si vous travaillez aux côtés des autres programmeurs. Un projet open source est probablement le meilleur moyen de le découvrir en fonction de votre expérience.
Lisez un bon code et découvrez pourquoi il est bon. Lisez le mauvais code et découvrez pourquoi il est mauvais. Lisez le code médiocre et déterminez quelles parties sont bonnes, lesquelles sont mauvaises et lesquelles sont correctes. Lisez votre propre code et faites de même. Procurez-vous quelques manuels (réputés) spécifiquement pour examiner les exemples et comprendre pourquoi ils les ont écrits comme ils l'ont fait. Surtout, lisez le code jusqu'à ce que vous puissiez faire la différence entre le bien et le mal, et que vous puissiez faire votre propre "Wtf?" tests.
Vous ne pouvez pas savoir si vous écrivez du bon code tant que vous ne pouvez pas reconnaître le bon code en général. Ce n'est pas parce que quelque chose est au-dessus de votre tête que c'est bien écrit ...
("Lire le code des autres" est apparu dans quelques commentaires sur ce fil, mais je pensais qu'il méritait son propre article)
Du point de vue du code et de la conception, j'aime ce que d'autres ont déjà dit sur la maintenabilité.
De plus, je regarde aussi la stabilité. Regardez les statistiques de support à la production. Si vous obtenez un nombre élevé de correspondances d'assistance pour des choses qui semblent être des fonctionnalités fondamentales, mais que vous constatez que de nombreuses personnes sont incapables de comprendre comment utiliser le logiciel ou trouvent qu'il ne répond pas à leurs besoins, alors il y a un problème.
Bien sûr, certains utilisateurs sont vraiment désemparés, mais si, au fil du temps, vous recevez toujours des rapports de casse, de confusion ou de demandes de changement de fonctionnalités importantes, cela indique que l'une ou l'ensemble des conditions suivantes s'appliquent:
- Les exigences ont été brisées
- Le code est cassé
- L'application n'est pas intuitive
- Le développeur n'a pas compris le besoin de l'utilisateur
- Quelqu'un a poussé la date de livraison plutôt que la qualité
- Quelqu'un n'a pas bien testé ou ne sait pas quoi tester
Demandez à quelqu'un d'autre de reprendre votre travail pendant une journée et vérifiez à quel point il est stressé à la fin de la journée ;-)
Je suis mal à documenter et à nettoyer les trucs - c'est ainsi que je vérifie.
Quand vous pouvez le lire comme de la prose.
Pour un morceau de code particulier:
Si cela fonctionne et est maintenable (choisissez vos bonnes pratiques), c'est du bon code.
Pour vous en tant que développeur au fil du temps:
Bon est un terme relatif et dynamique au domaine linguistique, au domaine problématique, aux tendances actuelles et, surtout, à votre expérience. Le "BON" test d'acide pour ce continuum pourrait simplement être un retour sur votre travail précédent et si vous dites "soupir est-ce que je l'ai vraiment résolu comme ça?" alors il y a des chances que vous continuiez à grandir et que vous continuiez à écrire du bon code.
Si vous regardez en arrière et voyez un code parfait, alors - vous êtes parfait, et il y a un risque que vous stagniez et que vous puissiez bientôt cesser d'écrire du bon code.
Un bon code est subjectif à la personne. Un codeur professionnel qui a lu beaucoup de livres et participé à des séminaires et utilisé différentes techniques de codage déchirerait probablement votre code en lambeaux ... Cependant, j'ai trouvé que le code indique vraiment où se situe le niveau d'expérience des codeurs. Pour moi, cela se lit comme un livre d'histoire ou une auto-biographie. C'est ce que le codeur savait à l'époque ou à quels outils il était limité.
Demandez-vous ceci ... Pourquoi Microsoft utilise-t-il 3 versions de logiciel pour bien faire les choses? Parce qu'ils corrigent constamment les erreurs qu'ils ont faites dans les versions précédentes. Je sais que mon code est de mieux en mieux après une révision. Bien sûr, il y aura des gens ici qui diront, j'écris du code parfait la première fois. Si vous croyez cela, j'ai un terrain marécageux à vous vendre ...
Lorsque vous comprenez les concepts, les choses deviennent plus faciles. Pour moi, le début de l'apprentissage de quelque chose de nouveau est "puis-je le faire fonctionner?", Puis la prochaine étape est "je me demande si je peux le faire de cette façon ...", puis généralement quand je l'ai cloué, je demande "comment puis-je faire plus vite" ...
Si vous voulez être programmeur, vous devez vous y plonger et le faire. Il faut beaucoup de travail et pour être honnête, c'est comme une œuvre d'art qui ne peut jamais être finie. Cependant, si vous voulez être juste un amateur occasionnel, alors si cela fonctionne, ne vous inquiétez pas. Vous devez vous adapter à votre environnement. Si vous n'avez pas de moyen de faire des revues de code, alors l'ignorance est un bonheur =)
Mais peu importe quoi ... Chacun va avoir sa propre opinion. Bien sûr, il y a de bonnes et de mauvaises façons de faire les choses ...
Cela étant dit, j'ai l'impression de ne jamais savoir si mes programmes sont bons. Bien sûr, ils fonctionnent - mais le code est-il propre, serré et bien écrit, ou un autre codeur le regarderait-il et me giflerait-il dans la tête?
Avez-vous considéré demander à un autre codeur ce qu'il pense de votre code?
Certains endroits utilisent la "revue par les pairs" où le code doit être acceptable pour un autre codeur avant d'être accepté dans le référentiel de code.
À mon humble avis, il n'y a pas de "bon code" en soi, mais il y a "un bon logiciel".
Lorsque nous travaillons sur quelque chose, il y a beaucoup de contraintes sur notre travail, ce qui nous obligerait plusieurs fois à produire le code qui sort du "bon code" standard des autres programmeurs.
Certains pourraient dire que le "bon code" est le code facile à entretenir. Le contre-argument pour cette déclaration est pour moi, comment facile? Avons-nous besoin de mettre 200% d'effort sur le morceau de code pour le rendre si facile à entretenir pour le bien du "bon code" standard, même si nous savons que nous n'aurons pas besoin de le maintenir autant? Je suis désolé mais je ne pense pas.
En fait, je suis celui qui promeut vraiment le "bon code" dans mon équipe et que personne ne s'en soucie vraiment. Chaque fois que je regarde leurs codes, je n'ai jamais trouvé qu'ils écrivent un code parfait. Cependant, je dois accepter qu'ils ont vraiment fait le travail et être en mesure de le maintenir adéquatement pour les besoins de notre entreprise. Bien sûr, l'application est parfois boguée, mais nous venons de le faire à temps, ce qui rend nos clients et utilisateurs heureux et sécurise notre entreprise dans une position très en avance sur nos concurrents.
Donc, je dirais que "bon code" est le code qui produit ce dont vous avez besoin. Il vous suffit de penser à ce dont vous avez vraiment besoin, puis de l'utiliser pour évaluer votre code.
Jamais.
"Bon code" n'est que du code pour lequel aucun moyen d'amélioration n'a encore été trouvé. Comme Jeff Atwood a dit :
Il existe une poignée de programmeurs dans le monde capables de produire du code brillant et parfait. Tout ce que nous pouvons faire, c'est continuer à rendre notre logiciel moins merdique au fil du temps - un processus d'amélioration continue
Et en passant, vous n'avez pas à atteindre la perfection, car parfois, " n design suffisant signifie un mauvais design ".
Rien ne vaut le fait que quelqu'un expérimenté regarde votre code, mais il existe des ressources pour vous aider à évaluer et à améliorer votre code par vous-même. Jetez un oeil à Martin Fowler Refactoring (ou site Web ). Sutter et Alexandrescu C++ Coding Standards est bon si vous écrivez en C++. Beaucoup de recommandations y sont indépendantes de la langue, mais d'autres peuvent recommander des livres similaires pour d'autres langues. Le développement piloté par les tests peut être très utile pour les développeurs solo, car il fournit une sorte de contrôle de qualité au fur et à mesure, et vous savez quand les tests deviennent difficiles à écrire que cela signifie que votre code pourrait probablement utiliser la restructuration.
Certains autres signes sont davantage orientés processus. Ils conduisent généralement à un meilleur code, mais pas directement. Cela inclut des choses comme l'utilisation du contrôle de code source, un processus de construction automatisé, le fait de ne pas se développer directement sur le serveur en direct, l'utilisation d'un logiciel de suivi des bogues, etc.
Dans le but de bien coder, je vise à assurer que le programme est très fonctionnel et rapide à ce sujet. Assurez-vous que tout est à sa place pour que le fichier, les données, la fonction et les abstractions soient assez évidents.
Après ce point, je l'ai mis à l'épreuve: trouvez une personne assez peu familiarisée avec les ordinateurs en général, essayez d'expliquer une partie du modèle de code principal. S'ils peuvent en quelque sorte le lire, wow. Bon travail.
Surtout juste EMBRASSE et essayez d'être innovant sans planter quoi que ce soit. Je voudrais également prendre plus de notes sur le retour au code et le bon moment pour l'améliorer et le maintenir, mais cela a été assez bien couvert.
Libérez votre code, laissez certaines personnes le jouer pour vous assurer qu'il fait ce qu'il est toujours censé faire. Ou si vous le souhaitez, concevez une spécification et assurez-vous qu'elle répond à toutes ces spécifications. Si vous réussissez l'un de ces tests ou les deux, votre code est "bon pour le moment". Pour la plupart des gens, votre code ne sera jamais génial, car vous reviendrez dans un an et direz "Pourquoi ai-je fait que alors qu'il aurait fonctionné tellement mieux ceci façon? "
Avec plus d'expérience, vous obtenez un meilleur code. Mais si vous pratiquez continuellement les mêmes habitudes, vous tomberez continuellement dans les mêmes pièges. C'est juste une simple prise sur un vieil adage de "La pratique fait permanent." Si vous faites continuellement les choses de la bonne façon (comme tester votre code pour vous assurer qu'il fonctionne toujours pour ce qu'il est censé faire), alors vous irez mieux. Si vous faites continuellement les choses de la mauvaise façon (comme ne jamais tester votre code pour certaines situations, ou ne pas reconnaître où des bogues peuvent se produire), vous serez juste têtu avec votre code.