This is a lecture memo of the special lecture on multi-scale simulation. The index of lecture memos is here
This article is a learning record of learning refactoring in line with "Refactoring: Ruby Edition" (ASCII Media Works, 2010) by Jay Fields, Shane Harvey, Martin Fowler and Takahiro Nagao. Lecture materials and codes cannot be published, so please refer to the relevant folder on github.
It was often introduced in the lecture, but what is ** refactoring **? Check again.
Factoring has the meaning of factoring, but dividing a program into classes and methods can be said to be factoring in programming. When re- is attached, it becomes an image of looking back and returning. To put it simply, refactoring is an image of reviewing the completed program and reassembling the structure of the program.
Strictly speaking, refactoring is
reassembling the internal structure of a program without changing the behavior seen from the outside. Make the contents beautiful without changing the appearance. Humans should be the same.
This time, I worked on refactoring: Ruby edition TSUTAYA Project (official name is unknown, Chapter 1 pp.25 ~ pp.74). It is a program that calculates and outputs video rental fees, and various elements are divided into multiple classes.
There are three program files to be edited: movie.rb, rental.rb, and customer.rb. Each program has a class similar to the program name defined.
--Movie class: A class that represents work data (fee, etc.) --Rental class: A class that represents rental information (new works, children's fees, etc.) --Customer class: A class that represents customer information (name and rental work)
It is configured as follows.
There is no particular problem in executing the first program, but there seems to be a problem in how to write programming. Since the role of refactoring is to modify redundant parts without changing the behavior, we will refactor immediately.
The procedure is to fix the redundant parts one by one and test them. When modifying a program, do not modify it all at once, but try to fix it little by little and test it even if only one variable is changed.
What is mentioned as a point to be corrected
--Long methods are split for each action. --Each method is defined under an appropriate class. --Write an easy-to-understand description so that it can be easily changed
Refactor these points.
** Creating a test set ** is emphasized as the first step in refactoring. By creating a test set and making it clear whether the expected output and the resulting output match, whether there is an assert, and what kind of error it is, the work efficiency for bugs will be improved. Is assert \ _equal in the lecture tied here?
This time, I worked on refactoring using a test set called rspec.
I can't explain the program later, so I will describe the impressions I felt when I worked on refactoring.
It took almost 3 hours to complete the refactoring of the TSUTAYA Project. Even a simple calculation takes about 1 hour per program. This time he was refactoring three programs, but since he will proceed while considering the correlation between each program, it will take time exponentially as the number of files increases.
This feeling of refactoring I thought I had tasted it somewhere, but it was the feeling when I was writing a Rails application. The idea is that it is better to go back and forth between multiple files and make this variable an instance variable, or move this function to another class.
Personally, I'm not good at refactoring, or rather it's not suitable. I'm tired of it, so I don't want to stare at the same programming. If you want to add a function, you want to follow the previous program and recreate it from scratch, and make it more beautiful. It is the real intention that even this task is exhausted from the point of view that it moves only by instantaneous power and has no endurance.
However, I am glad that I had the opportunity to learn about refactoring again. What is better code and what is more beautiful code? I feel like I have found my own answer.