Comment aborder la refactorisation d'une application web existante?

J'ai beaucoup lu et réfléchi récemment, et je suis arrivé à la conclusion que je devrais peut-être repenser ma stratégie de développement Web. Je fais beaucoup de programmation à la volée, et depuis 2 ans que je travaille sur une application web PHP, ce qui aurait pu commencer comme un petit outil est devenu un gros projet. Mais il y a une tonne de code hérité de moi et de mon prédécesseur, un extrait de code qui aurait peut-être du sens à l'époque, mais maintenant je remets en question l'utilité de ce code sous sa forme actuelle. De plus, des choses comme les tests unitaires et le développement piloté par les tests n'étaient pas de mon ressort jusqu'à tout récemment.

Comment aborderiez-vous la refactorisation de l'application Web? Quelles seraient les choses que je devrais rechercher et dans quel ordre? Qu'en est-il du jeu par navigateur et de l'application Web fonctionnelle? Y aurait-il alors une différence d'approche?

À peu près de la même manière que vous approchez de tout type de code hérité. Vous trouvez une pièce qui peut être testée, vous écrivez des tests pour elle, et refactorisez.

Si vous ne trouvez pas un morceau facilement testable, vous devrez le rendre testable sans le harnais de sécurité d'une suite de tests, auquel cas vous changez très soigneusement un morceau de code presque testable afin qu'il soit testable.

Le code qui ne rend pas les choses au navigateur - code "infrastructure", modèles, éléments touchant à la base de données - pourrait être un bon point de départ.

Edit: UI testing: Avec l'avertissement que j'ai peu d'expérience ici, un de mes amis fait ceci: il exécute un morceau de code générateur de HTML. Ensuite, il pirate son code et compare le code nouvellement généré à l'ancienne version (en utilisant diff; il n'a pas automatisé complètement). Les changements dans le HTML signifient que votre refactoring s'est cassé.

Il y a un grand livre à ce sujet intitulé "Travailler efficacement avec Legacy Code" par Michael Feathers. Avouons-le, nous avons tous un code hérité.

L'essentiel est de tester le nouveau code que vous créez. Comme vous devez toucher d'autres morceaux de code, vous trouverez également des opportunités pour les tester. C'est un processus long et lent, mais si vous le faites systématiquement, vous pouvez vraiment améliorer le produit global au fil du temps.

• Oui - les applications Web sont différentes des sites Web

Je les traiterais séparément. Si vous avez une partie de votre site qui est simplement une collection de documents (qui ressemblent aux utilisateurs anonymes et aux utilisateurs connectés) - alors la meilleure méthode de structuration est très différente d'une application Web qui sert des pages dynamiquement différentes à chaque utilisateur. Divisez ces deux parties du site en deux applications / composants et abordez chaque partie différemment.

• Commencer à utiliser le contrôle de version

Une fois que votre code est sous contrôle de version, vous pouvez parcourir et, en toute confiance, supprimer tout le code inutile que vous aviez précédemment conservé `` au cas où '', etc. Je ne sais pas comment j'ai survécu sans contrôle de version.

• Réduisez les infinis

Si quatre URL différentes pointent toutes vers la même ressource, le problème est bien plus important. Vous finissez par traiter une quantité infinie d'URL. Dès que vous le pouvez, assurez-vous que vous disposez d'une stratégie de normalisation des URL. Une fois cela fait, vous pouvez commencer à attacher des significations sémantiques aux URL et pouvoir effectuer des recherches inversées de la ressource vers l'URL. Cela vous permet de séparer «l'empreinte Web» des «ressources» du site.

Vous devez vous demander, "étant donné une URL, quelle est sa forme normalisée?". Une fois que vous l'avez épinglé. Ensuite, 50 000+ URL sur votre site peuvent être réduites, soit 2 000. ce qui est beaucoup plus facile à comprendre et à gérer dans votre esprit.

voir: http://www.sugarrae.com/be-a-normalizer-a-c14n-exterminator/

• Commencez par modéliser «ce qui est», pas «ce que vous voulez que ce soit»

Si vous ranger un site hérité, qui n'a pas été conçu avec les meilleures pratiques à l'esprit dès le départ, alors il est tentant de passer de `` désordre '' à `` la conception idéale ''. Je crois que vous devez le faire en au moins deux étapes: «mess» -> «code hérité bien modélisé» -> «nouveau code idéal avec des fonctionnalités supplémentaires». Arrêtez d'ajouter des fonctionnalités. Concentrez-vous sur la réparation du désordre ou l'encapsulation derrière une couche anti-corruption. Alors seulement, vous pourrez commencer à changer le design en quelque chose de mieux.

Voir: http://www.joelonsoftware.com/articles/fog0000000069.html

Voir: http://www.laputan.org/mud/

• La tester est une bonne idée.

Créez une suite / infrastructure de test et commencez à ajouter des tests. Mais, il est assez difficile de tester un code hérité. Alors, ne vous y attardez pas trop. Tant que vous disposez du framework, vous pouvez ajouter des tests petit à petit.

Voir: http://www.simpletest.org/en/web_tester_documentation.html

• Ayez du courage dans vos convictions

La plupart des publications sur les meilleures pratiques de développement de logiciels sont centrées sur les ordinateurs de bureau / entreprises. Pendant que votre site est en désordre, vous lisez ces livres et vous pouvez être impressionné par la sagesse qui s'en dégage. Mais n'oubliez pas que la plupart de ces meilleures pratiques ont été accumulées bien avant que le Web / SEO ne devienne important. Vous en savez beaucoup sur le Web moderne, plus que ce qui est mentionné dans les livres classiques comme POEA, Gof etc. Il y a beaucoup à tirer d'eux, mais ne jetez pas complètement votre propre expérience et vos connaissances.

Je pourrais continuer. Mais ce sont des choses que j'ai choisies lors de la refonte d'un ancien site hérité en un nouveau brillant.

Avant de faire quoi que ce soit, il est préférable d'avoir votre projet en contrôle de code source. De cette façon, vous pouvez annuler des modifications ou travailler sur des modifications majeures sur une branche distincte, ainsi que sur des jalons de balises.

Ensuite, écrivez des tests pour tout code que vous prévoyez de modifier. Vous n'avez pas besoin de tout faire en même temps, d'écrire des tests pour tout. Exactement ce sur quoi vous prévoyez de travailler immédiatement. La théorie veut que, avec suffisamment de temps, la majeure partie de la base de code sera couverte par des tests. Notez que certains refactorings sont «sûrs» de se passer de tests - ceux-ci sont documentés dans le livre Legacy Code mentionné précédemment, et sans doute ailleurs.

Avec des tests en place pour une section de code, modifiez le code. Faites tout ce que vous devez, tant que les tests réussissent.

Même avec le code hérité, vous pouvez effectuer TDD si vous effectuez des ajouts ou des modifications. Écrivez d'abord des tests pour vos modifications anticipées, voyez-les échouer, puis effectuez les modifications.

Certains outils peuvent être utiles ici. NDepend peut signaler du code fortement couplé et d'autres odeurs. NCover suit vos niveaux de couverture de code. FxCop est essentiellement un vérificateur d'exactitude de code, au-delà de ce que fait le compilateur. Ce sont tous des outils utiles à avoir à portée de main pour un projet de toute taille réelle, en particulier la variété héritée.

En fin de compte, c'est un processus en plusieurs étapes. N'essayez pas de tout faire en même temps, prenez-le un peu à la fois.

Si c'est assez moche pour me faire chier, c'est assez moche pour moi de supprimer le tout et d'écrire une goutte en remplacement.

Vous constaterez que plus souvent qu'autrement, cela prend le même temps que de le faire, de rester assis là et de garder la pointe des pieds autour d'un gâchis non organisé et sans papiers et de le caresser doucement.