I usually write Rails, but I was wondering if refactoring should be done.
I've noticed a lot while reading Refactoring: Ruby Edition, so here's a summary.
It's trivial, but I'll forget it, so I'll write it down.
Organize the internal structure of the source code without changing the behavior seen from the outside of the program.
[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))
It is often said that refactoring is always done while developing, but when will you do it concretely? I didn't really understand.
First, consider modifying the existing code and adding functions as an example.
When implementing the above, I thought that refactoring would be done like implementation → test code → refactoring.
When you actually add functionality, you start by understanding the existing code.
Refactoring also includes making the code easier to read, so refactoring may be the right choice when you first understand your existing code.
Therefore, I think it is better to implement in the flow of Understanding existing code → Refactoring → Implementation → Test code → Refactoring.
This way, the first refactoring will make the code easier to understand, and at this point a Pull Request will help other developers understand it.
If you have test code, I think the first refactoring will work, and if you don't have tests, I think you should write it at that time, including understanding the code.
When doing refactoring, it seems good to do it at the following timing.
Understanding existing code → Refactoring → Implementation → Test code → Refactoring
Recommended Posts