Software Thinking Series Deng Hui 12/24/2004 Introduction People's Software Development Activities have been made for decades, and many other traditional industries are still very young. In order to obtain a productive forces and other industries (such as: construction industry), there are many people who have no more people who have not stopped exploration, research and practice. One of the most far-reaching work is to learn from the "Project" in the traditional industry, and hope to produce "engineering" as the traditional industry to obtain satisfactory software productivity. However, the metaphor of "Project" did not bring expected results to the software industry, and even brought many negative impacts that were originally unexpected. Martin Folwer has done a detailed explanation in the blog named Metaphoricqustioning, and he pointed out: "Comparison with other industries, you can help us ask questions, but if you use it to prove the correctness of the program It will be very dangerous. Therefore, when we consider how to do things, we should start from the thinking software development process itself, and should not be simply based on the ratio. "
The waterfall model is a typical "project" metaphor product. It tries to divide software development activities into several clear phases, etc., and each stage is strictly implemented in this stage. The next phase of the activity can only be performed after a phase is completed. This model is built on such a assumption: you can clear all the needs at the beginning of the project and do not allow a large demand change in the later period. This assumption that the US Department of Defense is not costly, there is no project without pressing time, and it is also possible. However, with the prosperity of commercial software, this hypothesis is completely unable to set up. Because, the change is an important embodiment of customer competitiveness, and a software that cannot be quickly adapted is unable to bring expectations for customers. The waterfall model also thus exited the mainstream software development process.
Today, the variability and unpredictability of software demand have become an indisputable fact. Modern software development methods and techniques are also carried out around this. Iterative law and object-oriented are the outstanding representatives. Since the software demand is volatile, then we will no longer spend strength to stop it, but we use the attitude of hugging. We get a point of demand to quickly implement it, and make a product delivery to customers. After the customer acceptance, give more demands, we quickly implement and deliver it to customers, so loop iteration. The biggest advantage of this is that customers can get a software that can provide them with commercial value as soon as possible (although the functions may not be full) and provide real feedback as soon as possible to provide them with the most value of the next iteration. In this iterative loop, I think it is very important, one is the participation of Crack-type ON-Site customers, and one is to enable the software itself to adapt to this fast iteration technology. About On-Site Customer, XP Senior Experts Ron Jeffries has a wonderful metaphor: "Replacing a on-site customer with some case is about it." This metaphor is ON. -Site customer huge potential value. Object-oriented technology is currently using comparative technology that enables software to adapt to rapid iterations. Yes, object-oriented is born is an incremental development technology. Object-Oriented's purpose In many books and articles, object-oriented is a model of modeling tools. That is, we can use objects to represent the actual concepts and entities in the problem area, eliminating the semantic gap between problems and software representations. In these books, it is often used to use a lot of space to use objects to model real-world models. I can't say this practice is completely wrong, but according to my personal practice and research, this approach is very unpredictable. The model established from this point of view is often a very naive model, which is filled with a large number of people caused by plywood and confusion dependence network. The reason is very simple, object-oriented language is a universal language that can only describe some classic concepts. Any concept in the real world is unable to describe in object-oriented languages. For example: Simple, such as the concept of "Desk", can you write a class accurately describe it? Try it. In addition, even if we barely build a model for the problem to solve, it will also make this model no longer applicable due to the variability and inevitability of the software requirements mentioned earlier. In fact, we don't need to do this at all. What we need is to complete the functions required and ready to hug changes. Object-oriented technology is essentially a hug that hifts changes, and it hugs the way to provide more powerful information hidden and dependency management methods than processization methods. Through these means, we can make the software's particle size and dependencies; you can make more types of changes to change; you can reduce the price of changes as much as possible, so that frequent changes are possible. In the next section, I will give some views more effectively.
So what about Generic Programming, Functional Programming, and Aspect-Oriented Programmingn? In fact, they are in order to embrace different types of changes, they have added a lot of shortcomings for object-oriented in hug. For example, AOP is to supplement OO in the shortcomings of "cross-cut". In some forums, it is often related to the comparisons and debates of these different thinking models. In fact, this simple and disadvantage is very difficult. In the algorithm field, GP is definitely due to OO, FP is strong when the rule description is performed, and the infrastructure logic AOP of some systems should be slightly better. And what we face is basically not only a model of good expectations. Therefore, we only use multiple models to use multiple modes to make the most effectively hug. In other words, what we want to do is to keep the software "soft". In this way, we can shape the software into the shape of the current needs as needed, and make it gradually evolved into an elegant product. The techniques listed above are actually a means of maintaining software "softness" complementary means. If we can learn these technologies from the perspective of maintaining software "softness", it is believed to get a bigger return from these technologies.
By the way, the modes listed in the classic "Design Mode" book in GOF are actually some code softeners. Many of them are usually used in dynamic languages such as SmallTalk, Python, and Ruby. In the language of C and Java, these "techniques" have to be used in order to achieve a certain degree of flexibility (actually dynamic). Of course, the value of the mode is in communication or cannot be found out.
Two years ago, I have seen the book of "Smalltalk Best Practice Patterns", and I feel that it is a good book, but it is not understood. After two years of practice and thinking, come back to the content of the book, I think this book is what I read is the best book. Although it is a SMALLTALK language as an example, the OO recommendation given in the book is entirely applicable to other OO languages, and better than almost all books for this language. Expressions and Domain-Specific Language We have the technology that keeps the software "soft" and makes software very easy to use changes. At this time, is we satisfied? No, excellent programmers like to be lazy, they don't like to do some duplicate, boring work, although these work may be very simple, easy. They hope to put the main energy on the truly challenging work. They want to achieve higher productivity. So what should I do next?
The computer language is a universal language that cannot be simple, intuitive, and clearly describing logic in the field. One brief description in the problem area may correspond to a large number of implementation code. The root cause of this problem is because the language we use lacks expressions for the problem. We need to specifically target this field: Domain-Specific Language.
As mentioned earlier, trying to use the model of the model to directly establish a model of the problem, and the result is often a blunt model, which is not hit in front of the change. Therefore, more good practices are: Do not build a specific architecture for the current problem, but to understand the problem to be solved, gradually form an abstract, flexible metaphor. And this metaphor is guided, and a set of specific description languages for this area is gradually constructed. We no longer work hard to construct a model to solve the problem in your hand, but to construct some words, phrases, and some grammar elements that can intuitively describe issues in the problem. Solutions to them are often more intuitive, simple, and more easily inclusive. It is particularly proposed here that metaphorically sounds a feeling of unformal and unrealistic feelings, but from my personal practice, a good metaphor guide has greatly exceeded those that have formal definitions. Architecture. In the process of constructing a particular language of this field, the techniques (OO, GP, FP, AOP) mentioned earlier are very important. Because this process is also a process of frequent iterations, only in a large number of fast iterations, it can continue to get feedback; can constantly adjust their own understanding; can continue to improve metaphors; can gradually form a set of intuitive and expression DSL. This continuous evolution must be based on the technology capable of maintaining software softness, otherwise the price is expensive.
Build a system in this way, there are two good by-products: reuse and productivity. Because this DSL can be applied in other issues in the same field, it is again improved. At the same time, the improvement of expression will inevitably bring a significant increase in productivity.
Since then, build DSL, so far, the best book I have seen is "On Lisp" of Paul Graham. This technique is deep and enlightened and has a large number of examples. However, the language used in the book is LISP. Similarly, I also recommend everyone to learn Lisp language, because in Lisp contains a lot of thinking about computer science, and it is still a very beautiful language. I believe there will be many unexpected gains after you have finished learning.
(to be continued)
