At the beginning of my career, I was engaged in enterprise services. When developing components or pages under the current business, I often used CAN as a variable prefix to indicate whether the components could perform a certain class or a certain operation when the attributes of Boolean values were needed to be expressed. This naming convention has stuck with me for a long time.

Until one day, when I was working on a drag-and-drop designer at another company, my boss told me that although it was fine to start with CAN for a Boolean value, for component development, it would be better to start with the end of ABLE or the beginning of IS. Then I looked at some of the more well-known component libraries on the market, and they all ended in able when representing Boolean values, so I silently changed the current variable.

Unfortunately, there was no careful analysis of the problem and the logic behind it. But there is always a reason to do a thing, even if this reason can not convince others, but at least to convince yourself. So let me analyze the similarities and differences between the two.

Attribute it honestly

Let’s look at the meaning of can and able, but we’ll talk about it later.

  • Can, can, can, can, can, can 2. know how to do STH. Used with the verbs feel, hear, see, smell, taste
  • Able to; To be able to; Intelligent; intelligent. talented

Take editing as an example: canEdit means editable, while Editable means editable. The former emphasizes the ability to achieve something, while the latter emphasizes the ability to achieve something.

Under the different names, we can see that the underlying logic that determines the current name is what the focus of the current work is: in the previous work, we were developing the business system, and for the business system at the time, there was a lot of permission control. In later work, we developed more configuration (base) components.

Let’s take a look at the “is” prefix, which is probably closer to the meaning of a Boolean. For example, IsInternalStaff indicates whether it is an internal employee. But again, compared to the first two words, it can mean too coarse-grained. You can’t make any real sense out of this variable without actually doing a deep analysis of the business.

Layered model

The layered pattern is the most commonly used architectural pattern. Most software systems are developed by multiple people. The system can be layered in a manner or by rules that make it easier for developers to work together. Layering realizes low coupling between layers and high cohesion within layers, which improves the maintainability of the system.

The characteristics of

As a rule, all code in a layer must belong to a certain layer, and code in the upper layer can use the next layer, but the relationship must be one-way. You cannot make circular dependencies. Of course, from the actual analysis of browser running, loading and executing JS in turn is undoubtedly the natural application scenario of layered mode.

Of course, the advantages and disadvantages of the layered model are also obvious. The advantage is undoubtedly that the basic and unchangeable ones are extracted separately. Improve the system reusability, testability. Easier to modify. At the same time system layering is very easy to implement. But at the same time, each layering introduces additional abstraction, increases the complexity of the system, and has the potential to impact performance (a clear structure is far more useful than a little performance loss), as well as lead to some development pain.

There are many variations of the layered pattern, but no matter how many layers it is divided into, the rules of its relationship to use remain the same.

efficiency

Flux architecture is like glasses: you know when you need it.

Every system has its own code architecture. But for layering, it’s great. Unless you’re doing demo testing, I would definitely recommend using a layered architecture.

Another feature of the layering pattern is knowledge masking (encapsulation). Layering reduces the impact between unrelated transactions. For a mature development team, there must be a talent gradient design. When the team enters the new situation, mature layering allows developers to use the lower level technical documentation and CV methodology to develop the system without knowing the lower level details. But if all the code is in one layer, everyone is working on the same problem. While we’ve tried hard to get new people to deal with simple problems, the complexity of the calls still slows down the actual development efficiency. So the layered model helps the team to be effective. At the same time also plays a certain role in code protection.

The layered model also helps you analyze the real problem, and when you know who the problem belongs to, the problem is more than half solved. We need ownership, of course, but in fact, finding people who understand it better is surely a more effective programme.

Architecturally, we also try to solve the problem from the lower level, because the lower level code is very reusable. Although the closer you get to the code details, the more effective the changes are, and the higher the performance gain. However, for the system architecture, the detailed solution is the last consideration.

The actual analysis

Let’s go back to the Boolean value property. ABLE is designed for use with the base component to represent the capabilities that the base component has.

CAN indicates permission control, which is used in business blocks. It makes use of the underlying components, but often has certain business attributes, but can also be refined to a common set of logic. Vant address selection, for example, has business logic for adding, deleting, sorting, and modifying the default address.

The final IS is suitable for the business system (page). We can build different businesses based on different roles and so on, using basic components and business blocks to build. We can also see that we should not use state management libraries such as Redux in the underlying components and business blocks to avoid coupling.

However, in the business system, we should analyze whether the current code repetition is the repetition of knowledge. In many team programming rules, the DRY principle is listed, and even in CI systems, code duplication is indicated and you are prohibited from submitting code. At this point, you also need to tell them why, yes, the code is the same, but the knowledge that the current code represents is not the same, it’s just a coincidence.

In real project development, we can step forward and start by wrapping components and blocks in our code using the Components folder. After a certain stage of development, the current system is managed by using monorepo (multi-project one warehouse management). Finally, after stabilization, the various levels are extracted to form a multirepo for new projects to reuse.

Layered architectures are simple and powerful, but they are not easy to use well.

To encourage the

If you think this article is good, I hope you can give me some encouragement and help star it under my GitHub blog.

Blog address