De bonnes stratégies pour le développement de code? Jetable

Question

J'écris souvent un code jetable (dans un environnement de recherche ) - par exemple pour explorer un algorithme ou un modèle pour une propriété scientifique ou d'un processus. Un grand nombre de ces « expériences » sont ponctuelles mais parfois je trouve que je dois utiliser un peu plus tard. Par exemple, je viens de code pour déterrés string matching je l'ai écrit il y a 7 ans (arrêté en raison d'autres priorités), mais qui est maintenant valable pour le projet d'un collègue de travail. Après avoir regardé (ai-je vraiment écrire un tel code impénétrable?) Je sais qu'il ya certaines choses que je aurais pu faire alors pour me aider quand je remis en marche le « projet » ( « expérience » est encore un meilleur mot). L'expérience antérieure « a travaillé » mais je sais qu'à l'époque, je ne l'aurais pas eu le temps de factoriser que mes priorités sont ailleurs.

Quelles sont les approches rentables pour permettre un tel travail à creuser et réutilisée?

EDIT :. J'ai répondu à ma propre question (ci-dessous) parce qu'il ya des problèmes au-delà de la source réelle elle-même

Answer 1

Je suis en désaccord avec toutes les réponses disant: « écrire des commentaires ». C'est offert comme un fourre-tout pour le code lui-même ne pas être compréhensible.

Procurez-vous une copie de code complet (Steve McConnell, 2e édition). Si vous apprenez les techniques de l'écriture du code maintenable en premier lieu, il ne vous prendra pas plus de temps, et vous serez en mesure de revenir à votre travail plus tard, avec moins de peine.

Que préféreriez-vous:

• Code Cryptic avec des commentaires?
• OK sans Code La plupart du temps?

Je préfère fortement ce dernier, comme le code OK est plus facile à comprendre dans les situations où le code cryptique était décommentée, et les commentaires sont un autre endroit que le développeur d'origine peut faire des erreurs. Le code peut être Buggy , mais il n'a jamais mauvais .

Une fois que vous êtes à l'aise avec code complet , je recommande

Answer 2

[Répondre propre question] Il y a plusieurs autres aspects du problème qui n'a pas été soulevé et que je l'aurais trouvé utile pour revisiter. Certains d'entre eux peuvent être « soi », mais rappelez-vous ce code a été pré-SVN et IDEs.

• découvrir la preuve . Il a été effectivement difficile de trouver le code. Je crois qu'il est dans mon projet SourceForge, mais il y a tant de versions et les branches de plus de 7 ans que je ne le trouve pas. Je devrais donc avoir un système qui recherche code et jusqu'à ce que IDEs est apparu, je ne pense pas qu'il y avait.
• Que faut-il faire? . La caisse actuelle contient environ 13 classes (tous dans un seul paquet car il n'a pas été facile à factoriser à l'époque). Certains sont clairs (DynamicAligner), mais d'autres sont opaques (MainBox, nommée parce qu'elle tendit une boîte Swing). Il y a quatre programmes de main() et il y a en fait environ 3 sous-projets dans le distrib. Il est donc essentiel d'avoir un manifeste externe à ce que les composants étaient en fait.
• instructions sur la façon de l'exécuter . Lors de l'exécution du programme, main() offrira une utilisation brève de ligne de commande (par exemple DynamicAligner file1 file2), mais il ne dit pas ce que le contenu des fichiers ressemblent vraiment. Je savais que cela à l'époque, bien sûr, mais pas maintenant. Donc, il devrait être associé exemple des fichiers dans les annuaires frères et soeurs. Ce sont plus précieux que d'essayer de documenter les formats de fichiers.
• ça marche encore? . Il devrait être possible de faire fonctionner chaque chaque exemple sans y penser. La première question sera de savoir si les bibliothèques associées, runtimes, etc. sont encore pertinents et disponibles. Un ex-collègue de travail a écrit un système qui ne fonctionne qu'avec une version particulière de Python. La seule réponse consiste à réécrire. Alors, bien sûr, nous devons éviter tout blocage dans la mesure du possible, et je me suis formé (mais pas nécessairement) collègues de le faire.

Alors, comment puis-je et collègues d'éviter des problèmes à l'avenir? Je pense que la première étape est qu'il devrait y avoir une discipline de la création d'un « projet » (si petit) lorsque vous créez code et que ces projets doivent être sous contrôle de version. Cela peut sembler évident pour certains d'entre vous, mais dans certains milieux (milieux universitaires, nationaux), il y a une surcharge importante pour la mise en place d'un système de gestion de projet. Je soupçonne que la majorité du Code académique n'est pas sous contrôle de version.

Ensuite, il y a la question de savoir comment devraient être organisés les projets. Ils ne peuvent pas être sur Sourceforge par défaut que le code est (a) trivial et (b) pas ouvert par défaut. Nous avons besoin d'un serveur où il peut y avoir deux projets communautaires et privés. Je calculais que l'effort pour le mettre en place et exécuter est d'environ 0,1 ETP - qui est de 20 jours par an de toutes les parties (installation, formation, maintenance) - s'il y a des options plus faciles, je voudrais savoir que c'est un grand frais dans certains cas - ce que je passe mon temps la mise en place d'un serveur ou dois-je rédiger des documents

Le projet devrait essayer d'encourager une bonne discipline. C'est vraiment ce que j'espérais obtenir de cette question. Il pourrait inclure:

1. Un modèle de composants nécessaires (manifeste, README, journal des commits, des exemples, des bibliothèques nécessaires, etc. Tous les projets peuvent fonctionner sous Maven - par exemple FORTRAN)
.
2. Un moyen de la recherche d'un grand nombre (des centaines au moins) de petits projets pour les chaînes mnémoniques (j'ai aimé l'idée de dumping le code dans GoogleDocs, et cela peut être une avenue fructueuse - mais il est l'effort de maintenance supplémentaire)
3. conventions de nommage claires. Ce sont plus de valeur que des commentaires. J'ai maintenant régulièrement les noms des iterateOverAllXAndDoY de type. J'essaie d'utiliser createx () plutôt que getX () lorsque la routine crée effectivement des informations. J'ai une mauvaise habitude d'appeler processus de routines () plutôt que convertAllBToY ().

Je suis au courant, mais ne l'ai pas utilisé GIT et Mercurial et GoogleCode.Je ne sais pas combien d'efforts sont ceux-ci à mettre en place et combien de mes préoccupations qu'ils répondent. Je serais heureux s'il y avait un plugin IDE qui a contribué à créer un meilleur code (par exemple « mauvais choix du nom de la méthode »).

Et quelles que soient les approches qu'ils ont obtenu venir naturellement aux gens qui n'ont pas naturraly bonne discipline de code et d'être en vaut la peine.

Comme les excellentes réponses dans votre autre message indiquer et de ma propre expérience, il y a un écart difficile à croisement entre le logiciel utilisé pour la recherche et le logiciel qui a été conçu. À mon avis, le code complet pourrait aider un peu, mais pas beaucoup. Comme une question économique, cela va être intéressant de factoriser tout pour la réutilisation par rapport à la récompense occasionnelle pour trouver une utilisation ultérieure pour quelque chose? Votre point d'équilibre peut varier.

Voici une astuce pratique pour stocker des extraits. Au lieu de commentaires épanouies, jeter dans certains mots-clés:

• "wrapper graphique isomorphisme"
• "recuit simulé polymère"
• "Correspond à la chaîne Feynmann"
• "équilibre"

et puis mettre le code quelque part Google des recherches, comme un compte GMail.

Edit:. Je pourrais ajouter que les sites Google sont gratuits wikis vraiment interrogeables qui sont un bon endroit pour mettre le code, que ce soit sous forme de pièces jointes ou collé dans

En outre, je dois dire que je suis un fan de code complet et ont donné des copies aux étudiants diplômés des logiciels d'écriture pour la recherche scientifique depuis plusieurs années. Il est un bon début, mais pas de solution miracle. Je vous écris un document en ce moment sur l'utilisation de frameworks open source pour résoudre les problèmes de gestion des données scientifiques et l'une des conclusions est que une certaine expertise en ingénierie logicielle est essentielle pour les systèmes de longue durée. De nombreux projets scientifiques devraient probablement le budget pour cela dès le début.

Commentaires - décrire ce que vous pensiez et pourquoi vous avez choisi de mettre en œuvre quelque chose d'une certaine manière, y compris les solutions de rechange vous envisagé. Il y a probablement toutes sortes de solutions de fantaisie mais juste de commenter votre code correctement au moment où vous écrivez il semble fonctionner le mieux.

J'écho à ce que les autres ont dit que ce qui commente le « pourquoi est » pourquoi le code a été écrit et il est prévu l'utilisation, mais je voudrais également ajouter ceci:

Code comme si vous aviez prévu de mettre cela en production même lorsque vous êtes juste déconner. Code pour:

• Clarté et lisibilité
• Suivez les conventions de codage du temps. (Conventions de nommage, etc). Même si ces conventions changent au fil du temps, si vous vous en tenez aux normes que vous êtes plus susceptibles d'être en mesure de comprendre plus tard.
• Sécurité (le cas échéant)
• la performance (le cas échéant)

En particulier, je tiens à souligner le premier point, mais les autres sont aussi importants. Je trouve que si je l'utilise « code de test » plus tard, j'ai tendance à utiliser seulement si cela fonctionne, plutôt que de réarranger il.

Je l'ai probablement manqué le point de cette discussion, je fais souvent, mais va ici, une invitation pour tessons et downvoting ...

Si son code jetable, le jeter!

Si vous ne voulez pas jeter puis suivre les bons conseils ci-dessus. Pour moi, et j'écris une bonne quantité de code de jetable, la question de savoir si elle se jeté ou mis dans un état réutilisable et maintenu contre un jour de pluie se résume à l'économie.

Puis-je prévoir les circonstances dans lesquelles ce code sera utile à nouveau? Une fois dans une lune bleue, deux fois par an, chaque mois?

Vais-je être en mesure de réécrire ce code en moins de temps qu'il faut pour la rendre réutilisable? Si la réponse à cette question est non, alors combien de fois devrai-je réutiliser pour qu'il vaille la peine, tout en améliorant maintenant? (Retour à la question précédente.)

Si je fais ce code réutilisable, je serai capable de le trouver à nouveau quand je veux par la suite? (Quiconque a déjà eu l'expérience de savoir, avec une certitude absolue, que quelque part dans votre référentiel de code, il est juste le fragment que vous voulez, mais ne pas avoir la moindre idée de ce qu'il a été appelé, ni où chercher ni quoi grep?)

Enfin, l'approche 3 étapes pour faire rapidement le code réutilisable écrit. Arrêt après celui de ces étapes que vous aimez:

1) Document de code comme une boîte noire. Entrées, sorties, opération (s). Déposer ce document attentivement.

2) Rédiger des instructions sur la façon de construire / interpréter / installer le code, si vous avez jamais le porter. Classez ces instructions attentivement.

3) que si l'effort vaut la peine - améliorer la qualité du code source pour rendre le code maintenable à l'avenir. Assurez-vous que les sources sont dans le système de contrôle de code source et trouvable.

Cordialement

Mark

Je pense que la chose la plus à l'importation (si vous ne refactorisation il ne va pas se produire) est de commenter et documenter votre processus de pensée à l'époque. Il contribuera à rendre le code moins impénétrable et vous aider à trouver les bons morceaux en cas de besoin.

Non, Non, Non, Non, Non!

Ne pas écrire du code dans un même jetable environnement de recherche. S'il vous plaît!

Actuellement, je suis de jouer avec un tel « code jetable », à savoir projet BLAST. La chose est qu'il a commencé comme un terrain de jeu mais est arrivé à devenir un peu de succès, il est maintenant un outil propre avec de nombreux concepts mis en œuvre, mais le code est pratiquement ingérable. Mais ce n'est pas le point principal.

Le point principal est, vous faites la recherche pour les ingénieurs à profit plus tard de vos résultats. Après avoir fait un bon travail scientifique sur le concept général et l'écriture d'un outil qui prouve avec succès, vous pouvez facilement oublier que vous le faites pas pour publication et doctorat seulement. Vous le faites au profit de l'humanité. Votre code peut contenir un tas de « cas particuliers », qui étaient difficiles à déboguer, un ensemble de bizarreries et hacks qui ne rentrent pas dans un article de la conférence. Il est particulièrement important de documenter et de commenter ces choses tout au long de votre code.

Si un développeur a décidé de mettre en œuvre vos concepts dans un produit commercial, il aurait pu étudier les bizarreries et les hacks de votre code et la mise en œuvre aurait dix ont moins de bugs qu'il aurait pu avoir. Tout le monde dit: « Wow, ses recherches sur A est vraiment utile! » Mais si vous écrivez « jetable », disent-ils « son concept a l'air bien sur le papier, mais X a essayé de mettre en œuvre et noyé dans un tas de bugs ».

( EDIT : prise des commentaires ci-dessous) Pour aider les futurs développeurs de votre base de code, vous n'avez pas besoin de beaucoup. Tout d'abord, commenter ce que chaque fonction . En second lieu, Assurez-vous que chaque solution non évidente d'un bogue délicat est placé dans un commit séparé dans le système de contrôle de révision (avec un commentaire approprié, bien sûr). C'est tout à fait suffisant. Et si vous même faire des choses modulaire. (Même si elles ne sont pas prêts à être réutilisés pur et simple - qui est trois fois plus cher, selon Brooks), vous serez adulé par les ingénieurs qui mettent en œuvre votre recherche

Je pense que le monde serait meilleur si les chercheurs ont jeté leur orgueil et cessé de penser hautaine qu'ils ne sont pas ces sales codeurs qui font travail servile d'écrire un bon code. L'écriture d'un bon code est non seulement un emploi pour ces programmeurs stupides. Il est une chose tout le monde vraiment précieux devrait tendre. Sans cela, votre terrain expérimental, votre code, votre idée originale va juste mourir.

Quelques stratégies:

1. De bons commentaires. Difficile de réutiliser ce que vous ne pouvez pas trouver ou comprendre plus tard.
2. Enregistrer chaque requête dans un dossier qui est sauvegardé ou est sous contrôle de code source.
3. Avoir une bibliothèque commune de fonctions utiles que vous « promouvoir » quelque chose à une fois qu'il a été réutilisé.

Vous pouvez également emprunter l'idée de tests unitaires de la Folks TDD (développement piloté par les tests-). Vous devez vous assurer que le code fonctionne réellement OK jetable de toute façon, alors pourquoi ne pas exprimer le chèque linke un petit test unitaire? Cela aurait deux avantages:

1. La lecture du code de test communique l'intention du jetable très clairement: après tout, il exprime ses attentes dans la même langue. Code

2. Il serait également utile au 4ème problème de votre auto-réponse: « ça marche encore? ». Eh bien, il est facile: il suffit d'exécuter les tests unitaires et ils vous dire quoi et où (et avec un peu de chance) pourquoi (il) ne fonctionne pas

.

Answer 3

[Répondre propre question] Il y a plusieurs autres aspects du problème qui n'a pas été soulevé et que je l'aurais trouvé utile pour revisiter. Certains d'entre eux peuvent être « soi », mais rappelez-vous ce code a été pré-SVN et IDEs.

• découvrir la preuve . Il a été effectivement difficile de trouver le code. Je crois qu'il est dans mon projet SourceForge, mais il y a tant de versions et les branches de plus de 7 ans que je ne le trouve pas. Je devrais donc avoir un système qui recherche code et jusqu'à ce que IDEs est apparu, je ne pense pas qu'il y avait.
• Que faut-il faire? . La caisse actuelle contient environ 13 classes (tous dans un seul paquet car il n'a pas été facile à factoriser à l'époque). Certains sont clairs (DynamicAligner), mais d'autres sont opaques (MainBox, nommée parce qu'elle tendit une boîte Swing). Il y a quatre programmes de main() et il y a en fait environ 3 sous-projets dans le distrib. Il est donc essentiel d'avoir un manifeste externe à ce que les composants étaient en fait.
• instructions sur la façon de l'exécuter . Lors de l'exécution du programme, main() offrira une utilisation brève de ligne de commande (par exemple DynamicAligner file1 file2), mais il ne dit pas ce que le contenu des fichiers ressemblent vraiment. Je savais que cela à l'époque, bien sûr, mais pas maintenant. Donc, il devrait être associé exemple des fichiers dans les annuaires frères et soeurs. Ce sont plus précieux que d'essayer de documenter les formats de fichiers.
• ça marche encore? . Il devrait être possible de faire fonctionner chaque chaque exemple sans y penser. La première question sera de savoir si les bibliothèques associées, runtimes, etc. sont encore pertinents et disponibles. Un ex-collègue de travail a écrit un système qui ne fonctionne qu'avec une version particulière de Python. La seule réponse consiste à réécrire. Alors, bien sûr, nous devons éviter tout blocage dans la mesure du possible, et je me suis formé (mais pas nécessairement) collègues de le faire.

Alors, comment puis-je et collègues d'éviter des problèmes à l'avenir? Je pense que la première étape est qu'il devrait y avoir une discipline de la création d'un « projet » (si petit) lorsque vous créez code et que ces projets doivent être sous contrôle de version. Cela peut sembler évident pour certains d'entre vous, mais dans certains milieux (milieux universitaires, nationaux), il y a une surcharge importante pour la mise en place d'un système de gestion de projet. Je soupçonne que la majorité du Code académique n'est pas sous contrôle de version.

Ensuite, il y a la question de savoir comment devraient être organisés les projets. Ils ne peuvent pas être sur Sourceforge par défaut que le code est (a) trivial et (b) pas ouvert par défaut. Nous avons besoin d'un serveur où il peut y avoir deux projets communautaires et privés. Je calculais que l'effort pour le mettre en place et exécuter est d'environ 0,1 ETP - qui est de 20 jours par an de toutes les parties (installation, formation, maintenance) - s'il y a des options plus faciles, je voudrais savoir que c'est un grand frais dans certains cas - ce que je passe mon temps la mise en place d'un serveur ou dois-je rédiger des documents

Le projet devrait essayer d'encourager une bonne discipline. C'est vraiment ce que j'espérais obtenir de cette question. Il pourrait inclure:

1. Un modèle de composants nécessaires (manifeste, README, journal des commits, des exemples, des bibliothèques nécessaires, etc. Tous les projets peuvent fonctionner sous Maven - par exemple FORTRAN)
.
2. Un moyen de la recherche d'un grand nombre (des centaines au moins) de petits projets pour les chaînes mnémoniques (j'ai aimé l'idée de dumping le code dans GoogleDocs, et cela peut être une avenue fructueuse - mais il est l'effort de maintenance supplémentaire)
3. conventions de nommage claires. Ce sont plus de valeur que des commentaires. J'ai maintenant régulièrement les noms des iterateOverAllXAndDoY de type. J'essaie d'utiliser createx () plutôt que getX () lorsque la routine crée effectivement des informations. J'ai une mauvaise habitude d'appeler processus de routines () plutôt que convertAllBToY ().

Je suis au courant, mais ne l'ai pas utilisé GIT et Mercurial et GoogleCode.Je ne sais pas combien d'efforts sont ceux-ci à mettre en place et combien de mes préoccupations qu'ils répondent. Je serais heureux s'il y avait un plugin IDE qui a contribué à créer un meilleur code (par exemple « mauvais choix du nom de la méthode »).

Et quelles que soient les approches qu'ils ont obtenu venir naturellement aux gens qui n'ont pas naturraly bonne discipline de code et d'être en vaut la peine.

Answer 4

Comme les excellentes réponses dans votre autre message indiquer et de ma propre expérience, il y a un écart difficile à croisement entre le logiciel utilisé pour la recherche et le logiciel qui a été conçu. À mon avis, le code complet pourrait aider un peu, mais pas beaucoup. Comme une question économique, cela va être intéressant de factoriser tout pour la réutilisation par rapport à la récompense occasionnelle pour trouver une utilisation ultérieure pour quelque chose? Votre point d'équilibre peut varier.

Voici une astuce pratique pour stocker des extraits. Au lieu de commentaires épanouies, jeter dans certains mots-clés:

• "wrapper graphique isomorphisme"
• "recuit simulé polymère"
• "Correspond à la chaîne Feynmann"
• "équilibre"

et puis mettre le code quelque part Google des recherches, comme un compte GMail.

Edit:. Je pourrais ajouter que les sites Google sont gratuits wikis vraiment interrogeables qui sont un bon endroit pour mettre le code, que ce soit sous forme de pièces jointes ou collé dans

En outre, je dois dire que je suis un fan de code complet et ont donné des copies aux étudiants diplômés des logiciels d'écriture pour la recherche scientifique depuis plusieurs années. Il est un bon début, mais pas de solution miracle. Je vous écris un document en ce moment sur l'utilisation de frameworks open source pour résoudre les problèmes de gestion des données scientifiques et l'une des conclusions est que une certaine expertise en ingénierie logicielle est essentielle pour les systèmes de longue durée. De nombreux projets scientifiques devraient probablement le budget pour cela dès le début.

Answer 5

Commentaires - décrire ce que vous pensiez et pourquoi vous avez choisi de mettre en œuvre quelque chose d'une certaine manière, y compris les solutions de rechange vous envisagé. Il y a probablement toutes sortes de solutions de fantaisie mais juste de commenter votre code correctement au moment où vous écrivez il semble fonctionner le mieux.

Answer 6

J'écho à ce que les autres ont dit que ce qui commente le « pourquoi est » pourquoi le code a été écrit et il est prévu l'utilisation, mais je voudrais également ajouter ceci:

Code comme si vous aviez prévu de mettre cela en production même lorsque vous êtes juste déconner. Code pour:

• Clarté et lisibilité
• Suivez les conventions de codage du temps. (Conventions de nommage, etc). Même si ces conventions changent au fil du temps, si vous vous en tenez aux normes que vous êtes plus susceptibles d'être en mesure de comprendre plus tard.
• Sécurité (le cas échéant)
• la performance (le cas échéant)

En particulier, je tiens à souligner le premier point, mais les autres sont aussi importants. Je trouve que si je l'utilise « code de test » plus tard, j'ai tendance à utiliser seulement si cela fonctionne, plutôt que de réarranger il.

Answer 7

Je l'ai probablement manqué le point de cette discussion, je fais souvent, mais va ici, une invitation pour tessons et downvoting ...

Si son code jetable, le jeter!

Si vous ne voulez pas jeter puis suivre les bons conseils ci-dessus. Pour moi, et j'écris une bonne quantité de code de jetable, la question de savoir si elle se jeté ou mis dans un état réutilisable et maintenu contre un jour de pluie se résume à l'économie.

Puis-je prévoir les circonstances dans lesquelles ce code sera utile à nouveau? Une fois dans une lune bleue, deux fois par an, chaque mois?

Vais-je être en mesure de réécrire ce code en moins de temps qu'il faut pour la rendre réutilisable? Si la réponse à cette question est non, alors combien de fois devrai-je réutiliser pour qu'il vaille la peine, tout en améliorant maintenant? (Retour à la question précédente.)

Si je fais ce code réutilisable, je serai capable de le trouver à nouveau quand je veux par la suite? (Quiconque a déjà eu l'expérience de savoir, avec une certitude absolue, que quelque part dans votre référentiel de code, il est juste le fragment que vous voulez, mais ne pas avoir la moindre idée de ce qu'il a été appelé, ni où chercher ni quoi grep?)

Enfin, l'approche 3 étapes pour faire rapidement le code réutilisable écrit. Arrêt après celui de ces étapes que vous aimez:

1) Document de code comme une boîte noire. Entrées, sorties, opération (s). Déposer ce document attentivement.

2) Rédiger des instructions sur la façon de construire / interpréter / installer le code, si vous avez jamais le porter. Classez ces instructions attentivement.

3) que si l'effort vaut la peine - améliorer la qualité du code source pour rendre le code maintenable à l'avenir. Assurez-vous que les sources sont dans le système de contrôle de code source et trouvable.

Cordialement

Mark

Answer 8

Je pense que la chose la plus à l'importation (si vous ne refactorisation il ne va pas se produire) est de commenter et documenter votre processus de pensée à l'époque. Il contribuera à rendre le code moins impénétrable et vous aider à trouver les bons morceaux en cas de besoin.

Answer 9

Non, Non, Non, Non, Non!

Ne pas écrire du code dans un même jetable environnement de recherche. S'il vous plaît!

Actuellement, je suis de jouer avec un tel « code jetable », à savoir projet BLAST. La chose est qu'il a commencé comme un terrain de jeu mais est arrivé à devenir un peu de succès, il est maintenant un outil propre avec de nombreux concepts mis en œuvre, mais le code est pratiquement ingérable. Mais ce n'est pas le point principal.

Le point principal est, vous faites la recherche pour les ingénieurs à profit plus tard de vos résultats. Après avoir fait un bon travail scientifique sur le concept général et l'écriture d'un outil qui prouve avec succès, vous pouvez facilement oublier que vous le faites pas pour publication et doctorat seulement. Vous le faites au profit de l'humanité. Votre code peut contenir un tas de « cas particuliers », qui étaient difficiles à déboguer, un ensemble de bizarreries et hacks qui ne rentrent pas dans un article de la conférence. Il est particulièrement important de documenter et de commenter ces choses tout au long de votre code.

Si un développeur a décidé de mettre en œuvre vos concepts dans un produit commercial, il aurait pu étudier les bizarreries et les hacks de votre code et la mise en œuvre aurait dix ont moins de bugs qu'il aurait pu avoir. Tout le monde dit: « Wow, ses recherches sur A est vraiment utile! » Mais si vous écrivez « jetable », disent-ils « son concept a l'air bien sur le papier, mais X a essayé de mettre en œuvre et noyé dans un tas de bugs ».

( EDIT : prise des commentaires ci-dessous) Pour aider les futurs développeurs de votre base de code, vous n'avez pas besoin de beaucoup. Tout d'abord, commenter ce que chaque fonction . En second lieu, Assurez-vous que chaque solution non évidente d'un bogue délicat est placé dans un commit séparé dans le système de contrôle de révision (avec un commentaire approprié, bien sûr). C'est tout à fait suffisant. Et si vous même faire des choses modulaire. (Même si elles ne sont pas prêts à être réutilisés pur et simple - qui est trois fois plus cher, selon Brooks), vous serez adulé par les ingénieurs qui mettent en œuvre votre recherche

Je pense que le monde serait meilleur si les chercheurs ont jeté leur orgueil et cessé de penser hautaine qu'ils ne sont pas ces sales codeurs qui font travail servile d'écrire un bon code. L'écriture d'un bon code est non seulement un emploi pour ces programmeurs stupides. Il est une chose tout le monde vraiment précieux devrait tendre. Sans cela, votre terrain expérimental, votre code, votre idée originale va juste mourir.

Answer 10

Quelques stratégies:

1. De bons commentaires. Difficile de réutiliser ce que vous ne pouvez pas trouver ou comprendre plus tard.
2. Enregistrer chaque requête dans un dossier qui est sauvegardé ou est sous contrôle de code source.
3. Avoir une bibliothèque commune de fonctions utiles que vous « promouvoir » quelque chose à une fois qu'il a été réutilisé.

Answer 11

Vous pouvez également emprunter l'idée de tests unitaires de la Folks TDD (développement piloté par les tests-). Vous devez vous assurer que le code fonctionne réellement OK jetable de toute façon, alors pourquoi ne pas exprimer le chèque linke un petit test unitaire? Cela aurait deux avantages:

1. La lecture du code de test communique l'intention du jetable très clairement: après tout, il exprime ses attentes dans la même langue. Code

2. Il serait également utile au 4ème problème de votre auto-réponse: « ça marche encore? ». Eh bien, il est facile: il suffit d'exécuter les tests unitaires et ils vous dire quoi et où (et avec un peu de chance) pourquoi (il) ne fonctionne pas

.