Refactoriser ou se concentrer sur l'exécution de l'application

Souhaitez-vous refactoriser votre application au fur et à mesure ou vous concentrer sur la réalisation de l'application en premier? La refactorisation entraînera un ralentissement de la progression de l'application.

La fin de l'application signifie que vous aurez plus tard une application très difficile à maintenir?

L'application est un projet personnel. Je ne sais pas vraiment comment répondre à "Qu'est-ce qui motive la fonctionnalité et la conception", mais je suppose que c'est pour résoudre les inefficacités des logiciels actuels. J'aime aussi le logiciel minimal facile à utiliser. Je supprime donc certaines fonctionnalités et j'ajoute certaines qui, selon moi, seront utiles.

Fais-le fonctionner. Faites vite. Enfin, rendez-le beau.

Si vous avez une bonne séparation entre votre code (présentation, entreprise et couches de données) à l'aide d'interfaces, et que ce n'est pas une conception monolithique, le refactoring ne devrait pas être si difficile.

Si vous avez beaucoup de difficulté à refactoriser, c'est probablement une odeur de code - je vous suggère de regarder des principes solides

Je pense que l'essentiel est de garder les interfaces propres . Vous pouvez toujours refactoriser ou même réécrire le module / classe / quelles que soient les implémentations ultérieurement, tant que les couches de communication entre elles sont saines. Passez un peu de temps à découvrir ce qui est facile à changer plus tard et ce qui ne l'est pas. Faites ce dernier droit.

Cela est conforme à l'esprit de TDD. Pour écrire de bons tests, vous avez besoin d'une bonne interface pour effectuer des tests. Le fait qu'il soit désordonné en coulisses en ce moment n'est pas si important, car vous pouvez l'améliorer plus tard.

Je refaçonne toujours au fur et à mesure, surtout en utilisant TDD.

1. Écrivez les tests

2. Faire passer les tests

3. Refactor

Cela vous aidera à avoir moins de bogues et un meilleur code pour le produit fini. Cela vous permettra également d'avoir moins de code à conserver lorsque vous aurez terminé.

Refactorisez tôt et souvent! Le temps que vous "économisez" pour ne pas le faire est passé plusieurs fois à essayer de pirater la fonctionnalité suivante et à rechercher des bogues dans un code trop complexe ou chaotique.

Le refactoring, c'est comme récupérer votre chambre.

Si vous gardez les choses en ordre, vous avez une surcharge linéaire, proportionnelle à la quantité de travail productif que vous faites sur le code, O (n) en termes algorithmiques. En supposant que vous passez 10% de votre temps à refactoriser (ou à garder votre chambre bien rangée), que 10% est une donnée, et cela restera constant au fil du temps.

Si, cependant, vous jetez vos vêtements sales dans un coin et continuez à le faire, le temps que vous allez passer à ramasser votre chambre augmente à mesure que le désordre devient plus complexe. En supposant que chaque pièce de linge sale contribue de façon exponentielle au temps de nettoyage requis, vous êtes maintenant dans une situation O (e ⁿ ).

Quiconque a déjà exploré le concept de complexité algorithmique observera qu'il y a un seuil de rentabilité quelque part, c'est-à-dire qu'il y a une quantité optimale de linge sale à accumuler; combien cela dépend des facteurs constants qui sont rejetés dans la notation big-O. Un autre facteur est la valeur de votre travail au fil du temps: si votre travail vaut beaucoup maintenant, mais pas cher la semaine prochaine (c'est-à-dire qu'il y a une date limite ce vendredi pour ce projet et trois autres, mais après cela, vous serez surtout inactif ), l'équation pourrait se révéler favorable à la non-refactorisation.

Et puis il y a la complexité de la masse critique. À un moment donné, le gâchis (`` gâchis critique '', si vous voulez) devient si grave qu'il semble plus facile de simplement brûler toute la pièce et d'acheter de nouveaux vêtements. En réalité, ce n'est généralement pas le cas, mais cela semble ainsi, et les effets psychologiques rendront dix fois plus difficile de s'attaquer à la chose.

Et évidemment, si vous entrez déjà dans un projet qui est déjà un gâchis multiplicateur redondant, vous avez un choix limité.

TL; DR: En cas de doute, refactorisez. Vous devriez avoir de très bonnes preuves avant de décider de ne pas le faire.

Si vous avez la possibilité d'ajouter des fonctionnalités ou d'écraser des bugs pour obtenir la satisfaction de vos ventes / clients là où vous pensez qu'elle devrait être, faites-le. Une fois qu'il y a moins de nouvelles demandes, vous pouvez équilibrer la refactorisation. À un moment donné, vous devez vous assurer que vous écrivez le code que les gens veulent. Toutes choses étant égales par ailleurs, je préfère jeter 100 heures de code plutôt que 1000. C'est ce que vous ferez si personne ne le veut.

Cela dépend vraiment de l'endroit où vous en êtes!

Autres choses à penser:

Dans quelle mesure êtes-vous certain, vous avez vraiment le bon design fonctionnel? Pourriez-vous finir par reconcevoir après avoir reçu des commentaires des utilisateurs?

Je préfère libérer plutôt que réécrire. Optimisez une fois que vous êtes sûr d'avoir cloué la conception fonctionnelle.

Tant que vous êtes sûr que vous pouvez respecter la date limite, vous pouvez refaçonner tout ce que vous voulez. Cependant, même s'il y a un peu d'incertitude, il vaut mieux s'en tenir au développement et ne peut être refactorisé que par étapes incrémentielles modestes.

Si le mauvais design que vous souhaitez refactoriser vous fait vraiment mal, vous feriez mieux de le réparer maintenant que de créer plus de code qui en dépend. Une refactorisation plus tard serait plus difficile et plus coûteuse; il est probable que vous ne pourrez plus le faire.

D'un autre côté, si votre seul problème est la laideur, vous voudrez peut-être d'abord terminer votre logiciel, car presque rien ne vaut la peine de faire avancer les choses .

La refactorisation sera très importante lorsque vous travaillerez à compléter votre demande.

+ VES

1. Effacer le flux: la refactorisation donnera la clarté du code parce que parfois, si le code est peu structuré, comprendre le flux du code après une période de temps deviendrait difficile et le code de refactorisation pourrait devenir une tâche difficile et des bugs pourraient être introduits.

2. Améliorer les performances: une refactorisation correcte de l'application contribuera certainement à améliorer les performances de l'application.

3. Entretien: Dernier point mais non le moindre, il serait plus facile à entretenir à long terme.

-VE

1. Consommation de temps: cela prendrait beaucoup plus de temps à chaque étape de votre progression. Il pourrait donc y avoir un retard dans l'achèvement.

Bottom Line

Selon le type de projet, vous pouvez prioriser la qualité du code ou son achèvement, selon ce qui est exigeant pour la situation actuelle.

Sur la base de mon expérience personnelle, j'allais généralement terminer les applications en premier à condition qu'il y ait un délai à atteindre. une fois que vous avez terminé, vous pouvez le refactoriser.

Terminez-le et refactorisez-le. Mais s'il n'y a pas de date limite pour se précipiter ou de délai, je suggère que la refactorisation soit bonne.