When I first started my career, I was engaged in enterprise services. When I was developing components or pages under the current business and needed to express Boolean attributes, I often used CAN as a variable prefix to indicate whether a component could perform a certain type or an operation. This naming habit has stuck with me for a long time.

Until one day, WHEN I went to another company to develop drag and drop designers, I was told that although it was ok to start with CAN for Boolean, for component development, it would be better to end with able or IS. Then I looked at several well-known component libraries in the market, and they all ended in able when representing Boolean values. I silently changed the current variable.

Unfortunately, the problem and the logic behind it were not carefully analyzed. But do a thing always have a reason, even if this reason can not convince others, but at least also want to convince yourself. Now LET me analyze the similarities and differences between them.

Attribute it honestly

Let’s take a look at what can and able actually mean, and we’ll talk about it later.

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

Take editing as an example: canEdit means editable means editable. The former means to be able to achieve something, while the latter means to be able to achieve something.

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

Let’s look again at the is prefix, which is probably closer to Boolean. For example, isInternalStaff: indicates whether it is an internal employee. But again, it’s too granular to be able to express the meanings of the first two words. You can’t get any real meaning out of this variable without actually digging into the business.

Layered model

The layered pattern is the most commonly used architectural pattern. Most software systems are developed by multiple people. Systems can be layered in a way or by rules that make it easier for developers to work together. Layering achieves 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 one layer, and the upper layer can use the lower layer, but the relationship must be one-way. Circular dependencies are not allowed. Of course, from the actual analysis of the browser runtime, loading and executing JS sequentially is undoubtedly the natural application scenario of the layered pattern.

Of course, the advantages and disadvantages of the layered model are also more obvious, the advantage is undoubtedly the basis, not easy to change the separate extraction. Improve system reusability, testability. Easier to modify. And system layering is very easy to implement. But at the same time, each layer introduces additional abstractions, adds complexity to the system, potentially affects performance (a clean structure is more useful than a small performance penalty), and can lead to a certain amount of development pain.

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

efficiency

Flux architectures are like glasses: you know when you need them.

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

Another characteristic of layered mode is knowledge shielding (encapsulation). Layered mode can reduce the influence of unrelated transactions. For a mature development team, there must be talent gradient design. When the team is new, the mature layering allows the developer to use the lower level technical documentation and CV method for system development without knowing the details of the lower level. But if all the code is in one layer, everyone is working on the same problem. Although we’ve worked hard to get new people to deal with simple problems, the complexity of the calls can slow down actual development. So layering helps teams improve performance. It also plays a role in code protection.

Layering can also help you analyze actual problems. When you know who the problem belongs to, the problem has already been solved. We certainly need to have ownership, but in fact, finding people who know more about it is definitely a more effective solution.

Architecturally, we also try to solve problems from below because the underlying code has great reuse capability. The closer you get to code detail, though, the more effective the changes are and the higher the performance increase. But when it comes to system architecture, detailed solutions come last.

The actual analysis

Let’s go back to the Boolean property. Able fits into the base component design and is used to represent the capabilities that the base component has.

Can indicates permission control and is used in business blocks, leveraging underlying components but often having certain business attributes, but also distilling a common set of logic. Such as Vant address selection, there is business logic to add, delete, sort and modify the default address.

Finally, IS is suitable for business systems (pages). We can build different businesses based on different roles and so on, using basic components and business blocks. At the same time, we can also see that we should not use state management libraries such as Redux in the base components and business blocks to avoid coupling.

However, in business systems, we need to analyze whether the current code duplication is knowledge duplication. The DRY principle is cited in many team programming rules, and even in CI systems, for code duplication and forbidding you from submitting code. At this point, you also need to tell them your reason, the code is the same, but the current code does not represent the same knowledge, it is just a coincidence.

In actual project development, we can move forward by wrapping components and blocks in our code using the Components folder. After a certain stage of development, monorePO (Multi-project one warehouse management) is used to manage the current system, and finally, after stabilization, the layers are extracted to form multirepo for reuse by new projects.

Layered architecture is simple but powerful, but getting it right is not easy.

To encourage the

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

Blog address