** 1. About program improvement **
Program development is a very complicated act, and we proceed through trial and error. There are various ways to do this, such as opening a review to find out where to improve, whether to proceed with development as it is, etc. I will check with the customer and proceed.
Also, because the deadline and deadline are approaching, I dare to write "unfavorable but easy writing". You may have to make a choice.
So, ** If you leave it unconscious, the program under development will become more and more complicated. ** ** When I look at it later, I can't help but wonder, "Why did you write such a confusing code?" Even skilled engineers are not uncommon. An example is that you can copy and paste similar classes and it will be difficult to modify them later.
However, the more complex the code, the harder it is to fix. The more complex the program, the lighter it is at first, but over time it becomes more and more like a snowman. It adds complexity and eventually becomes untouchable. → It would be difficult for companies to hire talented engineers just for that purpose.
Therefore, an activity called ** refactoring ** is recommended to review and improve the code from time to time.
Complex programs ...
・ The code is messed up and I don't understand ・ It becomes difficult to understand when viewed by anyone other than the creator and designer. ・ It may be different from the processing design.
・ It is easier to see because only the code is left. ・ It is easy for people from other teams and people other than creators and designers to enter the content. ・ Completed according to the design
** 2. What is refactoring **
Strictly speaking, refactoring means "** improving the internal structure without changing the behavior and specifications seen from the outside **". I will.
For example, if you refactor the test class, it will have a big impact on another class that calls the test class. We will not make any modifications (such as changes that make the method operation completely different).
The word refactoring refers to activities rather than special writing.
Before the concept of refactoring was born, programs that were created and worked normally once The idea that it is better not to touch it was pervasive. Because when you fix a bug and a bug appears, the fix work spreads throughout the project and it becomes difficult to collect Because there is a possibility.
However, it is a daily occurrence that specifications and requirements change in program development. As a result, refactoring activities have gradually expanded.
** 3. Typical refactoring activities **
The following are typical refactorings.
① ** Collect overlapping parts in one place ** If similar code parts appear in multiple places for reasons such as copying, You can call it all in one method.
② ** Divide methods and classes ** Cut out a part of the method that has become too large and complicated as a separate method. Usually, it will be cut out as a private method.
③ ** Use external libraries and new Java version grammar ** Processing written using a large number of lines can also be done by using a new external library or new grammar. It can be simple. Of course, use only the libraries that you can use.
** 4. Precautions / Disadvantages of Refactoring **
Basically, refactoring is a "good thing" that you should do more and more. However, refactoring also takes time (= cost). So if you're unlikely to outweigh the costs, In some cases, "even code that is not maintainable should not be refactored."
** Notes ① It is difficult to obtain the benefits of refactoring just before the delivery date **
Even if you refactor in a situation where the deadline is approaching, the product will be released immediately after that Once completed, you cannot take advantage of the "easy modification". This doesn't seem to be very good for the author who wants to make it perfect before releasing it. → I think it's better to do it ...
In short, there are many cases where it is better to properly perform verification work such as testing when the delivery date is close. ** Caution ② Don't do it unnecessarily, don't overdo it **
Like testing, refactoring activities are endless and endless. Also, a few months later, I'll look at the design that I thought about until it seemed perfect at the time of refactoring. It may not be optimal.
Time isn't infinite, so refactor it appropriately so you don't waste money and effort. It's important to do it.
Recommended Posts