Lors de la création d'une application non triviale, est-il préférable de se concentrer sur la rapidité du travail et de prendre des raccourcis dans le code, comme mélanger la logique du modèle avec vos vues, briser l'encapsulation - les odeurs typiques du code? Ou préférez-vous prendre le temps nécessaire pour construire plus d'architecture, construisez-la correctement, mais courez le risque que tout ce code supplémentaire ne soit pas utilisé car votre conception est assez fluide et vous devrez peut-être la jeter à la poubelle aller dans une direction différente?

Pour le contexte, je construis une application de bureau. Je suis le seul développeur et je le fais à temps partiel depuis que j'ai un travail journalier. Maintenant, pour le travail, j'essaie de faire les choses comme il convient, dans les délais impartis. Mais pour ce projet, qui, je l’espère, se transformera à mesure que les gens me répondront, je ne suis pas sûr que ce soit la bonne approche. J'ai passé plusieurs heures cette semaine à mettre en place un manuel de conception de contrôleur de vue de modèle afin de communiquer les modifications apportées au modèle à la vue. C'est génial en général, mais je ne suis pas sûr d'avoir besoin de plusieurs vues pour afficher les données et je sais que les choses auraient pu être affichées plus rapidement sans l'architecture supplémentaire. Avec peut-être 10 à 15 heures par semaine à consacrer à ce projet, j’estime qu'il faudra beaucoup de temps pour obtenir quelque chose que je pourrai construire si je suis conforme aux bonnes pratiques en matière de logiciels. Je sais que mes utilisateurs ont gagné Peu importe que j’utilise MVC en interne, ils veulent juste quelque chose qui résout leur problème. Mais je me suis également trouvé dans une situation où vous avez contracté une telle dette technique à cause de raccourcis que le code est incroyablement difficile à maintenir et à ajouter de nouvelles fonctionnalités. J'aimerais entendre comment d'autres personnes abordent ce genre de problème.

Construis-le bien .

Construire "rapidement" est une erreur logique si vous regardez la grande image. Cela vous empêchera de l'avoir bien construit, et vous finirez par vous enliser sous des bugs et des défauts d'architecture fondamentaux qui empêchent la refactorisation ou même rendent l'ajout de nouvelles fonctionnalités presque impossible.

Bien le construire est en fait le contraire. Au début, le processus est peut-être plus lent, mais vous réaliserez un jour le gain d'efficacité obtenu après avoir pris le temps de faire les bons choix au départ. De plus, vous serez en mesure de vous adapter plus facilement aux exigences futures (refactorisation si nécessaire) et vous obtiendrez un meilleur produit final grâce au moins à la réduction du nombre de bugs.

En d’autres termes (sauf s’il s’agit d’un contrat unique), construisez-le vite = construisez-le lentement, construisez-le bien = construisez-le vite .

Aussi, il y a quelque chose d'important à réaliser sur le "bien construire" et la conception d'une architecture. Tu as demandé...

... mais vous courez le risque que tout ce code supplémentaire ne soit pas utilisé, car votre conception est assez fluide et vous devrez peut-être le jeter à la poubelle si les commentaires vous poussent à prendre une direction différente?

Ce n'est pas vraiment un risque réel de "passer du temps en architecture". La conception de l'architecture devrait être organique . Ne passez pas de temps à concevoir une architecture pour une partie tant que ce n’est pas justifié. L'architecture doit uniquement évoluer à partir de modèles observés et confirmés dans votre projet.

La loi de John Gall de Systemantics :

Un système complexe conçu à partir de zéro ne fonctionne jamais et ne peut pas être corrigé pour le faire fonctionner. Vous devez recommencer, en commençant par un système simple et fonctionnel.

Vite, alors bien

Ceci est de mon expérience personnelle après avoir essayé beaucoup de méthodes différentes.

Le problème avec seulement le travail rapide (et le relâchement) est généralement que vous ajouterez fonctionnalité après fonctionnalité sur votre application. Depuis sa publication, il est très difficile d’apporter des modifications fondamentales à votre programme. Vous payez un prix élevé à long terme pour rien ayant une architecture sous-jacente sonore, c'est comme construire un délabrement sur des sables mouvants.

Le programme avec de bons résultats est que vous allez perdre beaucoup de temps et de code. C'est comme construire un manoir sans aucun plan. L'écriture d'applications est un processus d'apprentissage et presque (selon mon expérience) impossible à concevoir à l'avance. Cela signifie que vous ferez beaucoup de refactoring, et si vous écrivez tout "bien" tout le temps, vous finirez par jeter beaucoup de code.

Donc vite vite!

Lorsque vous commencez, l’essentiel est de tout consigner dans le code afin de pouvoir définir toutes les fonctionnalités et de voir le type d’architecture à prendre en charge. Une autre bonne chose à propos de cette méthodologie est que je vais vous garder motivé car vous aurez rapidement quelque chose en cours d'exécution. Il est également important d'implémenter des fonctionnalités de "cas limite", car cela aura un impact sur votre architecture générale. Ne vous embêtez pas à écrire des tests unitaires ou à travailler sur les détails à ce stade. Si vous pensez que vous aurez besoin de prendre en charge plusieurs langues à l'avenir, une architecture de plug-in de toute autre chose, implémentez-la, mais rapide et sale. Refacturer pour que l'application reste gérable, mais rien de excessif.

Une fois que vous avez l’impression que vous avez un "prototype" opérationnel, il est temps de commencer la refactorisation. En gros, vous voulez refaire l’application comme vous le feriez si vous partiez de zéro en sachant tout ce que vous savez maintenant. L'important est de mettre l' architecture en place, de ne pas réimplémenter toutes les fonctionnalités que vous avez utilisées lors de la première phase, mais vous devez disposer de l'architecture en place pour la prendre en charge ultérieurement.

De cette façon, vous obtiendrez une application avec une architecture sonore aussi efficace que possible, selon mon expérience :)

Construit le

Rapide si le délai de commercialisation est plus important que la qualité

Eh bien, si la qualité est plus importante que le délai de commercialisation

Construire rapidement vous rapportera des avantages à court terme et des pertes à long terme.

Le construire correctement entraînera des pertes à court terme mais des avantages à long terme.

Construire bien demande de la patience et de la sagesse, mais vous serez récompensé.

Construire rapidement n'est utile que pour le prototypage rapide et les choses à jeter. Les objectifs à long terme ne peuvent être atteints qu'avec la bonne attitude dès le début.

Pour les projets que vous envisagez de distribuer pour que les autres les utilisent, je commettrais toujours une erreur en amont. Une architecture bien pensée est plus facile à étendre si nécessaire. Prendre des raccourcis n’est que le modèle d’accumulation de dette technique.

Cela peut parfois être frustrant et lent. Les choses qui valent la peine d'être faites méritent d'être faites correctement.

Bien construire = construire vite

Les raccourcis ont tendance à se retourner et à vous mordre encore plus vite que vous ne le pensez. Parfois même avant le déjeuner.

A propos de votre contexte ne pas résumer immédiatement. S'en tenir à YAGNI et éliminer les doublons. Implémentez ce modèle basé sur la vue lorsque vous avez réellement une deuxième vue, pas parce que vous pensez en avoir une dans le futur. Lorsque cette seconde vue arrive, l’abstraction que vous créez est généralement bien meilleure que celle que vous auriez créée autour de cette première occurrence.

Eh bien, si vous savez déjà ce que vous faites, vite si vous ne le savez pas

Je suis chercheur scientifique et j'écris beaucoup de code exploratoire avant d'avoir une idée de la situation dans son ensemble ou de l'évolution du projet. Dans ces cas, il est même difficile de voir comment "bien" devrait être défini. En outre, il est généralement difficile de voir tous les petits détails et les façons dont les choses pourraient être étendues au départ. Par conséquent, le vieil adage s'applique:

1. Fais-le fonctionner.
2. Fais-le bien. Bien faire les choses en second lieu présente l’avantage de pouvoir définir «bien» une fois que vous avez eu l’expérience de le faire fonctionner.

Construisez-le bien… toujours, mais donnez l'illusion d'aller vite

mais pour le rendre rapide, il suffit de le réduire. Construisez un petit sous-ensemble de l'ensemble suffisamment important pour obtenir un retour d'information. En y ajoutant progressivement à un rythme constant, vous obtiendrez le même avantage que de construire rapidement sans vendre votre âme à la réaction en chaîne des nuits sans sommeil qui jouent à des bobs.

Je pense qu'il devrait toujours être "bien construit". Si le temps de mise sur le marché est une préoccupation majeure, utilisez un processus de développement incrémental. Dans le pire des cas, vous avez un produit avec moins de fonctionnalités, mais au moins vous avez un produit de haute qualité à expédier qui peut être étendu dans les versions à venir.

Équilibre

Ce n'est pas pratique de concevoir votre code à la perfection ou de mélanger du code en un tournemain, n'est-ce pas? Il s’agit vraiment de trouver le bon équilibre. À mon avis, l’important est ce que vous faites quand.

Je pense que la chose la plus importante ici est d’assurer absolument que le noyau de l’application, la structure fondamentale, soit vraiment bien construit. Hermétique. Une fois cet objectif atteint, en fonction des contraintes de temps, si le temps vous manque, vous pouvez regrouper du code et le re-factoriser ultérieurement, et vous pouvez vous permettre ce luxe, car vous auriez eu soin de vous doter des fondations droit, et il ne serait pas mal de re-factoriser le code.

Faites la chose la plus simple qui puisse fonctionner. Dans votre cas particulier, votre programme ne deviendra pas très volumineux, vous serez la seule personne à y travailler à temps partiel. Je ne préconise pas les mauvaises manières comme les abus de goto, les noms de variables indescriptibles, etc., mais vous ne devriez pas le rendre plus complexe que cela doit être. Peut-être que MVC est juste un excès pour votre projet particulier.

ce qui, je l’espère, se transformera à mesure que les réactions

Vous avez dit le mieux vous-même:

Mais je me suis également trouvé dans une situation où vous avez contracté une telle dette technique en raison de raccourcis que le code est extrêmement difficile à maintenir et à ajouter de nouvelles fonctionnalités.

Si votre temps est compté, n'hésitez pas à demander plus de temps à votre employeur pour mener à bien le projet, en utilisant le même raisonnement. Je suis sûr qu'ils vont vous l'accorder. Cela dit, je comprends à quel point il est parfois frustrant de travailler si durement sur quelque chose et de ne pas pouvoir afficher un résultat aussi frustrant. Mais ne vous inquiétez pas, vous y arriverez, et bien le construire en vaudra la peine quand vous le ferez.

En général, j'aime bien construire la structure et gagner du temps en ne me souciant pas des détails spécifiques de la mise en œuvre. Comme tu le dis, ils vont changer quand même. L’idée derrière la construction d’une sous-structure bien faite est que les changements peuvent se produire très rapidement, une fois la base construite. J'essaie de rester aussi générique que possible dans mes cours et de les rendre réutilisables dans la mesure du possible. Je donne généralement à l'utilisateur une application bien construite qui ne satisfait que les exigences de base d'utilisabilité. Les utilisateurs ont toutes sortes d'idées une fois qu'un outil est entre leurs mains, il est donc inutile de penser trop loin.

Construis-le bien . Si vous n'avez pas le temps, réduisez le jeu de fonctionnalités.

Concevez-le aussi universel que possible. Par exemple, concevez une architecture de plugin, même si vous le savez, un seul plugin sera utilisé pour la première fois. Utilisez des schémas de configuration universels (configuration extensible, langage d'organisation), même s'il n'y a qu'un seul paramètre au début. C'est un très bon investissement , et vous ne pouvez le faire qu'au début du projet.

est-il préférable de s’attacher à faire en sorte que les choses fonctionnent rapidement et à utiliser des raccourcis dans le code, comme mélanger la logique du modèle avec vos vues, casser l’encapsulation - des odeurs typiques de code? Ou préférez-vous prendre le temps de construire plus d'architecture?

Dans mes oreilles, comme vous le dites, vous énumérez les deux extrêmes. Le premier choix, casser l’encapsulation, placer la logique du modèle dans les vues, c’est simplement une mauvaise programmation paresseuse. IMHO, résoudre ces problèmes n'est pas la même chose que de mettre plus d'architecture. Peut-être que si vous ne parlez pas de cela, c'est que le code de l'interface utilisateur exécute des instructions SQL. Mais ensuite, je ne dirais pas que construire plus d'architecture, alors je dirais que vous avez un manque total de conception et d'architecture et que vous devriez en avoir un.

En ce qui concerne l'architecture, je choisirais le plus simple, celui qui résoud le problème actuellement, puis je l'étendrais au fur et à mesure que les problèmes se poseraient.

Par exemple, si vous avez besoin de la fonctionnalité pour renvoyer des données d'une table de base de données unique, je ne m'inquiéterais pas des problèmes tels que le chargement des données à partir de tables associées, même si je savais que le problème se poserait éventuellement. Je commençais à m'en inquiéter lorsque je devais implémenter cette fonctionnalité.

Donc, pour mes propres projets de développement de la maison, j’adopterais l’approche suivante: Construisez la solution la plus simple possible pour résoudre le problème sur lequel je travaille actuellement, mais construisez-la bien. Je voudrais ensuite reformuler la solution car il faut plus de complexité. Suivre les pratiques de TDD sécurise la refactorisation et évite les odeurs de code (il est difficile de créer de bons tests unitaires si vous cassez l’encapsulation).

C'est d'ailleurs d'ailleurs l'approche que j'adopte lorsque je travaille de manière professionnelle. ;)

Je vous recommande de commencer par installer le logiciel, de couvrir tous les aspects et de commencer par le logiciel, puis de décorer et d'améliorer progressivement ses performances.

Vous voulez généralement être au milieu de ces deux bords:

Construisez-le bien = logiciel en temps réel essentiel à la vie dont dépend la vie des gens. logiciel de contrôle: réacteurs nucléaires, appareils de dialyse, appareils d' IRM , etc.

Construisez-le vite = logiciel inutile que personne n'utilise réellement.