Note: This article is taken from "Agile Software Development: Principle, Mode and Practice" (Tsinghua University Press, September 2003, I am fortunate to translate the book, see: http://www.china-pub.com/computers Appendix D in /common/info.asp?id=13569) This is a great palace, written in 1992, the author can have such reflection at the time, it is very unfair.
×××××××××××××××××××××××××××××××××××××××××××××××× ×××××××××××××××××××××
Source code is design (Deng Hui translation)
So far, I can still remember the place where I am experiencing and eventually producing the following article. That is the summer of 1986, I served as a temporary consultant in the China Lake Naval Weapon Center in California. During this time, I was fortunate to participate in a seminar about ADA. In the discussion, a listener put forward a representative question. "Is the software developer is an engineer?" I don't remember the answer at the time, but I remember that I didn't really answer this question. So, I will quit the discussion and start thinking about how I will answer such a question. Now, I can't affirmed why I will remember a paper that I have read in DataMation magazine almost 10 years ago, but I have prompted me to remember some things in subsequent discussions. This paper explains why engineers must be a good writer (I remember that this question is this problem - I haven't seen it for a long time), but the key to me from the paper is that the author believes that the final result of the project is documentation . In other words, engineers produce documents, not physical. Others make specific properties based on these documents. So, I put a question in confusion. "Is there anything that can be considered a real engineering documentation in addition to all documents generated by the software project?" I gave an answer yes, "Yes, there is Such documents exist and only one - source code. "Watch source code as a project document - design - completely subverting my opinion on my choice. It changed my way to see everything. In addition, the more I think about it, the more I feel that it is often the many problems that the software projects are often encountered. More specifically, I think most people don't understand this different opinion, or intentionally reject the fact that it is enough to explain a lot of problems. A few years later, I finally had the opportunity to disclose my point of view. A paper on software design in C Journal prompted me to write a letter about this topic. After several letters exchange, the editor of Livleen Singh agreed to publish my idea about this topic as a paper. Here is this article. --Jack Reecves, December, 22,2001
What is software design? © Jack W.Reeves, 1992
Object-oriented technology, especially C , seems to have a small vibration to the software community. A large number of papers and books have shown this new technique. Overall, the problem with the object-oriented technology is just a scam, which has been replaced by those who have the smallest effort to get the benefit. Object-oriented technology has been a period of time, but this explosive epidemic seems to be a bit unusual. Why do people suddenly pay attention to it? For this issue, people give a variety of explanations. In fact, it is likely that there is no single reason. Perhaps, combining a variety of factors can eventually break through, and this work is progressing. Despite this, in this latest stage of the software revolution, C itself seems to be a major factor. Similarly, there are many reasons for this problem, but I want to give an answer from a slightly different perspective: C is popular because it makes software design easier while making Programming is easier. Although this explanation seems to be a little strange, it is a well-thoughtable result. In this paper, I just want to pay attention to the relationship between programming and programming. In the past 10 years, I have always feel that the entire software industry has not been found to make a software design and what is a subtle difference between the real software design. As long as I see this, I think we can learn how to become a long-term knowledge of how to become better software engineers from the popular trend of C growth. This knowledge is that programming is not building software, but design software. A few years ago, I saw a seminar, discussed whether the software development was an engineering discipline. Although I don't remember the results of the discussion, I remember how it prompted me to realize that the software industry has made some mistakes and hardware engineering comparisons, and ignored some absolutely correct contrast. In fact, I think we are not software engineers, because we don't realize what is true software design. Now, I am confident that this is even more confident. The ultimate goals of any engineering activities are certain types of documents. When the design work is completed, the design document is transferred to the manufacturing team. The team is a group with a completely different design team, and its skills are also completely different from the design team. If the design document correctly depicts a complete design, the manufacturing team can build a product. In fact, they can start a lot of real involves any of the designers without any further intervention of the designer. After reviewing the life cycle of software development in accordance with my understanding, I got a conclusion that the only software document that meets the engineering design standard is the source code list. For this view, people have conducted a lot of arguments, whether it is in favor or opposing enough to write countless papers. This article assumes that the final source code is true software design, then carefully studied some of the results brought. I may not prove that this view is correct, but I hope to prove that it does explain some facts that have been observed in the software industry, including the popularity of C . In the result of the software design as the result, there is a result that completely covers all other results. It is very important and very obvious, because of this, for most software institutions, it is completely blind. This result is: The construction of software is cheap. It does not have expensive qualifications at all; it is very cheap, almost free. If the source code is a software design, the actual software build is done by the compiler and the connector. We often refer to compilation and connecting a complete software system called "once construction". The main investment in the software build device is very small - there is only one computer, an editor, a compiler, and a connector. Once a build environment is built, the actual software builds only takes a little time.
Compiling 50,000 rows of C programs will cost long, but build a hardware system with a 50,000 row C program to design complexity? Watching the source code as another result of software design is that software design is relatively easy to create, at least in mechanical sense. Typically, writing (also design) a representative software module (50 to 100 line code) is only taken for a few days (complete debugging to it is another topic, and will be more for it later. discuss). I really want to ask if there is any other discipline can have a design and software that has the same complexity in such a short period of time. However, first we must figure out how to measure and compare complexity. However, some is obvious, that is, software design can be very rapidly. Suppose software design is relatively easy to create, and there is no price in essentially, an uncompristened discovery is that software design is often incredible and complex. This seems to be obvious, but the importance of the problem is often overlooked. The projects in the school usually have thousands of lines of code. Software products with 10 000 row code (design) are discarded by their designers. We have long no longer pay attention to simple software. Typical commercial software is designed by hundreds of thousands of lines of code. Many software design reaches millions of lines of lines. In addition, software design is almost always evolved. Although the current design may only have a few thousand lines of code, but in the life of the product, it may be necessary to write a number of code. Despite some hardware design, they seem to be as complex as software design, but please pay attention to two facts about modern hardware. First, complex hardware engineering results may not always have no mistakes, at this point, it does not have the criteria that let us believe in the software like software. Most microprocessors have some logical errors in the sale: bridge collapse, dam rupture, airplane crash, and thousands of car and other consumer goods recall - all of these people have remembered, all of these It is the result of the design error. Second, complex hardware design has corresponding complex, expensive construction phases. As a result, the ability to manufacture such a system limits the number of truly capable hardware design companies. For software, there is no such limit. At present, hundreds of software institutions and thousands of very complex software systems are existent, and the quantity and complexity are growing every day. This means that the software industry is impossible to find solutions to their own problems through emulating hardware developers. If you have to say what is the same, that is, when CAD and CAM can help hardware designers create increasingly complex design, hardware projects will become more and more like software development. Design software is an activity of management complexity. The complexity exists in the software design itself, existed among the company's software institutions, also exists in the entire software industry. Software design and system design are very similar. It can span multiple technologies and often involve multiple discipline branches. Software specifications are often unfixed, often rapidly changing, which often occurs when the software is being designed. Similarly, software development teams are often unfained, often changing in the middle of the design process. In many ways, software is more like complex social or organic systems than hardware. All of this makes the software design be a difficult and easy to erode. Although all of this is not a creative idea, the software development seems to be unstructured (undiscipline) in today, with other engineering industry, compared with other engineering industries. The general view believes that when the real engineer has completed a design, it is very confident that the design is working very well.
They are also very confident that this design can be built using recognized technology. In order to do this, hardware engineers spend a lot of time to verify and improve their design. For example, consider a bridge design. Before the design is actually built, the engineer will structural analysis - they build computer models and simulate them, and they establish a proportional model and test them in a wind tunnel or in other ways. In short, before construction, the designer will use all the methods they can think to confirm the design is correct. For a new passenger aircraft, the situation is even more serious; must build prototypes with the original same size, and must perform flight tests to verify that the designs are expected. For most people, the software is clearly absent and hardware design equally strict projects. However, if we see the source code as a design, then the software engineer will actually have a lot of verification and improvement in their design. Software engineers don't call this as project, and call it as testing and debugging. Most people do not think of testing and debugging as a real "project" - is definitely not seen in the software industry. The reason for this view, more because the software industry refuses to treat the code as a design, not any actual engineering difference. In fact, the test model, prototype, and circuit test panels have become a recognized part of other engineering disciplines. Software designers do not have or without using more regular methods to verify their design because of the simple economic law of the software build cycle. The first revelation: only constructs design and test it is cheaper than doing anything else, but also simple. We don't care how many times do we do - these builds are almost zero at the time of time, and if we discard the build, the resources it use can be reused. Please note that the test is not only to make the current design correct, and it is also part of the process of improved the design. Hardware engineers for complex systems often create models (or, at least they are visually illustrated by computer graphics). This makes them get a "feel" for the design, but only to check the design is not possible to get this feel. For software, constructing such a model is neither possible. We only build the product itself. Even if the formal software verification can be automatically performed as the compiler, we will still go to build / test loops. Therefore, formal verification has never been much practical for the software industry. This is the reality of today's software development process. The increasing number of people and institutions are creating more complex software design. These designs will be written in some programming languages and then verify and improve by building / testing cycles. The process is easy to errors and is not particularly strict. Quite many software developers don't want to believe this is the way of operation, is also because of this, making problems more complicated. Most of the software processes are tried to separate different stages of software design to different categories. You must start the encoding after the design of the top layer is completed and freezed. Testing and debugging is only necessary to clear the construction error. The programmer is in the middle position, they are construction workers in the software industry. Many people think that if we can make programmers no longer conduct "Hacking" and build it according to the design handed to them (but also in the process, less mistakes), then software development can It has become mature and there is a true engineering discipline. However, as long as the process ignores engineering and economics facts, this is impossible. For example, any modern industry cannot endure more than 100% rework rate in its manufacturing process. If a construction worker often cannot build correct in the first time, then he will unemployment soon. But in the software industry, even if the minimum code, during the test and debugging period, it is also likely to be corrected or overwritten. In a creative process (such as: Design), we recognize this improvement is not part of the manufacturing process. No one will expect engineers to create a perfect design for the first time.
Even if she did it, she still must let it experience the improvement process, the purpose is to prove that it is perfect. Even if we have not learned anything from Japan's management methods, we should also know that due to mistakes in the process, they are not beneficial to increase productivity. We should not constantly force software development to meet the incorrect process model. Instead, we need to improve the process, making it helps rather than hindering better software. This is the "software engineering" stone test. The project is about how you implement the process, not about whether a CAD system is required to generate the final design document. About software development has an overwhelming issue, that is, everything is part of the design process. The code is a design, test, and debugging is part of the design, and we usually think is part of the design. Although the software is constructed, it is very expensive, but it is an incredible expensive. The software is very complicated, with many different design contents and the design considerations they result. The problem is that all of the different aspects are intertwinding (just like hardware engineering). We hope that the top-level designer can ignore the details of the module algorithm design. Similarly, we hope that the programmer does not have to consider the top design problem when designing the module internal algorithm. Worse, the problem in a design level invades other levels. For the success of the entire software system, the selection algorithm for a particular module may be equally important to any higher level design issues. In different aspects of software design, there is no level of importance. An incorrect design in the minimum layer module may be as fatal as the error in the highest layer. Software design must be intact and correct in all aspects, otherwise all software builded on the design is wrong. In order to manage complexity, the software is hierarchically designed. When a programmer is considering a detailed design of a module, there may be hundreds of other modules and thousands of details, he is impossible to take into account simultaneously. For example, in software design, some important content is not completely a scope of data structure and algorithm. Ideally, programmers should not have to consider these other aspects of design when designing code. However, the design is not working in this way, and the reason has also begun to become clear. The software design is only completed after it is written and tested. Test is the foundation part of design verification and improvement processes. The high-level structure is not a complete software design; it is just a structural frame for detail design. Our ability is very limited in strict verification of high-level design. The detailed design will eventually be as much as the impact caused by high-level design (or should allow this effect). Improve the various aspects of the design is a process that should penetrate throughout the design cycle. If any of the aspects of the design is frozen in the improvement process, then the final design will be bad or even unable to work, it will not feel strange. If the high-level software design can become a more stringent engineering process, then how good it is, but the real situation of the software system is not strict. The software is very complicated, it relies on too much to do something. Perhaps some hardware does not work as designers, or a library routine has a limit in a document. Each software item will encounter these kinds of problems sooner or later. These types of problems will be discovered during the test (if our test work is done, because there is no way to find them early. When they are found, the design is forced to make changes. If we are lucky, the changes to the design are topical. Often, change some important part of the entire software design (Mo's law). When a part of the impact cannot be changed due to some reason, then in addition to the impact, the other parts of the design must be damaged. This is usually caused by the "random encoding" that the manager is considered, but this is the reality of software development.
For example, in a project I have worked recently, I found a timing dependencies between the internal structure of the module A and another module B. Worse, the internal structure of the module A is hidden behind an abstract body, and the abstraction does not allow the call to the module B to be incorporated into its correct call sequence in any method. When the problem is discovered, the timing of changing the abstraction of A has been missed. As expected, what happens is to use an increasingly complex "correction" group to be in the internal design of A. When we haven't installed the version 1, it is generally in the design being recession. Every new revision is likely to destroy some old amendments. This is a regular software development project. Finally, I decided to change the design with my colleagues, but in order to get the management of the management, we have to voluntarily work hard. In any of the general scale software projects, there will be a problem like this, although people use various methods to prevent it from appearing, but still ignore some important details. This is the difference between technology and engineering. If the experience can lead us to the correct direction, this is the process. If the experience will only bring us in unknown areas, then we must use the way you use and make it better through a controlled improvement process, which is the project. Let's take a look only as a little bit of content, all the programmers know that after the encoding, the software design document will produce more accurate documentation after the encoding. The reason is now obvious. The final design of the code is the only thing that is improved during the construction / test cycle. During this cycle, the initial design remains unchanged and the number of modules and the number of programmers in the project are inversely. It will become worthless. In software engineering, we need to be excellent in all levels. We specialize in excellent top floor design. The better the initial design, the easier it will be in detail. Designers should use anything that can help. Structural chart, Booch, status table, PDL, etc. - If it can help, use it. However, we must remember that these tools and symbols are not software design. Finally, we must create a real software design and is done in a certain programming language. Therefore, when we get design, we should not be afraid to coding them. When necessary, we must be willing to improve them. So far, no design symbols can be applied to top design and detailed design. The design will eventually be expressed as code written in some programming language. This means that the top design symbol must be converted into a target programming language before the detailed design can begin. This conversion step takes time and introduces an error. Programmers are often reviewed and re-enabled by the demand, and then encoded according to their actual goes, rather than being converted from a symbol that may not be fully mapped with the selected programming language. This is also part of software development. Perhaps, if you let the designer you have written the initial code, not the designer that makes others to convert the language, it will be better. What we need is a unified symbol for each level design. In other words, we need a programming language, which also applies to capturing high-level design concepts. C can just satisfy this requirement. C is a programming language suitable for real projects, and it is also a very expressive software design language. C allows us to directly express high-level information about design components. In this way, it is more easily designed, and the design can be improved later. Since it has a more powerful type inspection mechanism, it also helps to detect errors in the design. This has produced a more robust design, actually a better engineering design. Finally, the software design must be manifested in a certain programming language and then verify and improve it through a build / test loop. Any other claims except this is completely useless. Please consider which software development tools and technologies are popular. Structured programming is considered to be creative technology in its era.
Pascal has made it popular and it has also become popular. Object-oriented design is new popular technology, and C is its core. Now, consider things that are not effective. Case tool, popular? Yes;? Not. How is the structure chart? The situation is the same. Similarly, there is a Warner-ORR diagram, Booch chart, object map, and everything you can think of. Every one has its own strength, as well as the only fundamental weakness - it is not a real software design. In fact, the only software design symbol that can be universally recognized is PDL, and it looks like what? This shows that in the common potential of software industry, it is impossible to program technology, especially the improvement of programming languages used in the software industry, and have an overwhelming importance compared to any other things in the software industry. This also shows that programmers care about design. Software developers use them when there is a more expressive programming language. Similarly, consider how the software development process changes. Once, we used the waterfall process. Now, we talk about spiral development and rapid prototypes. Although this technique is often considered "eliminating risk" and "delivery time to short products", they actually began to coding earlier in the life cycle of software. This is a good thing. This makes the building / test cycle earlier begin to verify and improve the design. This also means that the top-level software designer is likely to be detailed. As indicated above, the project is more about how to implement the process, not what is similar to what the final product looks like. In the software industry, we are close to engineers, but we need some cognitive changes. Programming and build / test loops are the center of the engineering software process. We need to manage them like this. Constructing / testing the economic law of the cycle, coupled with the fact that the software system can almost anything, so that we are completely impossible to find a general method to verify the software design. We can improve this process, but we can't leave it. Last: Any project design project is some documentation products. Obviously, the actual document is most important, but they are not the only documentation to be generated. In the end, some people will use software. Similarly, the system is likely to also require subsequent modifications and enhancements. This means that, like hardware projects, the auxiliary document has the same importance for the software project. Although the user manual, installation guide, and other documents do not directly contact, there is still two important needs to be solved using an auxiliary design document. The first use of the auxiliary document is to capture important information from the problem space, which cannot be used directly in the design. Software design needs to create some software concepts to model the concepts in the problem space. This process requires us to draw a understanding of the concept of problem space. Typically, this understanding will contain some information that will not be directly modeled to software space, but this information still contributes to designers to determine what is the essential concept and how it is best to model them. This information should be recorded somewhere, in order to prevent the model. The second important need to assist the auxiliary document is recorded for some of the designs of the design, and the content of these aspects is difficult to extract directly from the design itself. They can be both high-level aspects or low-level aspects. Many of these aspects, graphics are the best description. This makes them in the code as a comment. This is not to say that it is necessary to replace the programming language with a graphic software design symbol. This is nothing to supplement with some text descriptions to supplement the graphical design document of the hardware account. Never forget, the source code determines the real look of the actual design, not auxiliary document. Ideally, the Software Tool can be used for later processing and an auxiliary document can be generated. For this, we may expect too much.
Subtock is that programmers (or technical writers) can use some tools to extract some specific information from the source code, and then you can document this information in other ways. There is no doubt that it is difficult to maintain this document. This is another reason to support programming languages that require more expressive. Similarly, this is also a guaranteed reason why this auxiliary document is minimal and as possible in the project. Similarly, we can use some good tools; otherwise, we have to help the pencil, paper and blackboard. Summarize as follows: The actual software is running in the computer. It is a sequence of 0 and 1 stored in a certain magnetic medium. It is not a program written in C languages (or any other programming language). The list of program is a document that represents the software design. In fact, the software design is built is the compiler and connector. Build an inexpensive degree of actual software design is incredible, and it has always become more cheap with the speed of computer speed. Designing actual software is incredible, the reason is because the complexity of the software is incredible, and almost all steps in software projects are part of the design process. Programming is a design activity - a good software design process recognizes this, and when the coding is meaningful, it will not hesitate to encode. Coding It is more frequent than what we think. Typically, the process of expressing design in the code will reveal some omissions and additional design needs. The earlier this, the better the design. Because the software builds very cheap, a regular engineering verification method does not have much use in actual software development. Just build a design and test it to prove it easier, cheaper than trying. Test and debugging is the design activity - for software, they are equivalent to design verification and improvement in other engineering disciplines. Good software design process is recognized and will not try to reduce these steps. There are some other design activities - say they are high-level design, module design, structural design, architecture or so on. Good software design process is recognized and cautiously contains these steps. All design activities are interactive. Good software design process recognizes this, and when different design steps show that it is necessary, it allows design changes, sometimes even fundamental changes, Many different software design symbols may be useful - they can As a auxiliary document and tools to help simplify the design process. They are not software design. Software development is still a process, not an engineering discipline. It is mainly because lacks the stringency required in the critical process of verification and improvement. Finally, the truly improvement of software development depends on the progress of programming technology, which in turn means making progress in programming languages. C is such a progress. It has achieved explosive popularity because it is a mainstream programming language that directly supports better software design. C takes a step in the correct direction, but it also needs a greater progress. After I remember that when I review something written almost 10 years ago, I made me impressed me. The first point (also the most relevant to this book) is, today, I even convinced that I tried to explain the correctness in essence. Subsequent years, many popular software development methods have enhanced many views, which supports my belief. The most obvious (perhaps the most unimportant) is an popularity of object-oriented programming languages. Now, in addition to C , there have been many other object-oriented programming languages. In addition, there are some object-oriented design symbols, such as UML. I have been popular for object-oriented languages because they allow them to directly show the arguments of more expressive design, and now it seems a bit outdated. Reconstruction concept - reorganize code base, making it more robust and reusable - the same also as well as all aspects of design should be flexible and the arguments allowing changes in the design of the design.
Reconstruction only provides a process of improving a criterion that has been shown to be defective. Finally, there is an agile development of agile development. Although extreme programming is the most famous one in these new methods, they all have a common point: they all recognize that source code is the most important product in software development work. On the other hand, there are some views - some of which I have talked slightly in the paper - in the subsequent years, it is more important to me. The first is the importance of architecture, or top design. In the paper, I think the architecture is only a part of the design, and the architecture needs to remain variable during the construction / test cycle. This is essentially correct, but recalling, I think my idea is a bit unsatisfactory. Although the construction / test cycle may reveal the problems in the architecture, more problems are often exhibited by changing demand. In general, design software is difficult, and new programming languages, such as Java or C , as well as graphical symbols, such as: UML, there is not much help for people who don't know how to effectively use it. . In addition, once a project has built a large number of code based on a structural architecture, it is often equivalent to discarding the item and restarting, which means that the project has not appeared. Even the project and institutions have fundamentally accepted the concept of reconstruction, they are often unwilling to do something like being completely rewritten. This means that it is important for the first time, it is important to make it pair (or at least close to), and the more the project is getting bigger, the more it is. Fortunately, software design patterns help solve this problem. There are other contents, I think it is necessary to emphasize, one of them is auxiliary document, especially documentation in architecture. Although the source code is designed, it is a fearful experience that attempts to draw a frame from the source code. In the paper, I hope that some software tools can help software developers automatically maintain auxiliary document from source code. I have almost gave up this hope. A good object-oriented framework can usually describe a few pictures and a few pages of text. However, these images (and text) must focus on key classes and relationships in the design. Worse, for software design tools may become smart enough, so that these important aspects can be extracted from a large number of details of the source code, I didn't see any true hope. This means that this document must be written and maintained by people. I still think that after the source code is completed, or at least to edit the document while writing source code, it is better than writing a document before writing source code. Finally, I finally talked about C in the papers to program - and therefore is a software design - a progress in art, but it also requires greater progress. Even if I don't see any real programming progress in the language, I will challenge C popular, then today, I will think that this is even more correct than I first write it for the first time. --Jack Reeves, January 1, 2002
