When is the time to reorganize the code?

Question

At hand:
1. You will never have time for this.
2. “Contextual switching” is mentally expensive (it’s hard to leave what you are doing in the middle of it).
3. This is usually not an easy task.
4. There is always fear that you will break what is working now.

On the other hand:
1. The use of this code is error prone.
2. Over time, you will realize that if you first processed the code the first time you updated the code, it would save you in the long run.

So my question is - Practically - When do you decide the time to reorganize your code?

Thanks.

Answer 1

One of the most common mistakes that I see is people connecting the word "Refactor" with "Big Change".

Refactoring code does not always have to be big. Even small changes, such as changing the bool to the correct enumeration or renaming the method to be closer to the actual function against the intent, are refactoring your code. With the exception of the end of the milestone, I try to do at least a very small refactoring every time I sign up. And you would be amazed at how quickly this makes a noticeable difference in code.

Big changes, however, require more planning. I try and plan about 1/2 times every two weeks during the normal development cycle to address a larger change in refactoring. This is enough to significantly improve the code base. If refactoring does not end 1/2 a day, this is not a big loss. And this is rarely a complete loss, because even unsuccessful refactoring will teach you something about your code.

Answer 2

A few observations:

At hand: 1. You never had time for this.

If you regard re-factorization as something separate from coding (rather than decently inside the coding), and if you cannot manage the time, then yes, you will never have time for that.

• Context switching is mentally expensive (it's hard to leave what you are doing in the middle).

See the previous paragraph above. Refactoring is an active component of good coding practice. If you separate them as if they were two different tasks, then 1) your coding methods need improvement / maturation, and 2) you will encounter a serious context switch if your code is in urgent need of refactoring (again, quality code.)

• This is usually not an easy task.

Only if the code you produce is not refactored. That is, code that is difficult to refactor shows one or more of the following (the list is not generally accepted):

• High cyclic complexity
• No separate responsibility for the class (or procedure),
• High adhesion and / or poor low cohesion (also known as LCOM indicators)
• poor structure
• Does not follow SOLID principles.
• Do not obey the Law of Demeter when necessary.
• Excessive observance of the Law of Demeter when it is unacceptable.
• Programming versus implementations instead of interfaces.

• There is always fear that you will break what is working now.

Testing? Check? Analysis? Any of them before being checked in the initial control (and, of course, before being delivered to users)?

On the other hand: 1. The use of this code is error prone.

Only if it has never been tested / verified and / or if there is no clear understanding of the conditions and patterns of use under which a valid error code works acceptable.

• Over time, you will realize that if you reorganized the code the first time you saw it, it would save you time in the long run.

This awareness should not occur over time. Good engineering and work ethics require such an implementation when an artifact (whether hardware or software) is under development.

So my question is - Practically - When do you decide the time to reorganize your code?

Practically when I code; I find an area that needs improvement (or something that needs to be fixed after changing requirements or expectations); and I get the opportunity to improve it without sacrificing a deadline. If I cannot repeat the factor at this point, I simply document the perceived defect and create a workable, realistic plan to review the artifact for refactoring.

In real life, there will be times when we will encode some ugly clod just so that everything is in order, or because we are exhausted, tired, or something else. This is reality. Our task is to make sure that these incidents do not accumulate and remain unattended. And the key to this is refactoring, because you code, keep the code simple and with a nice, simple and elegant structure. And “elegant” I don't mean smart ass or esotericism, but it displays what are usually considered readable, simple, compound attributes (and mathematical attributes when they are applied in practice).

Good code can be refactored; It displays good performance; its structure is similar to the composition of computer science and the mathematical structure of functions ; he has a clear responsibility; he makes his invariants, before and afterwords obvious; etc. etc.

Hope this helps.

Answer 3

• Whenever it smells , I'm refactoring. I cannot make it perfect now, but I can at least take a small step towards a better condition. And these small changes evolve over time ...
• If I am in the middle of something when I notice a smell, and correcting it is not trivial (or I just before release), I can make a (mental or paper) note to return to it when I am finished with the main task.
• Practice does one thing better :-) But if I don’t see a solution to the problem, I put it aside and gave it a brew for a while, discuss it with my colleagues or even publish it on SO; )
• If I don't have unit tests and the fix is ​​not trivial, I start with the tests. If the tests are not trivial, I apply clause 2.

Answer 4

I start refactoring as soon as I find myself repeating my self. Dry ftw principles.

Also, if the methods / functions get too long, to the extent that they look bulky or their purpose is hidden along the length of the function, I break it down into private subfunctions that explain what is actually happening.

Finally, if everything is up and running and the code is slower, I start looking at refactoring for performance.

Answer 5

Refactoring code when it needs refactoring. Some symptoms I'm looking for:

• duplicate code in similar objects.
• duplicate code inside the methods of one object.
• at any time when requirements have changed twice or more.
• At any time, someone says, "We will clean it later."
• anytime when I read the code and shake my head, thinking “what did it” (even if it is a question that it was a question).

In general, less constructive and / or less clear requirements mean more room for refactoring.

Answer 6

When implementing a new function, I often notice that the task will be much simpler if the code I'm working on has been structured differently. In this case, I usually backtrack, first try to refactor, and only after that I continue to implement the new function.

I also have the habit of tracking all potential improvements that come to my mind either in notes or in bug tracking. Ideas will be baked there for some time, some of them no longer feel so irresistible, and rational ones are realized during the day, which I devote to smaller tasks.

Answer 7

It may sound like a joke, but in fact, I'm only refactoring when things "get dirty." When a simple task starts to take longer and usually when I have to twist my mind to remember which function does something and what. In addition, if the code starts to work slowly, and this is not because I work in a development environment (many variable outputs, etc.), if I can’t optimize it, I will reorganize the code. As you said, it was long.

However, I always make sure that I have enough time to think through everything before I start, so I do not get into this message.

Hooray!

Answer 8

I usually reorganize when one of the following statements is true:

• I have nothing to do and wait for the next project to get into my inbox
• The additions / changes that I make to the code cannot work if it is not, or it would be better if I refactored
• I am aesthetically dissatisfied with the way the code is laid out.

Answer 9

Martin Fowler in his book , if the same name invites you to do this the third time, when you are in a code block to make another change, The first time in the block you noticed that you should reorganize, but you do not have time. A second time ago ... the same thing. The third time ago - now refactoring. In addition, I read the developers of the current version of smalltalk (squeak.org, I think), they say that they go through a couple of weeks of intensive coding ... then they back down and see what can be reorganized. Personally, I have to resist the impulse to the refactor when I am coding, or I am "paralyzed."