"Software Blue Collar" criticized

zhaozj2021-02-08  408

"Software Blue Collar" criticized

Writing / transparent

Ahead

In recent time, the concept of "software blue collar" was fried, even my father was worried, I asked me: "I heard that I will find some high school students to train for two months. You are not Do you want to eat? "It can be seen that although the" software blue collar "has not yet truly formed," Software Blue Collar "is early, which has been deeply rooted. However, in terms of historical experience, Chinese people are best at logical thinking, so it is also the most prone to diagnosis of language confusion. So, let go of the so-called "concept", let's scientifically look at "software blue collar".

Before starting everything, you must first explain a little background. This article will use a lot of construction science and software science, which is based on this consideration: software engineering is largely influenced by architectural science, and software is more flexible than buildings; therefore software and architecture is comparable However, the software's requirements for sensibility will be higher, and the requirements for physical quality are not as high as buildings (I think this is natural: despite Windows constantly playing patch, it is still a good software; while covering the house; There is no "patch" to appear). If you can't admit this consideration, then the following text is nonsense for you, you can't see it.

A little background

OK, now we already have a consolidation, continue. The traditional software engineering method emphasizes the "modularity" of the software. It is considered that a small number of unified modules (modules) can be constructed to build a large number of software products that are different from each other. This is the theoretical basis for software blue collars. In fact, this concept is not fresh. Since the second industrial revolution, architects began to pursue a fast, modular building approach, and have fruitful - they build exactly the same "small grid" module Countless skyscrapers. This is great achievements, and it is no wonder that software engineering experts have selected "modular" as the object of imitation. Moreover, when the software users are only very few people, this modular development method has actually played a good effect.

But do you know what is the architecture of Christopher Alexander called this modular architect from the 1970s? "Language of the language". C.alexander believes that the reason why the building is "alive" is because it consists of some specific, angry modes. Mode is similar to each other, but it is different from each other. The reason is very simple: model has customizable, and the module does not have. The exact same module must be unrelated to the specific purpose. In other words, the products built by modular methods can meet the most basic requirements, but they cannot meet the specific requirements of any person. In order to meet the requirements of a single person or a group of people, it must be customized by modeling. The mode is existing, design, building is customized. Some people will say: any substance, eventually consisting of the same module - atomic - composition. However, even two carbon atoms, they are different from each other because the electrons have quantitative. Therefore, modularity (all modules are identical) is not natural, and modeization (conceptually, there are differences in detail) is natural.

The above paragraph may be a bit too abstract, and now look at the perspective of engineering. C.alexander believes that any system must handle a problem: the internal stress of the system. People who have learned engineering have known that they must pay attention to internal stress when designing structures. If the internal stress is discovered, it will make the system more stable; if it is obliged, it will accelerate the crash of the system. In the "The Way of Architecture", C.alexander expands "inner stress" from the physical scope to psychological category, people's preferences, habits ... all belong to internal stress. If appropriate mode is used, the appropriate combination is performed, and the internal stress will get the right to discovery, thereby enhancing the stability of the system. Obviously, it is necessary to make the internal stress to obtain "justice" discovery, the building must understand the model itself, and continue to fine-tune according to the current situation in the process of implementation, otherwise it is easy to concentrate on the system crash. (Insert a paragraph here. C.alexander believes that: good mode should be internal stress in its internal processing; good mode combination should properly discovery internal stress, this point is not open - closed principle Similar? Is it a bit like a highly polymer / low coupling principle? So, all sciences are in communication; so architecture is absolutely guiding software developers.)

Then, C.alexander also refers to the relationship between design and implementation. He believes that a person with model thinking, mastering the pattern language can make a beautiful design, this design is able to meet his requirements; however, if the design is not a mode idea, there is no mode language, he can't complete Implement this design. Moreover, from the easiest way, he will use modular implementation methods to reduce the quality of the product.

Back to the topic

Summarize, I just talked about three things:

1. Modular method does not meet any person's specific requirements, only to meet the most basic requirements of everyone; the mode method is customized according to a specific requirement, so it can meet the customer's requirements.

2. Modularization method is not conducive to the inside of the system, so that the system tends to crash; moderate method is conducive to the internal stress of the system, thereby making the system adaptive ability, tend to be stable.

3. Modular implementation method reduces design quality; moderative implementation method guarantees that product quality is consistent with design quality or even higher.

I believe everyone can understand what I mean. Since the software is higher for sensibility, the modular approach is more uncomfortable for software development for physical quality, and the modular approach is more suitable for software development. On the other hand, from the narrative from me, you can also see that the model development requires developers to have a comprehensive understanding of the entire system, there is enough knowledge, the breadth and depth; and the so-called "code worker", "software blue collar" only Can make modular development, their knowledge cannot guarantee that their reality needs to make the right fine-tuning, so the modules they have developed are very easy to cause stress concentration. In architecture, the products built by modular methods can only meet the most basic requirements, which is the physical properties; and software products are lower for physical properties, and higher inductive quality requirements, modular methods construction The most basic requirements of software products can not be satisfied.

He told many architecture knowledge and finally said from the perspective of software science. We all know that the reusable modules in the software are shared by many other functional parts, that is, many features depend on the reuse module. If the multiplexed module rely on these uses its functional part, it must be unstable because the modification of any part may cause a chain reaction. Therefore, the reusable module must be dependent on the functional portion, otherwise it does not have reusable. Obviously, this is not dependent on any specific function, and the number of general modules is very small, and the design is extremely high - design STL is definitely not "software blue collar". From the conclusions above, you can know that the can be used to be extremely high, and the functional portion that is assembled with a reuse module is not reused (because it relies on a specific application). So, what should I do without a deep knowledge of the "software blue collar"? to sum up

Software engineering and architectural projects have a lot of common, I use some architectural knowledge to prove the unreasonability of "software blue collar". Of course, the word "code worker" itself has a shadow of architecture. But please pay attention to the two facts: First, the scientific and technological content in software engineering is much higher than that of civil engineering; second, the reproducibility of the software development is easy to use the machine. As a result, I am more certain: the so-called "code worker", "software blue collar" - that is, it does not have a profound professional knowledge, only the programmer of coding abilities - is unable to stay in the software industry.

Reference

"The Aion of Architecture", the original book name The Timeless Way of Building, Christopher Alexander, Chinese translation, Translation, Intellectual Property Publishing, Published in February 2002.

"Design mode", the original title Design Patterns, Eric Gamma and others, Chinese translation by Li Yingjun, etc., Machinery Industry Press published in September 2000.

Robert C. Martin, Designing Object-Oriented C Applications Using Booch Method, Addison-Wesley, 1992.

转载请注明原文地址:https://www.9cbs.com/read-636.html

New Post(0)