Object-oriented CSS: Team collaboration Development specification and modular division by structure

Article Introduction: Object-oriented CSS has two main principles: separate the structure from the skin,separate of the container from the content. The first principle embodied in the modular thinking is that the design of the module and the layout of the frame itself are separated, meaning that your module can not only write a style for a layout, such as micro-blog, the existence of skin-changing functions

Speaking of Modularity, perhaps the first thing we think of is programming in the module design, functional block for the unit for the program, and finally through the selection of modules and composition of the final product. It is no novelty to apply this idea to the page building. It is believed that a large number of page-building engineers have gone through several phases: the first stage is in a CSS file to the multiple pages in their own custom order from the top down style, basically do not consider there is no common style, in order to complete the design presentation as the primary purpose; The second stage is to extract common styles from different pages, such as common colors, icons, buttons, etc., to achieve the reuse of some basic elements; the third stage is to extract the common function modules, such as navigation, copyright information, etc., to realize the reuse of some common modules.

Just described the third phase of the method has included a modular thinking, many teams also have a mature modular development program. And the first time I heard of the modular build method, it was three years ago. When working in a Korean internet company, some products require a modular, generic functional module or component called UiO to achieve maximum module independence and reusability, and many colleagues in the team, like me, It is considered that this kind of working mode constrains the freedom of coding, and the excessive structure constraint decreases the work efficiency, and the products are not unified, and the whole team is not applied.

So, if we use modular construction, where is the advantage? Perhaps in the beginning of the attempt, need an adaptive process, may make the team members appear similar to what I thought before, but when everyone adapts and skilled this way of working, it will greatly improve the efficiency of the page construction.

Suppose there is a scenario where the team receives a page that is very much, a very large number of emergency projects, the first team to do so: The group leader to assign a few pages, we have to complete their respective pages, unified delivery, for different pages structure similar to the module, the careful team may agree to let someone write well, And then copy it to everyone who needs to use it, and then let everybody write down all the content on their page and finish the task. The second team divides the common or repeating modules according to all the pages in advance, and assigns them to each individual according to the module uniqueness, and someone is responsible for building the framework, creating the modules, finally merging the frames and modules, and then delivering the pages in sequential order according to the development work plan. The result is that because the second team is working together to create a single page, they can produce the first page they need as quickly as possible, and the more late it will find the more reusable modules in the page, and the last time the entire work may be half as large as the first team. The reuse of modules does not only have a significant impact on the working hours of the team, but also for downstream developers, meaning they do not need to code or recreate the same modules. In addition, there is a big gap between the amount of code that is redundant and the code extensibility of the two ways in which the product is upgraded. Furthermore, if your team is going to use the bigpipe or less development approach, CSS modularity is the best way to go with it, or it's necessary.

When deciding how to work with a modular build, it is helpful to follow certain principles for the smooth advancement of modularity.

An article on object-oriented CSS once pointed out that object-oriented CSS has two main principles: separate the structure from the Skin,separate the container from the content . The first principle is embodied in the modular thinking that can be understood as the design of the module and the layout of the framework itself separate, means your module can't just write a style for a single layout, especially if you have a skin-changing product like Weibo, and if the module needs to write a lot of different styles or even modify the structure, The production of this module is a failure; the second principle says that the layout is separated from the content, and that a location in the layout does not have to be placed in a certain content, which in turn can be understood as the flexibility and reusability of the module.

second, adhere to the team cooperation and development of normative principles. This specification can include file directory structure, file and style naming conventions, picture Sprite specifications, module partitioning, and invocation specifications, such as our specification of the depth of the file directory, common style usage rules, the module's style name uniqueness, the module filename and style name must be consistent, etc. Modules that ensure the output of all are uniform and normative.

the principle of dividing modules according to the form of structure presentation. there is a big difference between this and modular programming, usually in the programming development is divided by the function of the module, and in the page construction, sometimes the different functions of the module presents the same style, in order to achieve the maximum modular style of reuse, you can not divide the module by function, simply, Which modules look like structure, we can classify them as a module, with the example of the right side of the microblog, the "probably interested" and "recommended" modules look the same, and they are the same style modules on the left with a picture, right text, and function buttons.

The principle of modular stability. I often ask new people a question, "How do you think the code you write is high quality, better than the average person?" "Most people will answer the semantics, reduce unnecessary nesting, and keep the code as concise as possible." Semantic and code streamlining is certainly an important aspect of evaluation quality, but I think, whether the code takes into account the rationality of data traversal, whether to take into account the operability of the DOM node, whether to take into account the expansion of the damage caused by the line, more reflect the level of a page construction engineer.

The principle of adaptive module. refers to any one module, as far as possible to achieve the width and height of the adaptive, special circumstances do not set the width of the module, the adoption of this principle to make the module has a good Plug and Play function, is the efficient completion of the page mosaic important prerequisite. If each module has a width defined, you must redefine the properties of the width or margin of each module to fit the current layout on a different layout.

margin-bottom principle. in general, the layout of the Web page is from top to bottom of the flow layout (multiple column structure can also be seen in the column of the flow-style layout), so we can for each module unified preset Margin-bottom, to achieve the purpose of uniform spacing, to avoid some of the modules set up the top margin, Some modules set the bottom margin to occur. (The left and right spacing is usually set by the style of the layout frame)

In the formulation of a good team of cooperation norms, adhere to the principle, does not mean that you can completely according to your ideas start work, teamwork is multi-directional, in addition to the team internal, the support of other teams is also indispensable, so still need the following two preconditions:

The design must strictly follow the grid. the module is independent, but the final module is still nested in the layout, because our final output is a complete static page, how to separate the module in the shortest possible time, to match the designer's intentions and product requirements of the page? Grid is a quick guarantee, in a layout framework that is strictly in accordance with the grid design, the engineer only needs to set the layout frame style and the inside and outside spacing of the columns, the subsequent work only need to embed the module used by the page, then call the corresponding module's style, because of the adaptability of the module, in the case that all modules are well prepared , it usually takes only a few minutes to flatten a page.

product, design and interaction of the normative unity. It is usually easier to unify the product and the design on the module at some stage of the project, but it is not a simple matter to achieve normative unification in different stages of the same project, especially between different projects or between different products. When there is a problem with the uniformity of the specification, the modularization only stays at a certain project stage, each time adding new function, adding new content need to add new module style, portability and reusability are greatly reduced, can not play the due effect. Of course, the product is continuous change and innovation, we can not ask for a product to always follow a certain specification to design, but we should work together to seek a win-won phase of the solution. In Weibo, after a long period of efforts, especially the interactive design of product functional components of the unified, the construction of the WDL Specification library for our modular provides a great help.

According to the actual situation, to achieve all the conditions of satisfaction is often not smooth, especially the second condition of the agreement. But step back, even if the modularity in each project, each product in the long-term stability of its maximum energy, at least can be in each project task to get modularity to the team's efficiency improvement.

If through the efforts of everyone, in all conditions are met, and the modular work can be carried out in the team smoothly, we may still encounter a wide range of problems, an unavoidable problem is that the product function upgrade caused by the changes in the module, this time is to modify the original module or another new module? The second is the degree of division of the module, sometimes from the module of the rendering and functional division are relatively vague, sometimes some of the content is divided into public style or module, or the unique content of the page is a matter of opinion; Three is the classification of the module, what kind of way to find the classification? Similar to these problems there are many, in different projects and situations, the need for concrete analysis of specific issues, to play the wisdom of the team, to find the most reasonable response plan.

While there may be problems and resistance to teamwork in the implementation process, you will love it when you get used to the way the modular team works. And when your team finishes every job efficiently, people fall in love with your team!