Travailler en tant que développeur unique: faire examiner le code


39

Je n'ai d' autre choix que de travailler seul et je ne trouve pas de solution adéquate pour faire réviser mon travail, vérifier son état d'esprit, avoir quelqu'un avec qui échanger des idées, discuter des meilleures pratiques, etc.

Je pensais avoir une réponse via l'article de Jeff Atwood: Dans Programming, One Is The Loneliest Number , le meilleur que j'ai pu trouver sur le sujet, mais il s'est avéré que je voulais simplement réitérer ma question.

Je connais des sites Stack Exchange tels que celui-ci, et Code Review sont une réponse potentielle évidente, mais comme beaucoup l'apprécieraient, c'est loin d'être idéal:

Bien que je ne puisse pas énumérer tous les pièges, souvent, formuler une question et la transformer en un problème à part entière prend souvent tellement de travail que, au moment où vous l'avez suffisamment préparée, vous avez répondu à votre propre question plus en détail le temps qu'il aurait fallu autrement. En outre, le fait de cacher des détails pour poser une question bien définie élimine la possibilité que quelqu'un repère des problèmes auxquels vous n'aviez pas pensé. En outre, bien que je ne puisse pas tout à fait mettre le doigt dessus, la réactivité d'une conversation libre ne peut être égalée par aucune forme de discussion textuelle sur Internet à laquelle je peux penser. Dernier point mais non le moindre, je ne veux pas publier tout mon projet pour que le monde entier le regarde pour le reste de l'éternité, pour des raisons évidentes.

Y at-il des réponses autres que de payer un consultant pour examiner mon code?


3
J'ai aussi ce problème (avec des projets amusants, cependant), seulement je suis assez chanceux pour avoir quelques amis programmeurs proches prêts à parcourir mon code.
Austin Hyde

23
Vous pouvez toujours vous parler à vous-même - c'est particulièrement utile pour les contrôles d'aliénation mentale :-)
Danny Varod le

4
Si vous pouvez vous le permettre, c’est l’une des raisons pour lesquelles il est bon de louer un bureau dans un parc d’affaires (idéalement là où se regroupent les informaticiens). J'ai eu beaucoup de bonnes conversations avec les informaticiens de mes bureaux voisins lorsque j'étais programmeur isolé et que je travaillais dans un bureau.
JW01

6
Travailler seul peut être mieux que de travailler avec des idiots.
Job

2
Ce n'est pas vraiment une solution, mais vous pouvez passer du temps sur SO Chat ou sur un canal IRC approprié. cela pourrait alléger le fardeau de travailler seul.
Tikhon Jelvis

Réponses:


36

J'ai été à votre place et je ne pense pas qu'il existe une solution facile. Payer un consultant pour examiner votre code n'est pas un bon moyen de dépenser de l'argent. Si votre problème est que vous vous sentez seul et que vous n'avez personne à qui parler de la programmation, je ne peux pas vous aider là-bas, mais si vous souhaitez vraiment améliorer la qualité de votre code, la meilleure chose à faire est de la définir. de côté et y revenir dans environ une semaine. Si le code est vraiment mauvais, cela deviendra évident car vous ne pourrez pas le comprendre et vous pourrez le refactoriser pour le rendre plus clair. Après quelques itérations de ce processus, vous remarquerez les modèles de code qui facilitent la compréhension du code et améliorent sa qualité.


Bon un! ... 15
Marjan Venema

2
En théorie, cela pourrait fonctionner. En pratique, il n'y a pas de chemin à parcourir pour revenir au code qu'il a écrit il y a deux semaines, si cela fonctionne. Il ne devrait pas non plus, probablement. Si cela fonctionne, y passer du temps dans le seul but de le rendre "plus joli" est une perte de temps, cela devrait être fait quand et si on le touche à nouveau.
Thomas Bonini

3
@Krelp: Je regarde le code passé tout le temps et il n'y a aucun moyen d'ajouter des fonctionnalités et de maintenir en général un logiciel sans regarder le code écrit précédemment. Il n’existe pas d’architecture parfaite et les abstractions qui fuient sont la règle plutôt que l’exception. Il est donc inévitable de regarder du code écrit précédemment. Je sais que les codeurs marathon sont idolâtres dans les cercles de programmation, mais le codage marathon conduit rapidement à l'épuisement professionnel et aux projets abandonnés. Par conséquent, améliorer la qualité du code en prenant des pauses et en revenant me maintient également sain d'esprit.
davidk01

@david: vous avez mentionné que vous remontez dans le code après un laps de temps déterminé, même si vous n'en avez pas besoin pour le moment. Au départ, vous n'avez pas dit de regarder le code seulement quand vous devez le faire pour ajouter de nouvelles fonctionnalités. Donc, si - selon ce que vous avez dit - vous devez éventuellement regarder tous les anciens codes, pourquoi ne pas le faire Donc, dans un moment qui est pertinent au lieu d’après une période de temps déterminée?
Thomas Bonini

3
@Krelp: Si vous êtes assez confiant dans vos compétences, allez-y et regardez seulement le code qui fonctionne, mais si vous débutez et que vous ne savez pas à quel point vous structurez votre code, cherchez-le continuellement De retour à ce que vous avez écrit il y a quelques semaines, le refactoriser est un très bon moyen d'apprendre la structure de code appropriée. Mon conseil était destiné aux personnes cherchant à améliorer et à atteindre le point où la restructuration du code précédemment écrit devient de moins en moins nécessaire car la version initiale a la structure extensible appropriée. Vous êtes plus que bienvenu pour ignorer mon conseil.
davidk01

17

Y at-il des réponses autres que de payer un consultant pour examiner mon code?

Non.

Mon conseil est de rejoindre un groupe de développeurs / utilisateurs locaux et d'exprimer vos idées avec d'autres. Parlez de votre conception. Demandez aux autres comment ils ont abordé certains problèmes.

S'ils vérifient votre conception, même sans regarder votre code, cela devrait suffire.


4
Beaucoup d'écrivains professionnels le font.
JeffO

10

Il existe des techniques d'auto-vérification, telles que le développement piloté par les tests, qui peuvent aider à fournir des commentaires. Lorsque cela devient difficile, vous savez que votre architecture est probablement complètement déséquilibrée.

formuler une question et en faire un problème autonome demande souvent tant de travail qu'au moment où vous l'avez suffisamment préparée, vous avez répondu à votre propre question plus longtemps qu'il n'aurait fallu autrement.

Problème résolu. Vous n'avez pas besoin de commentaires externes sur chaque ligne de code pour pouvoir vous améliorer, mais d'un bon échantillonnage aux emplacements clés de la route et d'auto-contrôles minutieux aux points intermédiaires.

Vous devez surmonter l’idée que vous pouvez maintenir le même niveau de qualité en travaillant seul et dans le même temps qu’une personne travaillant en équipe. Il y a une raison pour laquelle les gens travaillent en équipe. La bonne nouvelle est que vous n'avez pas de conflits de décisions de conception. La mauvaise nouvelle est que vous n’avez pas de conflit à propos des décisions de conception. J'espère que le temps supplémentaire que vous passez à maintenir la qualité est quelque peu compensé par les avantages de travailler seul.


Je ne vois pas comment TDD est une réponse ici.
Aaronaught

1
@Aaronaught Je suis dans le même bateau que le TS et je peux vous assurer que l'écriture de tests (que ce soit avant le code comme dans TDD ou après) est LE moyen de vérifier si votre code est sain d'esprit. Si vous ne pouvez pas le tester, c'est mauvais.
stijn

1
@stijn: Il est peut-être (un peu) vrai que le code incorrect est plus difficile à écrire pour les tests, mais ce n'est jamais impossible - c'est la façon dont les systèmes hérités sont mis à niveau. Même si nous avons accepté à première vue l'affirmation douteuse selon laquelle un code correct conduit à de bons tests, la prétention inverse n'est toujours pas prouvée; un test réussi ne signifie pas que le code est de qualité raisonnable. En fait, le principe de TDD - "red, green, refactor" - signifie essentiellement écrire un code peu satisfaisant qui passe le test , puis le refactoriser pour améliorer la qualité. juste avec des tests.
Aaronaught

2
@Aaronaught: vous faites valoir des arguments valables, mais je maintiens toujours mon argument, à savoir que les tests sont un très très bon moyen de vérifier la santé du code (bien que ce ne soit pas le seul moyen); L’expérience m’a prouvé que c’est particulièrement utile de voir où le PÉR est violé lourdement.
stijn

@Mark: C'est bien, mais toutes ces anecdotes valent encore moins qu'une réclamation publicitaire "J'ai perdu 50 kilos en 2 semaines", parce que la chose dont on parle n'a même pas été mesurée , encore moins observée dans des conditions contrôlées. Oui, il existe des preuves que TDD réduit les défauts avant la publication, et c'est une bonne chose. les revues de code résolvent un problème entièrement différent et il n'y a aucune base pour supposer que TDD résout le même. Les tests unitaires "à la vieille école" sont probablement meilleurs, car ils imposent des contraintes de testabilité à des classes individuelles plutôt qu'à des groupes.
Aaronaught

6

Je recommanderais de créer autant de réseaux que possible lors de conférences et de groupes d'utilisateurs locaux. Je connais beaucoup de développeurs qui tirent des fragments de code désinfectés par courrier électronique ou par im tout le temps, simplement pour rester précis et examiner les algorithmes ensemble. Non, ce n'est pas une conversation face à face, et oui, il est parfois pénible d'assainir le code, mais une révision de 20 codes de messagerie instantanée peut parfois être très utile, en particulier lorsque vous avez désespérément besoin d'une deuxième paire d'yeux.


4

Je suis dans une situation similaire et je compte énormément sur Stack Overflow pour obtenir des commentaires sur des questions épineuses. Je trouve aussi, en raison de la nécessité de rédiger une description du problème, que la réponse devient souvent évidente. En ce qui concerne les meilleures pratiques, je suis un développeur .Net et j'utilise ReSharper, qui offre des suggestions de bonnes pratiques pour remplacer le code que j'écris (ce que j'ignore parfois - cela peut être un peu pédant). Un autre outil utile est FxCop, qui effectue une analyse de code statique et met en évidence les problèmes qui ne correspondent pas à son ensemble de règles.

Sinon, c’est à vous de lire et de vous tenir au courant des pratiques actuelles. J'aime Morning Dew d’ Alvin Ashcraft pour ses liens vers ce qui est nouveau et amélioré dans le monde .Net.


4

Je suggérerais d'essayer de créer (ou de trouver) un petit groupe d'utilisateurs. Assurez-vous que votre code est disponible et que tout le monde s'engage à le faire fonctionner - une demi-heure ou plus par jour.


3

D' après mon expérience, il serait très important, bien que non obligatoire, qu'un développeur expérimenté examine votre code pour jeter les bases de votre développement . Une fois que vous êtes expérimenté, vous pouvez suivre l’approche suggérée par @ davidk01, c’est-à-dire revoir votre propre code périodiquement pour en améliorer la qualité.


2

Je ne connais pas les détails de votre situation, mais là où je suis maintenant, nombreux sont ceux qui ont soif d'expérience et d'étudiants d'expérience qui sont plus qu'heureux de travailler comme stagiaire et d'apprendre quelque chose.

Cela peut sembler être un travail supplémentaire pour vous de les manipuler et de leur apprendre ceci et cela, mais nous étions tous là quand nous avons commencé et je suppose que c'est à notre tour de rembourser.

Ils ne sont pas des experts et peuvent même parfois vous induire en erreur, mais ils défient généralement tout, ils regorgent d’idées et sont parfaits pour une discussion dans le cadre de laquelle vous devez défendre chaque détail de votre code.


2

Bien que je ne puisse pas énumérer tous les pièges, souvent, formuler une question et la transformer en un problème à part entière prend souvent tellement de travail que, au moment où vous l'avez suffisamment préparée, vous avez répondu à votre propre question plus en détail le temps qu'il aurait fallu autrement.

Je ressens la même chose pour plus de 75% des questions que je poste.

Cependant, ce n'est pas un argument pour ne pas prendre la peine de le faire. C'est effectivement un débogage de canard en caoutchouc. Vous trouvez des réponses aux questions qui, selon vous , pourraient surgir en réponse à votre question; ce qui signifie que vous envisagez le problème du point de vue de différentes personnes; ce qui signifie que vous pensez au problème dans toutes les directions possibles; qui est la meilleure façon de trouver la faille.

Au mieux, vous avez prouvé de façon concluante que vous ne pouvez clairement pas trouver la réponse ici. Au "pire", vous finissez par répondre à votre propre question. Faites attention aux citations, car ce n'est pas mal du tout. C'était peut-être un peu inefficace, mais résoudre le problème lentement est mieux que de décider rapidement de ne pas s'attaquer au problème . Vous aurez plus vite à résoudre le problème éventuellement.

Exemple:

Quand j'étais un développeur débutant, j'ai traité de nombreuses fois avec la page ASP.Net eror . J'avais besoin de Google le message pour comprendre ce qui ne va pas. Cela pourrait prendre plusieurs heures avant que je trouve la bonne solution. En gros, j'ai commis chaque erreur dans le livre et j'ai ensuite dû gérer les conséquences de devoir déboguer les problèmes.

Maintenant, quand une erreur survient, je connais déjà les "suspects habituels" de ce qui pourrait causer le problème. Ma liste mentale de "suspects habituels" est effectivement basée sur les problèmes avec lesquels j'ai le plus de problèmes au cours de ma carrière. Sans avoir au préalable effectué le travail fastidieux sur les jambes de Google, je n'aurais jamais fait cette liste mentale . Mais maintenant que j'ai cette liste mentale, le dépannage est beaucoup plus rapide.


En outre, bien que je ne puisse pas tout à fait mettre le doigt dessus, la réactivité d'une conversation libre ne peut être égalée par aucune forme de discussion textuelle sur Internet à laquelle je peux penser.

Je suis un peu en désaccord ici. Vous avez raison, la communication Internet est moins sensible, mais vous avez tort (à mon avis) de penser que cela est mauvais pour vous.

En tant que développeur isolé, vous dépendez du débogage du canard en caoutchouc. L'ingrédient clé pour faire fonctionner le RDD est que vous anticipez les questions que le canard en caoutchouc peut avoir pour vous. Vous ne pouvez évidemment pas vous fier à ce que dit le canard en caoutchouc.

Lorsque vous traitez avec des systèmes de messagerie lents (publication sur StackOverflow ou communication en écrivant des lettres), vous êtes intrinsèquement incité à vous assurer de bien faire les choses dès la première fois. Parce que le besoin de corriger une erreur sera un processus lent et ardu.
En comparaison, considérons que les systèmes de messagerie rapide (conversation, messagerie instantanée) permettent de corriger immédiatement quelque chose. La capacité de corriger rapidement quelque chose rend les gens moins incités à s'assurer que c'est correct.

Quatre cas d'espèce:

  • Lorsque je fais ma propre analyse / liste de tâches en tant que développeur, j'utilise toujours un crayon et du papier. J'ai remarqué que je dissimule les hypothèses et les mensonges lorsque je tape mes notes, parce que mon esprit pense que «je peux facilement résoudre ce problème plus tard». Cependant, avoir à corriger quelque chose que vous avez écrit sur du papier est ennuyeux, vous devez rayer des choses et écrire entre les lignes et le document paraît tellement pire quand il porte des gribouillis. Ecrire sur papier me fait vérifier les faits avant de m'engager à l'écrire. Cela attrape beaucoup de malentendus tôt, avant même d’écrire du code qui produirait des bugs.
  • Ma grand-mère était secrétaire (âge de la machine à écrire). Faire une faute de frappe dans un document officiel signifiait avoir à taper à nouveau la page entière. Ma tante est secrétaire (âge du traitement de texte). Elle peut compter sur un correcteur orthographique automatique et les erreurs peuvent être corrigées facilement et avec un minimum d'effort. Sans surprise, ma grand-mère fait beaucoup moins de fautes de frappe et de fautes d'orthographe que ma tante.
  • Auparavant, les jeux vidéo étaient imprimés sur des cartouches. Corriger un bogue après la publication était presque impossible. Vous devez réimprimer toutes les cartouches, les distribuer à tous les fournisseurs et espérer que ceux-ci pourront en quelque sorte entrer en contact avec les clients qui ont déjà acheté le jeu. Cela coûterait des tonnes d'argent (le double du coût de production physique) et n'atteindrait toujours pas certains clients. Aujourd'hui, à l'ère des correctifs Internet, les développeurs de jeux ont montré qu'ils investissaient beaucoup moins dans le test de leurs jeux afin d'éviter les bogues de publication, car il est beaucoup plus facile de simplement appliquer directement un correctif à chaque client. L'impact d'une erreur est minimisé à un point tel qu'il est préférable de régler quelques problèmes après coup, plutôt que d'avoir à tester tous les problèmes possibles. les erreurs qui pourraient survenir.
  • J'habitais dans un appartement au troisième étage, sans ascenseur, et je devais souvent garer une ou deux rues de mon immeuble. Je n'ai presque jamais oublié de prendre quelque chose dans ma voiture. Maintenant, je vis dans une maison avec ma voiture juste à côté de moi dans l'allée. J'oublie de prendre des choses dans ma voiture tout le temps .

L'idée sous-jacente est qu'un système d'échange difficile incite les gens à effectuer des échanges corrects et vérifiés . La sévérité de la peine (= processus de correction difficile) vous apprend à ne pas commettre d'erreur.


En outre, le fait de cacher des détails pour poser une question bien définie élimine la possibilité que quelqu'un repère des problèmes auxquels vous n'aviez pas pensé.

Lorsque vous créez un MCVE , vous ne devez pas simplement le créer et le poster dans la question. Vous devez d'abord le faire vous - même , afin de pouvoir isoler le problème. Et puis, quand vous pensez que le problème ne peut plus être réduit, et que vous n'en voyez toujours pas la cause; alors vous avez une question valide pour StackOverflow.

Exemple:

J'ai toujours un deuxième Visual Studio en cours d'exécution avec une application de console simple appelée Sandbox. Chaque fois que je rencontre un problème technique, je copie le code incriminé dans le bac à sable et commence à jouer avec.

  • Que se passe-t-il quand je change ce réglage?
  • Puis-je reproduire le problème si je raccourcis le code?
  • Quels paramètres permettent / impossible de reproduire le problème?

Dans 90% des cas, je trouve la cause du problème parce que le bac à sable m'a aidé à examiner le code incriminé sans être distrait par le contexte (ou par exemple toute incertitude sur les valeurs associées à différentes parties du code).

Dans les 10% restants, il me reste un code minimal pour reproduire le problème, qui constitue un exemple parfait d'extrait de code à publier sur StackOverflow.


Dernier point mais non le moindre, je ne veux pas publier tout mon projet pour que le monde entier le regarde pour le reste de l'éternité, pour des raisons évidentes.

Lorsque vous avez déjà votre MCVE, vous ne devriez pas avoir trop d’informations personnelles (ou d’entreprise). Si vous le faites, puisque le code est minimal, il est facile de renommer les choses en un exemple plus basique foo / bar / baz.

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.