Designed to die? English Original copyright owned by Martin Fowler Original Text Is CopyRighted by Martin Fowler
Martin Fowlerchief Scientist, Thoughtworks
Original version | Traditional version | Translator: Daimler Huang
For many people who have expired Extreme Programming, XP seems to declare the death penalty of software design. Not only a lot of designs are labeled as "Big Up Front Design" [Translation 1], even a lot of technologies like UML, flexible programming, or even mode (Pattern) is not valued, or is ignored. In fact, XP contains many design philosophy, but it has different ways of operation with existing software processes. XP gave evolutionary design (PRACTICE) to give evolutionary design, so that evolution becomes a practical design method. It also facilitates the designer (Designer [Translation 2]) facing new challenges and techniques, learning how to streamline, how to use reconstruction to maintain a clear understanding of a design, and how to gradually use mode.
(This article is the speech I published in the XP2000 Seminar, which will be announced in the seminar.)
Planned and Evolutionary Design (planned design and evolution)
The Enabling Practices of XP (XP Effective Practical Skills)
THE VALUE OF SIMPLICIE (simple value)
What ON Earth is Simplicity Anyway (what is simple)
Does Refactoring Violate YAGNI? (Reconstructing violates YAGNI?)
Patterns and XP (Mode and XP)
Growing an Architecture (development structure)
UML AND XP (UML and XP)
ON Metaphor (About metaphor)
Do you wanna be an architect when grow up? (Do you want to be a software architect in the future?)
Things That Are Difficult to Refactor in (it is difficult to refactivate)
SO is design dead? (So is it designed to die?)
Acknowledgements (Acknowledgments)
Revision History (revised record)
Extreme Programming (XP) challenges many software development common assumptions. The most controversial is to try to reject UP-Front Design, and support a relatively evolved approach. The critics say that this is the development method of "Code and Fix", and the top can only be a generally anxious program design. Supporters often see XP for design methods such as UML, PrinciPle (Design Guidelines), Patterns, etc. Don't worry, carefully pay attention to your program code, you will see good Design to appear.
I found yourself in this debate. My work focuses on the graphical design language - UML and Patterns, in fact I also wrote UML and Patterns book. I have such embrace XP means I abandoned these theories, or cleared these anti-revolutionary concepts from my brain?
Well ... I don't want your heart to hang in these two situations. Simple saying is not; the next article let me see more.
Planned and Evolutionary Design
I will explain how the two design methods of software development is done in this article. Perhaps the most common is an evolution design. Its essence is the system's design grows with software development. Design is a part of the writing program code. As the program code is developed, the design is also adjusted. In common use, the evolution design is really completely failed. The result of the design is actually a bunch of decisions in which some special conditions are cleverly arranged, and each condition will make the program code more difficult to modify. From many ways, you may criticize this, there is no design, which will often lead to a very bad design. According to Kent's statement, the so-called design is to allow you to make you a long time to modify the software. When Design is not as good as expected, you should be able to make a valid change. After a period of time, the design is getting worse, you also understand the level of this software. Such a situation not only makes it difficult to modify the software itself, but it is easy to generate bugs that are difficult to track and completely solve. As the plan is carried out, the number of bugs grows in an index, and more costs must be solved, this is the nightmare of "Code and Fix".
Planned Design is just the opposite and contains the concept of other projects. If you plan to be a dog house, you only need to find a wood and have an inert image in your heart. But if you want to build a skyscraper, take the same practice, I am afraid that less than half the high building will be collapsed. So you first complete the drawings in the office like my wife in Boston. She determines all details in the design diagram, one for mathematical analysis, but most of them use architectural norms. The so-called architectural normative is based on the successful experience (some are mathematical analysis), the law of designing structures. When the design is completed, their company can hand over the design graph to another construction company.
Planned Design will be applied in software development in the same way. Designer first defines important parties, the program code is not written by them, because the software is not "building [translation 3]", they are only responsible for design. So Designer can use technologies like UML, do not need to pay too much attention to the details of the program code, while working at a relatively abstract level. Once the part of the design is completed, they can hand over it to another team (or even another company) to "build". Because Designer thinks towards the direction, they can avoid the order of the software because of the constant changes in strategies. Programmer can write a good system according to the design direction (if you have a design).
The Planned Design method appeared in the seventh and many people used it. In many ways it is better than Code and FIX progressive design, but it also has some shortcomings. The first disadvantage is that when you write a program code, you can't think of all the problems that must be handled simultaneously. Therefore, there will be no problems that have encountered some questions about the original design. However, if Designer is transferred to other projects after completing the job, what should I do? Programmer started to write to write a program, so the software began to tend to confuse. Even if you find Designer, spend the time finishing design, change the design map, and then modify the program code. However, it is necessary to face shorter times and greater pressure to modify the problem, and it is the beginning of chaos.
In addition, there is usually a problem with software development culture. Designer became a Designer because of specialized technology and rich experience. However, they are busy engaged in design without time writing program code. However, the development of software has developed rapidly. When you no longer write program code, you don't just miss the change in technology trend, and also lose the respect for those who actually write program code.
This subtle relationship between Builder [Translation 3] and the designer also sees in the architectural industry, but it is only high in the software industry. The reason is so strong because of a key difference. In the construction, designers and engineers have a clear profile; in the software industry, they are unclear [translation 2]. Any Programmer that is highly paying attention to Design's environment must have good technology, his ability to question Designer's design, especially when Designer is increasingly unfamiliar with new development tools or platforms. Now these issues may be able to get resolution. Maybe we can handle the interaction between people and people. Perhaps we can strengthen Designer technology to handle most of the questions, and bind a process that is sufficient to change the design in accordance with guidelines. But there is still another problem: change the demand. Change demand is the most problem that I feel the headache in the software project.
One of the ways to handle changes demand is to do elastic design, so you can easily change the design when demand changes. However, this is what you need to see what you may do in the future. A reserved designed to deal with variable nature may be helpful for future demand changes, but there is no help (even harmful) for unexpected changes. So you must have enough understanding of the demand to isolate the variable part. This is very difficult to observe my observation.
Some of the problems related to demand should be blamed on the understanding of the demand, so some people focus on research demand processing, hoping to get appropriate demand to avoid the removal of the design. But even if you are doing it in this direction. Many unpredictable changes caused by instantaneous shopping malls, you only have more careful demand issues to cope with the unavoidable situation.
In this way, Planuned Design sounds like it is impossible task. This approach is of course a big challenge. However, the evolutionary design is generally compared with the code and fix method, and I don't think Planned Design will be relatively poor. In fact, I also prefer Planned Design. Because I understand the shortcomings of Planned Design, and is looking for a better way.
The Enabling Practices of XP
XP is controversial because of many reasons, one is that it advolutionary design is not Planned Design. We also know that the evolutionary design may not be done because of a specific design or software development.
To understand the core of these debates is the software research and development of an action curve. Changes of curves In order to increase the cost rendering index required for changes in the course of the project. Such curves often indicate in one sentence: there is a change in the analysis stage to spend thousands of dollars to remedy. Ironically, most of the plans still have no analysis procedures and in a non-standard manner, but this cost index relationship still exists. This index curve means that the evolution design may not pass, and it also shows why Planuned Design should be carefully planned because any errors still face the same problem.
The basic hypothesis of XP is that it can pull this index curve, so that the evolution design is available. XP makes the curve more gentle and can use this advantage. This is because the coupling effect between XP actual techniques: In other words, this curve does not tend to work without using the actual skills that can flat software development curves. This is also the source of debate, because the critics do not understand this relationship therein. Usually these criticisms are based on their own experience, they don't implement those effective practical skills, when they see the result is not as expected, the impression of XP is the same.
These valid actual skills have several parts, mainly Testing and Continuous Integration. If there is no Testing security, other XP practical skills are not feasible. Continuous Integration can keep team member information synchronization, so when you have changed parts, you don't have to worry about the integration of other member information. At the same time, these actual techniques can greatly affect the development curve. This makes me again remember that after Testing and Continuous Integration in Thoughtworks, it improves the research and development results. The degree of improvement is good to be suspected is that it is like XP, and all the actual skills must be used to significantly improve efficiency. [Translation 4] Refactoring has similar results. Those who have adopted XP proposals to review the program code, which is more efficient than non-unparalleled or special way RESTRUCTURING. That used to guide my proper refactor to get an unforgettable experience, and because of such a huge shift prompts me to write a book with this topic.
Jim Highsmith wrote a great article "Summary Of XP", he puts Planned Design and Refactoring at both ends of the Libra. Most of the traditional practices assume the constant, so Planned Design dominates. And when your cost is increasingly altered, you will tend to use refactoring. Planned Design is not completely disappeared, just makes these two practices to make each other to make a balance. For me, I always feel that this design is not sound enough before designing Refactoring.
Continuous Integration, Testing and Refactoring These valid actual methods make Evolutionary Design seem very much. But we have not yet identified the balance between them. I believe that there is any impression on XP in the outside world, and XP is not only Testing, Coding and Refactoring. There is also the need for Design before Coding. Some of DESign is prepared before coding, and most of the Design happens before performing each of the features. In short, new balance can be found between UP-Front Design and Refactoring.
The Value of SimPlicity
XP loud two slogans are "Do The Simplest Thing That Could Possibly Work" (only the simplest design) and "you are going to need it" (YAGNI - you will need it) . Both are the form of expressive design in XP practices.
The word YAGNI is often discussed, it means not add any program code now for future features that may be used in the future. It sounds simply on the surface, the problem is in Framework, reuse components, and elastized design, these things are very complicated. You pay extra costs in advance to build them, I hope to make it back later. This idea of this prior elastic design is considered to be a key part of the software design.
However, XP's suggestion is to build a resilient component group and framework when dealing with the first problem. Let the overall structure grow as needed. If I want a Money category that can handle addition but don't have to multiply, I only build the functions of the addition in the Money category. Even if I determine that the next stage also needs multiplication operation, and I know very simple, I can't spend how much time, I will still leave it next stage.
One reason is the benefits. If I want to spend time, it is necessary to play tomorrow, it means that I didn't put my spirit on this stage. Purchase the items for the top now to complete, and now make things that needed to violate the agreement between developers and customers. This approach has the possibility that the goal is unable to achieve. And this stage of Stroies [Translation 5] is risky, or you need to do additional work, it is made by the customer - or may not include multiplication function. This kind of economic benefit is because we may be wrong. Even if we have determined how this feature works, it is possible wrong - especially at this time we have not yet achieved detailed requirements. Do a wrong thing in advance is more wasteful than making a pair in advance. And XP experts usually believe that we are more likely to do something wrong, not doing (my heart is awkward).
The second reason that supports Simple Design is a complex design violates the principle of light travel. Complex design is more difficult than simple design. Therefore, with the complexity of the increasing system, it is more difficult to make any modifications to the system. Thus, if the system must add more complex design, the cost is bound to increase.
Many people now find that such suggestions are meaningless, in fact they want to be right. Because you imagine that the general R & D is not replaced by XP effective skills. However, when the balance between the planned design and progressive design has changed (only when such changes occurs), YAGNI will become good skill.
Therefore, the conclusion is that unless there is a need to reach the next stage, you will not waste your spirit to add new features. Even if you don't cost a cost, you will not do this, because even if you don't increase the cost, it will increase the cost of making modifications in the future. In summary, you can comply with such a method for wise when using XP, or take a similar approach to cost reduction.
What on Earth Is Simplicity Anyway
Therefore, we hope that the more simple and better, the more it can sound, this sounds no more controversy, after all, who wants to complicate? But the problem is coming, "What is it simple?"
In the XPE book, Kent has booked four evaluation criteria for simple systems, and the order is (the most important ranks):
Through all tests.
Present all intentions.
Avoid repeating.
Minimum number of categories or methods.
Through all tests, it is a very ordinary evaluation standard, avoiding repetitions and clear, although some R & D staff need someone else's guidance. What is more troublesome is "presenting all the intentions", what is this?
The original meaning of this sentence is a simple and clear program code. XP has a high standard of readability for program code. Although in XP, "Clever Code" is often abused, but it is a clever program code, which is really a clever. Josh Kerievsky got a good example in the XP 2000 paper, reviewing the program code for everyone the most well-known JUnit in the XP area. JUnit uses Decorators to join unnecessary features in Test Castes, like synchronous mechanisms and batch settings, etc., to extract these program code into Decorator, indeed make normal program code looks clearly.
But you must ask yourself, do you make so simple enough? I think it is because I understand the decorator this patterns. But it is quite complicated for those who don't know. Similar situations, JUnit uses Pluggable Method, which does not feel simple skills when most people have just started to come. So, maybe we can say that JUnit is relatively simple for people with experience, and novices will feel complicated.
The DRY (Don't Repeat Yourself) of XP "Once and Only Once" and Pragmatic Programmer is focused on removing the repeated program code. These good suggestions have a significant and amazing effect. As long as in this way, the project can work smoothly. But it can't solve all problems, simplified or not easy to achieve. Recently I have participated in a project that may be excessive design, and the system removes part of the elastic design after Refactor. However, as one of the developers said "Reconstruction of excessive design is much easier to be more than the desired design," is the best than you need, but it is a little bit. It is not a serious thing in a complex point.
I have heard the best suggestion from Bobert Martin. His advice is not too much what is the simplest design. After all, you can, it should be, it will also be reconstructed. Willing to refactor, more important than knowing how to do simple design.
Does Refactoring Violate YAGNI?
This topic has recently appeared on the XP discussion area. When we examine the role of design in XP, I think it is worth mentioning.
Basically this problem is due to the reactance to take time but does not increase the new features. YAGNI's point of view is to assume that you need to design instead of the future, is this conflict?
YAGNI's view is not to increase the complex features that are not needed at this stage, which is also a part of this technique. Reconstruction is also to meet the simplicity of the system as much as possible, so when you feel that the system becomes simpler, it will be reconstructed.
Simple design not only uses XP practice skills, it is also a useful practical skill. Only with test, continuous integration, and reconstruction can be effectively designed effectively. At the same time, the foundation of maintaining the development of an electric curve is also a simple design. Any unnecessary complex will make the system becomes difficult to adjust unless this complexity is added to the predicted flexibility. However, people's forecasts are usually less accurate, so it is best to maintain simplicity.
Anyway, people are unlikely to get the easiest thing for the first time, so you need to refactor to help you close this goal.
Patterns and XP
JUnit's example made me have to think of patterns. The relationship between XP and Patterns is very subtle, and often asked. Joshua Kerievsky believes that patterns is too tightly in XP, and the reason why he has raised is quite convincing, I don't want to reverberate. However, it is worth mentioning that many people think that patterns seem to have conflict with XP.
The essence of the debate is that patterns are often over-abused. There are too many legendary Programmer in the world. I read the four-legged code of 32 rows of order. I still remember to discuss an article with Kent with Kent "Not Design Patterns: 23 Cheap Tricks (do not use the design pattern-23 simple 诀窍)." We believe that it is just that the IF condition is replaced with Strategy this pattern. Such a joke has a focus, and patterns is abused. But it doesn't mean that patterns is not enough, the problem is how you want to use it.
One of the arguments is that the strength of the simple design will naturally guide the project to PATTERNS. Many reconstructed examples are clearly done, or do not even need to be refactored, you will find Patterns as long as you follow the simple design rules, even if you still don't know what patterns is. This kind of saying may be true, but is it really the best way? Of course, if you have a big understanding for Patterns, or if there is a book in your hand, you can refer to it, which will be better than invented new patterns. When I think a Pattern is coming, I will definitely turn over the GOF book. For me, a valid design tells us that Pattern is worth learning - that is its unique technology. Like Joshua suggestions, we need to be more familiar with how to gradually use Patterns. In this regard, XP is only different from the usual way of using patterns, and does not erase its value. But from some articles in the discussion area, I think many people clearly believe that XP does not encourage the use of Patterns, although most advocates of XP are also leaders in Patterns movement. Because they saw different views from Patterns? Or they have integrated patterns into thinking without having to understand it again? I don't know what other people's answers, but for me, Patterns is still very important. XP may be a process of development, but patterns is the backbone of design knowledge, regardless of which process is very useful. Different processes use patterns, and XP emphasizes the need to use Patterns and gradually import Patterns through simple work. So Patterns is still a key knowledge that must be obtained.
I have recommended Patterns using XP:
Take some time to learn Patterns.
Pay attention to the time to use Patterns (but don't be too early).
Pay attention to how to use patterns first in the simplest way, then add complexity.
If you use a Pattern but I feel that there is not much help - don't be afraid, take it again.
I think XP should be more emphasized to learn Patterns. I am not sure how it is to match XP practical skills, but I believe that Kent will come out.
Growing an Architecture
What is the software architecture point? For me, architecture This word represents the concept of system core components, which is difficult to change, and the rest must be built on this basis.
So when you use evolutionary design, what role is played again? The XP's critics claimed again to claim to ignore the architecture because the method used by XP is to write the program as soon as possible, and then believe that the reconstruction will solve all the designs. I am very interesting, they are right, this is likely to be the shortcomings of XP. Undoubtedly, the most active XP expert - like Kent Beck, Ron Jeffries, and Bob Martin, to avoid pre-structural design. Before you know that you really want to use the database, don't join the database, first use the file instead, and then add to the database with the subsequent stage.
I am often considered a timid XP expert, I don't agree. I think a general initial architecture has its use. How to apply a hierarchy, how to interact with the database (if you need it), which way to use to deal with the website server.
Basically, I think this is the Patterns we have studied in recent years. Especially when you know the understanding of Patterns, you will be familiar with how to use them. However, the difference in key is that these initial architectures can be changed, as long as the team believes that their early judgment is wrong, they should have courage to fix them. Some people told me a story of a project, just when the project is coming, I decided no longer need EJB, and to remove them from the system. This is a considerable number of reconstruction, but in the end, it is still completed. These effective practices not only make things possible, but also worth doing. What if you do this in a different way? If you decide not to use EJB, will it be difficult to join in the future? Do you have to try a variety of ways but find what is still lacking, then use EJB? This is a problem involving many factors. Failure to use complex components can of course increase the simplification of the system, and make things progress faster, but sometimes you can easily add some part from the system.
So I suggest that starting from the evaluation architecture possible. If you see that multiple users will use a lot of information, use the database directly at the beginning. If you see a very complex business logic, it is set with Domain Model. You will suspect whether it deviates from a simple feature, which is of course not the spirit of YAGNI. So you have to prepare, simplify your structure as soon as possible when you find the structure used.
UML and XP
After I devote myself in the XP field, because I have a big problem with UML, is it not compatible?
Of course some are not compatible. XP obviously does not pay attention to Diagram. Although everyone has a consensus on the "easy to use", it is actually "actually uses XP people who do not draw blueprints." This impression is strengthened because these people are not used to the phenomena of the figure. In fact, I have never seen the Kent actively uses a fixed mark method to draw software blueprints.
I think this situation comes from two factors. One is that some people think that the software blueprint is useful, and some people don't feel useful. It is difficult to feel that people who are useful in blueprints are not really doing people who do their hands, but people who must do their hands do not feel their necessity. In fact, we should accept some people like it, and some people don't like it.
Another situation is that software blueprints are often in a heavy process, and these processes are time-consuming, but they will even have harm. I think that people should teach people how to use blueprints, but they do not fall into such traps, rather than using just negative saying "."
So, I have recommended the use of blueprints to use the blueprint:
First don't forget the purpose of you painting these pictures, the main value is communication. Effective communication means choosing an important part and ignores unimportant part. Such choices are also the key to efficient use of UML. You don't have to draw all Class, you don't have to draw it. For each class, only critical Attribute and Operation are displayed, not all displayed. Don't draw a chart in all USE Case and steps ... unless you already have a complete imagination. There is a common problem using blueprints that people usually want to show the drawings in detail. In fact, the program code is the best source of providing full information, and the program code itself is also the easiest way to keep information synchronization. Because the graphics of the giant 靡 靡 is a great enemy.
The purpose of the blueprint is to explore the design content before starting the program code. I always feel that this action is illegal in XP, but not the case. Many people say that if you encounter a tricky problem, it is worth doing some design. But when you design:
Maintain short.
Don't do too detailed (only to pick an important thing).
Take the result as a sketch, not a case.
The last point is worthy of discussion. When you do a pre-design, you will not avoid some errors, and you will find it when you write the program code. If you change your design, it is not a problem. Trouble is if your design has been finalized, there is no experience from the Coding process and follow the previous design. The change design does not mean to change the blueprint. Painting these blueprints to help you understand the design, then throw the figure open, it is very reasonable. These pictures can help you have its value. They don't have to exist forever, the most useful UML graphics will not be a collection.
Many people who implement XP use CRC cards, which is not conflict with UML. I often interact with the CRC card and UML, and I always choose the most useful skill in accordance with my work. Another use of the UML graph is to continue revisions. Its general form is the model seen in the Case Tool. The initial idea is to stay such information to help build the system. In fact, there is often not used.
Keep the graphics update too much time, and finally cannot synchronize with the program code.
They are implied in Case Tool or Thick Binder, let people ignore it.
So I want this continuous revised file to be useful, from these problems:
Only some of the modifications are not allowed to make people feel painful.
Put the picture in a conspicuous place. I like to draw on the wall and encourage everyone to make a modification.
Review these pictures is not in use, and wipe it off without use.
The last problem using UML is the handover of the file, like a different team's takeover. The idea of XP is that the file is like a story, so the value of the file is determined by the customer. So UML is also sent to the field, and the graphics provided can help communicate. Don't forget that the program code itself contains all detailed information, the role of graphics is just provide an overview and the important part.
ON Metaphor
Ok, I may be admitted - I have never seized the spirit of Metaphor. It is useful, and it is used in the C3 project, but doesn't mean that I know how to use it, let alone to explain how to use it.
The metaphor in XP practicing skills is based on Ward Cunningham's to be named after system. The focus is to come up with a well-known vocabulary, in such a word to a more common category. The name of this representative system will be used in Class and Method named.
I have established a naming system with the conceptual model of different fields, using UML and its predecessor. I have found that you have to be very careful, you have to keep the most streamlined annotations, and to make technical problems unconsciously affect this model. But once you finish this job, you can build a group of vocabulary in a variety of fields. These vocabulary can be understood and can be used to communicate with R & D staff. This model cannot match the Class design, but sufficiently gives a universal synonym of the entire field.
At present, I can't find any reason. Why can't be a metaphor, just like the success of C3; I don't think there is any harmony with the system-oriented version of the vocabulary. At the same time, I will not give up the skills that can be used as a system name.
People often criticize XP is based on at least one of the needs of a system. XP experts responded to "Metaphor!". But I still didn't see a convincing explanation for Metaphor. This is the shortcoming of XP, and the XP expert must be learned.
Do you wanna be an architect when grow up?
In recent years, "Software Architect (Software Designer)" has become more and more popular. This is a noun that is unacceptable to me. My wife is the relationship between structural engineers, engineers and architects ... interesting. One of my favorite words is: Architects are good to three Bs, bulbs, bushes, and birds. Because the architect draws these beautiful pictures, but the engineer must make it possible. The conclusion is that I avoid the word Software Architect, after all, if my wife can't respect my major, how can I expect others? For software, the term "Architect can represent many things. (Many words in the software industry can represent a lot of things.) This is usually in line with a sentence: I am not only a programmer, I am still a designer [translation 2]. It is also possible to further interpret: I am now a designer - I am too important for completing all programs. Then this problem becomes, when you want to show technology leadership, do you write your own and cumbersome procedures?
This problem caused a lot of dissatisfaction. I saw that people were angry with ideas such as the design role. I often hear: there is no designer in XP to sway space.
For the role of the design itself, I don't think XP does not pay attention to experience or good design. In fact, many XP advocates - Kent Back, Bob Martin, of course, Ward Cunningham - all I have learned the design. However, this also represents their roles from all the existing impressions to become technical leaders.
I will take a technology leader Dave Rice in Thoughtworks as an example. Dave participated in many research and development cycles, and informal guidance of a 50-person project. The role he serves as a guide means that it takes a long time and programmer. When the programmer needs help, he is involved, otherwise he will pay attention to who needs assistance. His seat has a clear feature that serves a long-term thinking worker, he can adapt good in any form of office environment. He used to share the Office Manager CARA Shared Office for a while. In the last few months, he moved to the open space of engineers' work (just like XP group like an open "combat space"). It is important to do this to him. He can know the progress of things and make a helping hand in a timely manner.
People who know XP can understand what I described is the clear role of XP "coach". Indeed, the leadership technology in the text game played in XP is to depict the role of "coach". It is very clear: leadership in XP technology is presented through teaching programmers and helping them make decisions. This is a technique that needs good interpersonal management and technology. Jack Bolles says in XP2000: The Master of Lone is a bit chance, cooperation and teaching is the key to success.
At the dinner at the seminar, I and Dave have some opposition to XP when talking. When we discuss the previous experience, our methods are quite similar. We are all prejudiced, Itemive Development, also believes that test is important. So we all felt doubts about his opposition. However, he mentioned that "the last thing I want is the programmer is busy with the design". Everything suddenly. Later, Dave said that "If I don't trust my programmer, why should I use them?" The concept of the concept is even more clear. In XP, the most important thing that experienced R & D people can do is to try to advance all technologies to newers. Unlike an architect who determines all important things, you have a coach that teaches R & D staff to do a major decision. Just like Ward Cunningham pointed out, don't just enhance the ability to enhance your newcomer, the benefits of the project are greater than a hyper people who are isolated without aid. [Translation 7]
Things That Are Difficult To Refactor in We can use Refactoring to handle all design decisions? Or, some problems are too common and difficult to join the design in the future? At this point, the orthodox approach of XP is that all requirements can be easily increased when needed, so YAGNI can always apply. I guess whether there is exception? There is a nice, the example discussed is the internationalization of the software. This is not a kind of going now, otherwise it will feel painful when adding it.
I can easily imagine something that is this situation. In fact, we still master too little information. If you have to join some features, such as internationalization, and you know how much work needs. You are not easy to realize how much time you want to add it before you really need him, and maintain it for a long time. You are not easy to detect maybe you may do something wrong, so I still need to do some refactoring.
There is a reason for the defense of YAGNI is that some pre-done features may not be needed, or it is not as expected. Do not do these efforts than to change the strength of the need to meet the needs of the needs.
Another problem to think is whether you really know how to do it. If you have many experiences of software internationalization, you will know what model used. In that case, you should do it. At this time, the reserved structure you join may be better than your header. So my idea is that if you know what to do, you have to consider doing now and future, between the two situations. Conversely, if you don't have the problem, it is not only the cost you can't correctly judge, you can't make things good. This situation, you have to choose to do it in the future. If you still have it, you can taste the bitter fruit, you may be worse than you don't do. When your team members have more experience, you have more understandings about related fields, you will know more about demand. Usually, you will find more simple things when you look back. The design earlier is much more difficult than you think.
This problem is also closely related to the order of Stories. In Planning XP book, Kent and I have disclosed our discipline. Kent is biased to only the factors of commercial value affect the order of Stories. Ron Jeffries also agreed to this idea after short-lived opinions. I still stay suspicious. I believe that the balance point can be found between business value and technical risks. Based on this reason, I will prepare for software internationalization to reduce risks. But this approach is only necessary to expose software internationalization when issuing in the first phase. It is very important to reach a phase release as soon as possible. Any complexity that must be increased will be worthwhile to start after the first phase is issued. After the release, the program has a powerful force, which seizes the customer's attention, adding trust and a good opportunity to learn. Even if there will be more things to do after the initial release, but also do our best to push the first phase date forward.
SO is design dead?
Nothing, it is only the essence of the design has changed. XP design pursuits the following techniques:
The more simple and better, the more simpler, the more simpler.
Reconstructive skills, so you can have confidence in the time when you feel necessary.
Knowledge with Patterns: Not just a way of solving it, how to feel when it can be applied, or how to import Patterns.
Know how to tell the designs to understand [Translation 8], with program code, or graphics, or all of the above tools: conversation.
The skills that have been picked up seem to be very scared, but it is difficult to become an excellent designer. XP is not to make it simple, at least I don't think it is. But I think XP lets us have a new idea for efficient design, because it makes progressive design sounds feasible way. And I also support evolution - otherwise know what I will become?
Acknowledgements [Translation Note I have learned a lot of good ideas from many good friends in the past years, many have already remembered. But I remember the good things that steal from Joshua Kerievski. I also remember that Fred George and Ron Jeffries gave me a good suggestion. I certainly can't forget Ward and Kent's constant ideas.
I also grateful to the question and pointed out the wrong friend. At the same time, Craig Jones reminds me a few "A" missing.
Revision History
The following is a major modification record of this article:
February 2001: Modifications such as Growing An Architecture, The Role of An Architect, and WHERE Things That Are Difficult To Add with Refactoring.
July 2000: Original file published in XP 2000 and published in Martinfowler.com webpage.
[Translation 1] Before the writing of program code, first, according to the established program analysis, design, mapping, writing files, etc. time-consuming work.
[Translation 2] What is the difference between Taiwan you think of "programming designer", "software designer" and "software engineers"? I believe that most people feel that they are the same role. But from English writing, it is easier to distinguish between "Programmer", "Designer", "Architect", etc. from English. Such language cultural differences are also why I left a lot of original text in my own. In partial phrases, leave the original text does not affect the smooth reading, but can avoid ambiguity or distortion caused by translation.
[Translation 3] In the construction industry, it should be called "construction personnel" to compare the ear, and in the software industry should be "programmer" is appropriate. But both are "Builder".
[Translation 4] About this, the translator also provides a practical experience, which is the process of translating this article. I translated this article with a friend, and because I first read XP Distilled article, I decided to use XP 12 effective practical skills in Continuous Integration, Pair Programming, Small Releases, Refactoring, Coding Standards, Collective Code Ownership Waiting for skill. Because of the experience of XP Distilled, we first propose each other's unified version of each other, this is a Coding Standards. At the same time, we translate this article. Different people do not have the same work schedule, and each translated a few paragraphs will be sent to each other, which is Small Releases. When I received some part of my friends, I will put the article for the correctness of the two parties and the initial finishing and correction of the script, this is Continuous Integration. The part I sorted back was sent back to a friend. If you find a non-part, discuss or modify it, this is refactoring. From the process of head to the tail, we have received each other's translation versions, and also have the versions of the organ, which is clearly understood for each part, complying with the spirit of Collective Code Ownership. Finally, because we are just two people, you can't afford to top another tip of PAIR PROGRAMMING. Therefore, we use half of XP, which is a way to work. But not doing every skill is used. I think, more importantly, XP is not only used in software development, our translation process will not borrow!
[Translation 5] Story is a description similar to USE CASE.
[Translation 6] According to the original text, it is possible to show 16 kinds of Patterns with 32 lines. Such legendary skill is really not experienced and exclusive, so we can only follow the original translation, and you cannot ask for a left certificate on this sentence. If the reader has seen the example mentioned by the author, thank you very much for providing information to me. [Translation 7] This is also the problem of the translator to the Taiwan software environment is very worrying. Everyone can understand the Chinese people who don't know if it is a major shortcomings. I have seen an idea from the article in the article and friends in the mouth of the article. It is the easiest way to improve the team's employee education to the same level as the technology leading member. This idea is really a very useful and profound consideration, but also a kind of lament. How much is Taiwan to agree with this practice in verbally, and it is actually more capable of practicing this spirit? ? Some people are worried that their skills are smashed, and the personal status will be replaced. It is more likely that the boss will really be "the rabbit to die" after the inherit of extracting experience, will contribute but The cost of high cost is forced by a variety of ways, which is really worried and discouraged! The translator believes that the technology that is difficult to understand is that you can understand, there is already a competitor. If you can't raise the technical level of your side, you only wait for rapid transcendence, more likely to be eliminated. The translator also practiced the spirit of XP, although the technique of translator has very thick, but as long as colleagues need my assistance, I always know all, I don't know. The translator wants to wish to the meteor, I hope to find more and more similar classes.
[Translation 8] Effective communication is also one of the problems that translators often encounter. Some people can't discover in different ways. Some people have a professional terminology for foreign countries, and some people can't observe that they have already understood. The essences set forth. These are not effective communication. We seem to pay still enough to attach importance to this learning, how to say to the other party's way, it is not easy! The translator is just a sigh, but it is urgent to cultivate communication skills, and will not let the colleagues have shake his head.
[Translation 9] One of the translators (DAIMLER) also has a hurry, thank you a friend (Shchen) to take the email with me in a busy schedule, this friend is in software engineering knowledge. Give me the help very key. There are many controversies in translation, and should be translated by sentence by words, or consider making appropriate adjustments in accordance with the use of words in the country, in order to seek the words of the phrase, it is really difficult to make a choice. I (DAIMLER) is more preferred to make appropriate restructuring and adjustment of the sentence without distortion of the original written context. But this action itself has a very dangerous, I have enough understanding for the original text? Is my attainment to the country? I hope this article can help domestic readers, at least in efficiency. More expecting advice from all parties.
