Martin Fowler's article: Keeping Software Soft
Let the software go down (huh, the name of the translation is somewhat strange)
Original article:
Http://martinfowler.com/distributedcomputing/soft.pdf
Here is a Chinese translation:
Let the software go soft
Keeping Software Soft
Martin Fowler
Translation: Liu Wei
Thursday, July 4, 2002
Remember your first writing? I can remember: I knocked into some statements
(Written in some stupid language), do a little
Debug, my machine will respond to me. At that time, you can easily calculate it.
Machine do something, and change the program, let
It's too easy to do anything else, but just change a change program, do a point debugging. do not forget,
Total, the software is to be soft.
Of course, the absolute variability of the software is a fantasy. Many times, a software developer and
The difference between a normal person is
As: software developers know how difficult it is. In fact, it is really difficult to change the software.
How hard is it
Don't let it collapse.
People who do software doing software have been aware that this is why temporary design
(Ad hoc design) - when procedures
Write here to design - not suitable for a large system.
In order to solve this problem, software developers are inspired by other engineering disciplines.
. In these disciplines, design process and construction
The process is clearly distinguished. Communication for designers and builders is through design
What to build something, how to build
In these drawings.
Most of the software development methods are based on this idea. No longer temporary design
We have a new way.
I call it UP-Front Design. That is to say, before writing the program, once the design is completed
,Start
When writing a program, you should not have a major design change. Of course, the change is inevitable.
, But the pre-design process is clear
The purpose is to minimize this change as much as possible.
It is difficult to let these design as complete as possible to avoid major changes in the future.
And major changes tend to
Worse. There is a practical problem here - it is difficult for the design from the beginning.
.
There is a most fundamental problem with the reality of demand changes. Sometimes, I have to go to investigation, some of the missing items
That is a look
Make a way to let them get rid of the sea. Whenever, in this case, I will go and these items
Developers talk, I get it,
It seems to always complain about crying: "Customers are constantly changing demand"
. This always makes me feel very strange, I am strange,
All people are surprised by changes in demand. I have never encountered a real project.
It does not change. Even if you let
Users use blood to sign on demand files, no matter what blood type
Eventually change.
Users change their ideas and have the following reasons. One reason is: a system to develop
What will be something like?
It is difficult to say that it is difficult to say. Only when it is in front of you, you can use it to do actual
Work, you will find what function is
Really useful, what function is useless. Another reason is business changes
It is still a very important requirement for six months.
Because business changes, it is now possible to become a secondary demand. More people are more annoying
Some users have written some small programs themselves: I have written a little in VB, so they think that software modifications are easy (and
They have never dealt with a real system with many problems, interdependent
However, professional programmers must be dealt with.
For many people, this is a problem that the demand project must face. We need more good at things
First make a clear demand, put more time
Flowers in the need to clear the needs and keep up with the development of new technologies. I have also believed in this way.
But now I have concluded that this is
It is impossible to achieve, at least for a period of time.
There is another key issue, here you need a balance, what do you want?
How much is you prepared? If you buy a car
The car sales personnel tell you: "Do you want to be a ceiling?", Then you have to ask the first
I may be: "How much?"
If it is 20 yuan, then give me a good, if it is 20,000, then I would rather don't. So, unless we give one
More precise valuation, otherwise the customer is impossible to fix the demand. Unfortunately
script>, we showed very bad in terms of valuation. I
It doesn't matter, this is because software developers are stupid, the problem is the basis us.
The field is constantly changing. If concrete
The characteristics of the soil will also "upgrade" every year, and civil engineers will also find them.
Valuation is also very difficult.
So have other options? I want to have a choice, it can be summed up: expectation demand changes
Adopting a welcome development process.
This approach is incompatible with pre-design core ideas. If the demand can be without any
Why warning, then, then
How do we do a stable pre-design?
Let the change easier solution is to make the built software in the face of unsuccessful changes, it is better.
(We can set up
When the meter, let it handle some expected changes, but the problem is those who are unpredictable.
Change, follow the bite behind your ass
you. Object technology is a key here. Utilizing object encapsulation
(Encapsulation) and polymorphism (Polymorphi)
c)
Port, we can improve the assembly characteristics of the software, thereby reducing the dependence of each other
Make changes easier.
Dynamic development environments are also helpful, for example: object browser, fast finding cross-reference
Features, let you explore your code
The deactivation and monitors, a short compilation / connection cycle. For many professional developers
Say, these tools are still very new, but any one
SMALLTALK (translation: a dynamic language) programmer knows
: One is in Debug, can change the code and immediately
Effective, one is to make compilation / connection to interrupt your attention, both of which are different.
Refactoring (Translation: Refinition, I don't know if this translation is correct.
It refers to such a program change: the purpose of the code change
Not to increase the function, not to improve efficiency, but for the program structure more reasonable
Clear code, more readability, more
Easy to expand. As a black box, the program has no change, as a white box.
The program has indeed changed it here.
Dreaming a very important role. Refactoring is such a technology that can effectively change your software design, but will not introduce new BUGS. With refactoring, if you have an error in the beginning, you will change it later.
No need to spend a lot of money
price.
Dynamic Design All of these technologies (translation: the object mentioned above, dynamic development environment
, Refactoring, together leads us
The change of the method, this direction of transformation, I call it dynamic design
. In the dynamic design, you don't have to set it out.
Make it completely. This is not to let you give up the pre-design, you still need to do pre-set
Type, but at this time, your design is not
Find the best solution, but find a reasonable solution. you know
When you start building your software,
One step by step, you will realize the best solution, don't be the initial idea
the same. With refactoring, right
As a dynamic development environment, this will not be a problem because the change is no longer expensive.
It is necessary to emphasize that this transformation is an important result that leads to a simple design (translation note)
: Simple design is based on such an idea:
To add something on a simple thing, we must lose our things from a complex thing.
It is easy to more. This is also the value of XP
One of the movements. Before I use dynamic design, I am always looking for flexibility.
(flexible) solution. For any need, I
Always want to know what changes will change in the life cycle of the system being applied
. Because the change is very expensive, I tried to let
My design allows I can foresee the changes.
The problem of building a flexible program is a flexible price. Flexible plan is complicated than simple solutions
Generally, software constructed by flexible scheme
It is also more difficult to maintain, of course, if you happen to be flexible in terms of my foresee
That change will be easier. So, what do you need to know how to go?
Let the design flexibly. If there is only one or two parts, then there is nothing
But if the entire system will change, it can be troublesome. yield
The entire system is flexible in all places, which will make the system more complex and maintained.
Of course, more people are discouraged, all of these flexibility, perhaps it is not required.
. Maybe some is needed, but let
Which of you is going to foresee it is, it is almost impossible. So get what you need
Flexibility, you have to add some of you.
Unwanted flexibility.
Using a dynamic design, then the risk of dealing with these changes, it is greatly different.
. You still need to consider potential changes, you still need
Consider the flexible plan, but before deciding to adopt a flexible program, you have to ask yourself,
"Turn a simple solution to a need
How hard is it necessary? ", If the answer is" small meaning, it is easy "
(Most are this answer), then, you will pick it up.
Go with a simple solution.
So the dynamic design will result in simple design, but will not lose flexibility. This also makes it designed
The process is simpler and the pressure is smaller. Once you care
Solve these things, it will be easy to reorganize (Refactor)
You don't even think about flexible programs. If you need to change, you
Confident to reform ". Just like the Kent Beck (Translation: "Extreme Programming Explained" and
As the author of "Planning Extreme Programming", it is recommended to build a simplest
Things, as long as it works
. In order to flexible complex design, in most cases, it is not required.
This is a big change in the design process, and for me such a designer.
It also requires a big change. But it has a few
Tip: You need a good test, you need object technology, you need to know about REFA
CTORING. However, its return is also very rich.
You don't have to be afraid of demand, and you can respond to your customer's request.
Not to sacrifice your design, even your future.