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.

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.

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.

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.)

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.

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.

É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.

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.

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.

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.

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