Codage des Katas pour pratiquer la refactorisation du code hérité
Je me suis beaucoup intéressé au codage des katas ces derniers mois. Je crois qu'ils sont un excellent moyen de perfectionner mes compétences en programmation et d'améliorer la qualité du code que j'écris sur le tas.
Il existe de nombreux endroits où les Katas peuvent être trouvés. comme..
http://schuchert.wikispaces.com/Katas
J'ai trouvé que ce sont d'excellents référentiels de Katas ... mes tentatives pour certains d'entre eux ont été extrêmement enrichissantes.
Cependant, je pense que tous les Kata que j'ai vus jusqu'à présent ont un court à venir. Aucun d'entre eux ne semble me permettre de pratiquer la refactorisation de mauvais code. C'est génial d'apprendre à écrire du code propre la première fois ... mais dans mon travail actuel, je n'ai pas trop d'occasions d'écrire du nouveau code. Au contraire, je me bats souvent contre le code hérité et j'essaie de comprendre comment refactoriser les modules, éliminer les dépendances et réduire le couplage.
En tant que tel, je suis à la recherche de quelques Katas que je peux utiliser pour affiner mes compétences de refactorisation du code hérité et de le transformer en code propre.
Quelqu'un en connaît-il déjà un? Je sais que je m'entraîne beaucoup pendant que je suis au travail ... mais j'aimerais affiner mes compétences au point où je suis en mesure de voir rapidement comment briser les dépendances et séparer les préoccupations dans les classes qui en faire trop.
Je ne connais pas de site qui les catalogue directement, mais une stratégie que j'ai utilisée à l'occasion est la suivante:
- Trouvez un ancien, petit projet open source non entretenu sur sourceforge
- Téléchargez-le, faites-le compiler/construire/exécuter
- Lisez la documentation, découvrez le code
- Utilisez les techniques de Travailler efficacement avec le code hérité pour en tester un morceau
- Refactorisez cette pièce, peut-être en corrigeant des bugs et en ajoutant des fonctionnalités en cours de route
- Répétez les étapes 4 à 6
Lorsque vous trouvez une partie particulièrement difficile, jetez votre travail et répétez-le plusieurs fois pour renforcer vos compétences.
Cela ne se limite pas à la refactorisation, mais à d'autres compétences telles que la lecture de code, les tests et la gestion des processus de génération.
Le problème le plus difficile est de trouver un projet qui vous intéresse suffisamment pour continuer à travailler. Le dernier sur lequel j'ai travaillé était une bibliothèque python pour la programmation génétique, et celle sur laquelle je travaille actuellement) on est une bibliothèque IRC pour Java.
Emily Bache a un dépôt github avec quelques katas de refactoring: Repo de refactoring d'Emily Bache . Il existe des variantes de KataYahtzee et KataTennis à refactoriser. En outre, elle a une variante du Kata Rose doré, qui a été conçu comme un kata de refactorisation.
En outre, elle a les Katas Racing Car dans son repo: Racing Car Kata . Les Race Car Katas incluent également de bons exercices de refactoring.
Ces kata ont le code dans plusieurs langages:
- C++
- C #
- Java
- Javascript
- Python
- Ruby
Je me sens comme un nécromancien répondant à un tel vieux fil, mais il y a une chose qui ferait un ajout digne - Legacy Code Retreat .
L'idée est d'avoir un Code Retreat avec le code hérité et d'essayer de pratiquer les techniques mêmes pour y faire face, mais je ne vois rien qui vous interdirait d'utiliser simplement le code préparé et de pratiquer avec lui par toi-même. Le simple fait de l'utiliser pour créer un Golden Master représente une heure de travail, et vous pouvez faire beaucoup plus. Si votre kata dure généralement environ 2 heures, je dirais simplement qu'en divisant ce qui se passe habituellement sur LCR en kata, vous avez quatre choses différentes à travailler.
Il y a un référentiel GitHub de l'auteur de l'idée, J.B. Rainsberger, qui contient un système hérité simple avec lequel vous devez travailler, Trivia Game.
D'après mon expérience en tant qu'organisateur/participant, les gens ont vraiment aimé cela et c'était éclairant de voir ce qui peut être un problème dans un code hérité et où votre refactoring peut vous induire en erreur (et comment!). Voici encore un autre compte rendu à quoi cela ressemble, par Andreas Leidig .