J'écris habituellement Rails, mais je me demandais si le refactoring devait être fait.
J'ai remarqué beaucoup de choses en lisant «Refactoring: Ruby Edition», alors voici un résumé.
C'est trivial, mais je vais l'oublier, alors je vais l'écrire.
Organiser la structure interne du code source sans changer le comportement vu de l'extérieur du programme.
[wiki: Refactoring 2020/11/15](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3% 82% BF% E3% 83% AA% E3% 83% B3% E3% 82% B0_ (% E3% 83% 97% E3% 83% AD% E3% 82% B0% E3% 83% A9% E3% 83 % 9F% E3% 83% B3% E3% 82% B0))
On dit souvent que le refactoring se fait toujours en cours de développement, mais quand le ferez-vous concrètement? Je n'ai pas vraiment compris.
Tout d'abord, envisagez de modifier le code existant et d'ajouter des fonctions à titre d'exemple.
Lors de l'implémentation de ce qui précède, j'ai pensé que je refactoriserais avec le sentiment de implémentation → code de test → refactoring.
Lorsque vous ajoutez réellement des fonctionnalités, vous commencez par comprendre le code existant.
La refactorisation comprend également la facilitation de la lecture du code, la refactorisation peut donc être le bon choix lors de la première compréhension du code existant.
Par conséquent, je pense qu'il est préférable de l'implémenter dans le flux de Comprendre le code existant → Refactoring → Implémentation → Code de test → Refactoring.
De cette façon, le premier refactoring rendra le code plus facile à comprendre, et à ce stade, une Pull Request aidera les autres développeurs à le comprendre.
Si vous avez du code de test, je pense que le premier refactoring fonctionnera, et si vous n'avez pas de tests, je pense que vous devriez l'écrire à ce moment-là, y compris comprendre le code.
Lors du refactoring, il semble bon de le faire au moment suivant.
Comprendre le code existant → Refactoring → Implémentation → Code de test → Refactoring
Recommended Posts