Recently, I have been obsessed with "modularization", including articles and PPTs, and I was forced to think about a lot of related things. To sort out my thoughts on "modularity" during this period, most of them are based on my own experience and understanding of the job of page reconstruction. There are limitations to a certain extent, and I hope that I can learn the new by reviewing the past.
"Modular" is just a trendy name for the technologies and methods we have been using in the past, just like "Ajax". However, as a trend in the development of page reconstruction, people are paying more and more attention to it, and they often talk about "modularity" unconsciously, but do you really understand what "modularization" is?
What is modularity?
There are 28 interpretations of "modularity" in CNKI. It can be seen that "modular" thinking is widely used. The closest explanation to "modularization" in page reconstruction is probably the explanation in software development.
Let’s first look at how Baidu’s entry explains “ modularity ”:
Modularization refers to the process of dividing a software system into several modules layer by layer from top to bottom when solving a complex problem. Each module completes a specific sub-function, and all modules are assembled in a certain way to form a whole to complete the functions required by the entire system. The module has the following basic attributes: interface, function, logic, and status. The function, status, and interface reflect the external characteristics of the module, and the logic reflects its internal characteristics. In software architecture, modules are units that can be combined, decomposed and replaced.
There are also quite a few related books, and interested students can search for them. It needs to be emphasized that what we are learning from is a way of thinking.
Why does page production need to be modular?
The content of the site is increasing and the code is becoming bloated, which gradually affects the client experience (mainly the opening speed) and the efficiency of maintenance. Are there any ways to solve these problems?
We can easily think of: reducing code redundancy, improving code reuse, image compression, etc., but how to achieve these? Modular thinking can be solved, which can effectively reduce code redundancy and improve code reuse. More importantly, it can support multi-person maintenance and reduce maintenance costs. CSS writing method is more flexible and can easily cause code coupling. Using modularization can also reduce coupling to a certain extent, which is also helpful for locating bugs. Therefore, we should pay more attention to and use "modular thinking" to write the site in the early stage of the site.
A considerable part of the site performance optimization we often mentioned before also involves "modularization", such as improving code reuse, improving development efficiency, etc. There are many advantages of "modularization". I will briefly list them:
Improve code reuse, improve development efficiency, reduce communication costs, reduce coupling, reduce release risks, reduce bug locating time and fix costs, increase page fault tolerance, better implement rapid iterations, and better support grayscale releases. The most important point, I think, is "improvement" Code reuse rate", which is also one of the most important features of modularity.
How to achieve "modularity"?
The main problem here is the "modularity" of HTML and CSS. We can look at how to implement skinning:
Same class name, change files (JS)
The same file, change the class name (JS)
From this we can see the interface implementation of HTML and CSS:
In order to better implement this interface, the three methods of class names introduced by CSS need to have relevant (interaction, design, page, development) conventions, rules, and specifications. For example: all current states use the same class name "nonce" , all grayed out performances use the original class name followed by "_n", the implementation of Tab, etc. With these conventions, rules, and specifications in place, HTML code can easily be templated and unified with interface specifications.
There are two misunderstandings that need to be understood first:
Modularization does not mean that it can be used in any location (modularized code segments also have applicable scope restrictions and require an environment that provides interface rules)
Modularization does not mean that it cannot be changed (modularized code segments can be modified according to actual needs)
Completely independent modules are placed in the same project. Since the project has its own performance and interactive unity, there must be similar parts between the modules. These parts can be proposed as common definitions to reduce redundancy. At this time, Coupling problems will arise, and it is impossible to be completely decoupled. Therefore, a very important point in modularization is "moderate coupling." With the public definition, it is necessary to adjust the implementation of the module style, and this adjustment will also affect the implementation of the "interface".
Since this article mainly talks about the modular way of thinking, the specific implementation details will be discussed in future articles. For related content, you can read the previously written " Modularization from IKEA Furniture Design ". Welcome to discuss together.