Evolutionary architecture and emergent design: Using reusable code, part 1th

Introduction: After identifying idiomatic patterns in your code, the next step is to accumulate and use them. Understanding the relationship between design and code facilitates the discovery of reusable code. This period of evolution architecture and emergency design explore the relationship between code and design, the importance of using expressive language, and reconsider the potential value of abstract style.

As you know from previous installments in this series, my view is that each part of the software includes reusable blocks of code. For example, the way a company handles security may be consistent across an entire application or even in multiple applications. This is an example of what I mean by idiomatic patterns. These patterns represent common solutions to the problems encountered when building specific parts of the software. There are two types of idiomatic patterns:

Technical patterns-including transactions, security, and other infrastructure elements.

Domain mode-a solution that includes business problems within a single application or across multiple applications.

In previous installments, I focused most of my attention on discovering these patterns. However, after discovering patterns, you must be able to take advantage of them as reusable code. In this article, I'll look at the relationship between design and code, especially how expressive code makes it easier to accumulate patterns. You'll see that sometimes by changing the abstract style, you can solve some seemingly intractable design problems and simplify the code.

Design is code

As early as 1992, Jack Reeves wrote an incisive paper titled "What is Software." In this article, he compares traditional projects (such as hardware and structural engineering) with software "Engineering" to remove quotes from the Word project for software developers. This paper draws some interesting conclusions.

Reeves first observed that the final deliverables of a project were "some kind of document". Structural engineers who design bridges will not deliver real bridges. The final result is the design of a bridge. The design was then passed on to a construction team that built the real bridge. What are the similar design documents for the software? Is it the graffiti on the napkin, the sketch on the whiteboard, the UML diagram, the sequence diagram, or other similar artifacts? These are all part of the design, and they are still not enough to make the manufacturing team do what's actually going on. In software, the manufacturing team is the compiler and the deployment mechanism, which means that the complete design is the source code-the complete source code. Other artifacts can only help with creating code, but the end result is the source code itself, which means that the design in the software cannot be separated from the source code.

Reeves the next point of view is about manufacturing costs, manufacturing costs are usually not part of the project, but are part of the overall cost estimate of the workpiece. Building physical entities is more expensive, which is usually the most expensive part of the entire production process. On the contrary, as Reeves said:

“... Software is cheap to build. It's as cheap as it is free. ”

Remember, when saying this, he is going through the C + + compile and link phase, which is very time-consuming. Now, in the Java™ field, there are teams popping up all the time to implement your design! Software builds are now so cheap that they can be almost ignored. Compared with the traditional engineers, we have a huge advantage. Traditional engineers would also like to be able to build their designs for free and perform hypothetical analysis of the game. Can you imagine? If bridge engineers were able to test their designs in real time, and if they were free, then the bridges would be exquisite.

Manufacturing is so easy, which explains why there is not so much mathematical rigor in software development. To achieve predictability, traditional engineers have developed mathematical models and other cutting-edge technologies. Software developers do not need that level of rigorous analysis. It is easier to build and test a design than to build a formalized proof of its behavior. Testing is the engineering rigor of software development (engineering rigor). This has also led to one of the most interesting conclusions in Reeves's paper:

If software design is fairly easy to prove and can be built for free, then it is no surprise that software design will become extremely large and complex.

In fact, I think software design is the most complex thing that human beings have ever tried, especially in the context of the growing complexity of the software we build. Given that software development has become mainstream for about 50 years, the complexity of the usual enterprise software is staggering.