Prototypage vs code propre au début


43

Je prévois de travailler sur quelques projets personnels qui pourraient devenir mon travail quotidien. Cela m'a fait réfléchir, par quel chemin devrais-je commencer?

  • Protégez simplement - écrivez simplement du code de base fonctionnel qui pourrait me coûter beaucoup de temps d'optimisation et de refactorisation pour une expansion facile.

  • Écrivez du code propre, optimisé et documenté dès le début, en gardant à l'esprit que s'il ne sera pas rentable après un certain temps, il sera abandonné.

Mise à jour: La combinaison de YAGNI avec les réponses sunpech et M.Sameer me semble parfaitement logique :) merci à tous pour votre aide.


1
voir aussi: Quand refactoriser
Gnat

Réponses:


39

Il existe une troisième option ... écrire du code propre via un développement piloté par les tests pour mettre en œuvre les exigences requises aujourd'hui par YAGNI.

La tentation d'écrire du code qui n'est pas nécessaire pour le moment mais qui le sera peut-être à l'avenir souffre de plusieurs inconvénients ... de Vous n'en aurez pas besoin :

  • Le temps nécessaire est pris en ajoutant, en testant ou en améliorant les fonctionnalités nécessaires.
  • 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. Une fonctionnalité inutile peut dès lors empêcher la mise en œuvre ultérieure d'une fonctionnalité nécessaire.
  • Tant que cette fonctionnalité n’est pas réellement nécessaire, 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 de boule de neige et donner lieu à des fonctionnalités insidieuses.

En conséquence, vous ne devriez pas simplement prototyper ... ni écrire de code propre, optimisé et documenté dès le début, sachant que si ce délai n’est pas rentable, il sera abandonné.

Écrivez le code dont vous avez besoin maintenant, sachant que vous êtes alors en mesure de répondre au mieux aux besoins d'aujourd'hui et de demain.


4
Bien que je ne sois pas un fan du TDD à part entière, c'est toujours un bon conseil, car suivre TDD vous obligera à écrire un code propre et bien documenté.
Wayne Molina

1
Je pense que ce qu'il voulait dire, c'est qu'il abandonnerait tout le projet s'il ne réussissait pas. Si cela est vrai, alors cette réponse ne semble pas différente de "écrire du code vierge".
Jeremy

@ Jeremy, vous supposez juste sur ma réponse. Mais cette réponse n'est pas la même. Il est basé sur le chemin de programmation stricte autre où est basée sur l' expérience, bien sûr qu'ils regardent dans certains cas similaires, mais ce n'est pas le même :) bien au moins du point je le vois :)
JackLeo

1
@JackLeo Je pense que le fait est qu'une fois que vous avez atteint un certain niveau d'expérience, il n'y a plus de différence entre "le code sur lequel j'ai travaillé dur" et "le code que je viens d'écrire".
Ant P

@AntP En effet. Il est intéressant de réfléchir à cette question 6 ans plus tard :)
JackLeo

16

comme d'habitude...

Ça dépend

Si vous prototypez pour atténuer un risque ou exposer un inconnu, codez-le et attendez-vous à le jeter à la fin.

Si vous prototypez pour un raffinement itératif, codez-le et attendez-vous à le modifier et le refactoriser fréquemment.

Si vous commencez à écrire le produit réel mais que vous l'appelez prototypage afin de pouvoir être paresseux , ne le soyez pas, et écrivez-le bien la première fois.


2
+1 excellent post! J'ajouterais que bien que cela puisse sembler inutile après avoir développé cette fonctionnalité, ne jetez JAMAIS vos prototypes. Je contrôle toujours tous les prototypes sur lesquels je travaille, car je leur renvoie parfois des astuces.
maple_shaft

1
@maple_shaft: oui, "jeter" est métaphoriquement, comme dans "n'essayez pas nécessairement de le reformuler, prévoyez de le réécrire"
Steven A. Lowe le

2
Je dis: soyez paresseux et écrivez bien la première fois pour ne pas avoir à revenir en arrière plus tard.
Blrfl

3ème phrase fait ma journée.
Christopher Francisco

10

Si vous prototypez, pourquoi songez-vous au code propre? L'idée même du prototypage est qu'il vise à prouver un concept ou une idée et à être jeté par la suite.

Je ne suis pas du même avis que presque tout le monde ici: si vous envisagez déjà le choix entre écrire du code propre ou faire quelque chose de rapide pour le prototypage, choisissez ce dernier. Surtout quand vous parlez de développement précoce. Je ne dis pas que n'écrivez jamais de code propre, je dis simplement de faire ressortir l'idée, de voir que c'est la direction à suivre, puis de la nettoyer, refactor.

En tant que développeurs de logiciels, nous sommes tellement habitués à faire les choses correctement et à la propreté du premier coup, que nous ne réalisons pas que ce n'est pas du code que nous fournissons, mais une solution à un problème .

Je pense coder comme je rédigerais un papier:

Lors de la rédaction d'un document, nous commençons quelque part, dessinons des idées, des contours, etc. Il ne contiendra pas tous les détails ni ne sera examiné de manière approfondie - il s'agira essentiellement d'un premier projet, suivi d'un second, etc. Une grande partie sera réécrite, remplacée et / ou même supprimée en cours de route pour donner un papier plus raffiné et plus fini. (Évidemment, cette analogie ne va pas jusqu'à dire que le code est toujours vraiment fini ou final comme un papier.)


+1 Très bonne réponse :) Cela m'est souvent arrivé à mes débuts, alors sauter sur de gros projets peut causer la même chose ... c'est ce dont j'ai peur.
JackLeo

"En tant que développeurs de logiciels, nous sommes tellement habitués à faire les choses correctement et à la propreté du premier coup, que nous ne réalisons pas que ce n'est pas du code que nous fournissons, mais une solution à un problème." Je dirais l’inverse: "Nous n’avons jamais le temps de le faire correctement mais nous avons toujours le temps de le faire".
Christopher Francisco

6

Il existe deux types de prototypage:

  • Prototype évolutif qui continue d'évoluer via des améliorations et des correctifs pour devenir le produit final.
  • Prototype à usage unique destiné uniquement à rendre la collecte des exigences et les commentaires des clients plus efficace dès les premières étapes du projet, puis totalement abandonné et le développement du produit final commence à partir de zéro.

Selon Capers Jones, les prototypes évolutifs produisent des produits finis de qualité médiocre qui nécessiteront beaucoup plus d'effort et plus de temps pour atteindre la stabilité.

Donc, si vous envisagez de créer des prototypes pour que le client puisse voir quelque chose le plus rapidement possible afin de vous aider à avoir une idée plus précise et plus de détails sur les exigences, il est préférable d’être un prototype jetable et de développer le code propre ultérieurement. Si vous ne pouvez vous le permettre, écrivez du code vierge dès le début et conservez-le avec précaution, mais comme d'autres l'ont suggéré, n'optimisez pas au maximum et n'ajoutez rien tant que vous n'en aurez pas besoin.


Très bon point, c'est pour montrer différents types de prototypage, je n'y ai pas pensé :) De
quoi

D'accord avec le point!
Richard Topchiy

Le gros risque du prototype jetable est que la direction aura du mal à comprendre pourquoi la version de production devrait prendre si longtemps par rapport au prototype et pourquoi le travail sur le prototype devrait être «gaspillé». Bien sûr, s'il s'agit de votre propre démarrage potentiel, il n'y a pas de telle gestion, ce qui facilite grandement les choses.
Jan Hudec

5

Je suis réticent à excuser un code sale pour une raison quelconque. D'après mon expérience, les personnes qui prétendent que quick and dirty est une excuse pour le prototypage ont cette attitude envers n'importe quel code, y compris la production. Si quelqu'un crée un prototype en désordre, il crée des dégâts dans n'importe quel code. Prototyper ne signifie pas coder de manière incorrecte, cela signifie des hypothèses simplifiées pour tester les cas d'utilisation les plus importants. Le code peut ne pas être formellement testé, ni prendre en charge tous les détails, mais il doit toujours être bien conçu et mis en œuvre. La propreté est un signe de compétence, les programmeurs compétents éprouvent un dégoût naturel envers un code compliqué, quel que soit son objectif.


Juste une chose que j'ai oublié de mentionner. Je l'ai encore et encore vu que des gens écrivaient vite et mal à des fins de "prototypage" et que cela devenait douloureux et laid à des fins de production. Depuis que tout est fait et que les choses fonctionnent, les gens ne cessent d’ajouter des bandages et d’empiler désordre.
Gene Bushuyev le

Vous avez un bon point - "pourquoi ré-écrire si cela fonctionne?" C’est un problème pour beaucoup de jeunes entreprises, je le constate même dans mon poste actuel, lorsque de grandes entreprises utilisent un système de gestion de contenu vieux de 10 ans, ce qui est pénible pour une mise à niveau conforme aux normes actuelles ... Je ne veux pas faire d’erreur ici. Bien que votre réponse dise principalement que je cherche une excuse pour écrire du code bâclé. Sunpech et M.Sameer ont compris mon argument. Prototype est de faire quelque chose pour voir comment le monde va réagir à cela. Si cela fonctionne, faites-le bien.
JackLeo

1

Écrivez du code propre, optimisé et documenté dès le début. Je suis incapable de le faire moi-même et c'est un problème réel. Je ne suis pas un codeur, mais j'ai beaucoup travaillé pour des sociétés de développement de logiciels et des rôles de gestion en relation avec la clientèle; comme ils me donnent beaucoup de bonnes idées, je construis parfois un prototype pour quelque chose. Presque chaque fois, ce prototype a ensuite été remis à un développeur qui l'a "nettoyé" et l'a transformé en un produit d'expédition. Lorsque je vérifie le code source, il reste 80% à 90% de mon code pourri.


0

Un de mes collègues approuve avec enthousiasme le prototypage répété, en précisant toutefois qu'il est nécessaire d' être assez discipliné pour jeter chaque prototype et réécrire à partir de rien - et pas seulement pour cela, assurez-vous de ne pas être influencé par les détails de mise en œuvre décidés la dernière fois. En fin de compte, on écrit plusieurs fois le même prototype dans un style trivialement différent. Il a suggéré de façon semi-sérieuse que si vous étiez vraiment attaché à un élément de code génial que vous ne pouviez probablement pas rejeter, vous devriez l'imprimer, supprimer le référentiel de contrôle de code source et poster la copie imprimée sur votre ordinateur. assez longtemps pour qu'il ne puisse pas s'infiltrer à la prochaine itération.


Cet article est plutôt difficile à lire (mur de texte). Pourriez - vous l' esprit modifier ing dans une meilleure forme?
Gnat

Pouvez-vous suggérer ce que vous pensez que le problème est? Peut-être que les phrases sont trop longues, comme je viens de remarquer qu'il n'y en a que deux. Rien d'autre?
Tom W

-1

Vous pouvez toujours commencer par le faire fonctionner (du tout), puis le réviser pour le rendre propre, puis le rendre rapide / petit si cela a un sens économique de le faire. Je commencerais par quelques expériences que vous jetez, puis par TDD à nouveau lorsque vous maîtriserez ce qui fonctionne.


-1

Les deux sont bons. Les deux j'aime bien. Ils ne se contredisent pas.

J'aime prototyper. Prototyper, c'est développer ma créativité. Je teste de nombreuses solutions possibles. Faire ça rapidement me donne la possibilité de tester beaucoup de façons possibles de résoudre un problème.

J'aime écrire du code propre et bien testé. Cela développe mes compétences fondamentales. J'ai l'habitude de choisir l'un des prototypes et de l'améliorer ou de le réécrire à partir de zéro.

Mais vous ne devez jamais confondre le prototype avec le code de production. Le prototype ne devrait jamais entrer en production. Il devrait toujours être marqué comme prototype. Au mieux, faites tous les prototypes dans votre propre branche.


-2

J'ai tendance à dire que les extrêmes sont presque toujours mauvais.

Je conseille de garder l'équilibre entre propreté, bien documenté et prototypage. Lorsque vous développez pour une bibliothèque ou une plate-forme avec laquelle vous n'avez pas d'expérience, j'entre davantage dans la direction du prototypage. Cela est particulièrement vrai au début et pour les plateformes, comme Android ou les conteneurs, qui vous mettent dans leur corset. Cela signifie que vous implémentez leurs interfaces et ils vous appellent.

De par ma propre expérience, la plupart du code ne vit pas très longtemps. Cela dit, allez vite en implémentant votre fonctionnalité. Quand tôt ou tard (la plupart du temps plus tôt), vous devez retravailler / reformuler votre code existant en raison de la fonctionnalité suivante que vous rangez, en particulier les parties avec lesquelles il est compliqué de travailler. Faites attention à avoir des tests automatisés appropriés pour permettre une refactorisation sans tracas possible. En ce qui concerne les plates-formes mentionnées ci-dessus, telles qu'Android: souvent, les tests automatisés ne sont pas aussi faciles en raison du couplage étroit et de l'absence de conception pour la testabilité. Ensuite, vous pouvez élever votre base de tests à un niveau supérieur, par exemple les tests d'intégration.

J'ai écrit un article qui pourrait donner des conseils sur le démarrage: https://medium.com/@ewaldbenes/start-lean-why-its-best-testsplit-your-next-coding-project-by-feature-70019290036d

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.