Reconstructing the large layout of serial and the small step run

In the past, when we redesigned a system, we always liked the big layout. Comprehensive system requirements, comprehensive analysis of system functions, and then comprehensively design the system, development, testing. Such a process often lasts months and takes a lot of work. However, not until the final design, no one knows whether there will be problems. This is the "big layout" of the ills.

Because of this, software gurus always emphasize that system refactoring should avoid large design, but should use a continuous small design as far as possible when describing system refactoring. This is what we call the "small step fast" design pattern.

The small step running reflects the characteristics of agile software development-simple and fast feedback. Do not think too much, live in today's lattice, because you can never predict what will happen in the future. So, do today's design, solve today's problems, complete today's reconstruction, let's go to hell tomorrow. You know, how important simplicity is to us. When our brains begin to think about complex problems, they start to get bloodshot, and then they're sleepwalking, and the end result is a trade-off. In that case, why do we not choose a simpler way of life?

Unfortunately, many times we can not choose this simple way of life, because we are afraid of tomorrow, fear tomorrow will appear those we can not handle the business scene, so we began to excessive design. I am not criticizing that we should not foresee, predictive design and excessive design are often a line of separation. Limited foresight is possible, but don't think too far. When tomorrow really needs to change, we are not satisfied with the design, how to do? It's no big deal, because we have refactoring. Refactor our system to meet that requirement and then add code to achieve new requirements through a secure and smooth refactoring approach. This process is called "Two hats": one is refactoring without new features, and one is to add new features to achieve new requirements. Because of this, we can think about the moment when designing.

Another problem is timely feedback, the implementation of this is timely testing. Only the test passed, this refactoring is successful, we can continue to refactor, otherwise we must restore. It is not hard to see from here how important the cycle of refactoring is. In my previous refactoring work, the cycle of one refactoring was 10 minutes to 1 hours. The longer the cycle of refactoring, the more complex the problem you are considering, and the greater the probability of a final error. Therefore, we must get used to the "small run" of the way of working, let oneself only live in the present.

Having said so many constructions, I believe there must be a doubt that begins to linger in your mind. Since the system refactoring is transparent to the customer, the customer completely does not feel its existence, no doubt, it is worthless to the customer. The question is: since refactoring is worthless to customers, what's the point of doing it? To understand this problem, we need to first talk about four kinds of motivations for software modification.

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/