"Anti-chaos", also known as "NTKS", is more than just a concept; it's a plan, a system, an organization, and a community. I've often mentioned "Anti-chaos" in both online and offline conversations, but I've never fully explained what it is and why it matters. This article aims to clarify these questions for those who are curious or might be interested.
Why "Anti-chaos"?
Have you ever joined a new team and found the project code to be a mess? For instance, when using Vue components, the naming conventions for components and attributes are inconsistent—some use camelCase while others use kebab-case, and sometimes both are used within the same component. Function names seem to have no correlation with their return types, or the functions do more than their names suggest, making it hard to understand their purpose at a glance. After seeing this, you can't help but think, "What terrible code! It's a disaster!"
As a newcomer, you don't want to get caught in this sea of chaos. With years of experience, you know that to improve a team, "standardization" is the first step in the first phase—setting rules and establishing guidelines. After drafting various standards and discussing them in meetings, you find that implementation doesn't lead to much improvement—people continue to code as they always have.
This reinforces your understanding of human nature—self-discipline? Forget it! Power is what truly matters! Humans make mistakes, and no matter how reliable they are, machines or programs are more dependable.
Reusability Issues
In your work, you might encounter a complex requirement. Although there are some open-source projects available, they are few and have limited scalability. To meet business needs, you often have to heavily modify them or start from scratch.
When your company or department launches a new business, you need to create a new application. In theory, much of the front-end code should be reusable, but in practice, you find yourself having to make so many changes that it becomes a frustrating task.
Front-end libraries and frameworks change rapidly. The applications you maintain are too large, and the core logic is too tightly coupled with the view layer, making it extremely difficult to upgrade the technology without causing significant disruption.
Within your company or department, multiple technology stacks are used, each with its own distinct way of working. If you're assigned to a project that uses an unfamiliar technology stack, you not only have to understand the business requirements but also spend time learning how to work with that particular stack, which can be costly in terms of time and effort.
Consider the challenge of upgrading an application from Vue 2.x to Vue 3.x. The Element UI library you're using doesn't support Vue 3.x, and the official announcement suggests that it will no longer be maintained. What do you do? Even if there were a Vue 3.x version of Element, could you migrate smoothly? How can you reduce the costs of upgrading and migrating in such situations?
The Vision of "Anti-chaos"
The issues mentioned above are common and something many of us want to avoid. The root cause of these problems can be summed up in one word—chaos. This is a state of disorder and ambiguity that leads to confusion and makes work more difficult.
The source of "chaos" is not external but internal—it stems from human nature, primarily in two aspects: collaboration and management problems caused by human flaws and the distortion of information during transmission.
Some people desire unwarranted freedom. They may ignore established norms, even if doing so is objectively inappropriate and could lead to unstable programs, difficult maintenance, or a negative team atmosphere. They prefer to do things their own way, regardless of the consequences.
Others are simply lazy, doing the bare minimum and showing no concern for the quality of their code. As long as it runs, they consider their job done, even if it reflects poorly on them. While constant reminders might improve code quality slightly, this approach is exhausting in the long run.
The software development process involves taking requirements and producing usable software that meets those requirements. This chain starts with the requirement proposer and then goes through various roles such as product, design, development, and testing.
Although the requirement proposer is the starting point, the real origin is their intent. The authenticity of this "intent" is questionable. Moreover, information inevitably gets lost during transmission, and the less capable each node in the transmission chain is, the more information is lost.
When information is input and output by each individual, it undergoes some degree of distortion due to factors such as knowledge, comprehension, and expression. To minimize this distortion, the best approach is to reduce the number of transmission links, that is, to reduce the number of participants and ensure that the requirement proposer's intent is directly transformed into usable software as much as possible.
The "chaos" in software development needs to be governed, and "Anti-chaos" is like Pangu and the axe he wields—splitting the chaos to create order.
Therefore, the purpose of "Anti-chaos" is to promote the industrialization of front-end development, making it more orderly, allowing business development to focus on business logic, and supporting new development methods and collaboration models.
The Essence of "Anti-chaos"
At the beginning of this article, I mentioned that "Anti-chaos" is:
A Philosophy: A strong dissatisfaction with the current state of disorder and confusion in front-end and related fields, and a commitment to creating an orderly environment where unnecessary or repetitive tasks are eliminated, and individuals can focus on doing what they love and what adds value to the industry.
A Plan: To share insights and provide practical tools in software design and team collaboration, especially from the perspectives of front-end engineering and application development, to help eliminate chaos.
A System: A series of measures to implement the aforementioned plan, currently including two major subsystems in front-end engineering and application development: "Fxxk Design" and "Future.js".
An Organization: Recognizing that one person, no matter how capable, cannot achieve much alone, a core team of highly like-minded and talented individuals is necessary to fulfill this mission.
A Community: A genuine desire to contribute meaningfully to the industry, embracing open-source principles, and building a high-quality open-source community led by non-profit individuals and organizations.
In essence, "Anti-chaos" is the "de facto standard" for communication between different levels and links in front-end and related fields.
Conclusion
I am a simple, straightforward male coder, not adept at writing flowery prose or creating flashy presentations. I can only use plain words to roughly outline my humble vision of "Anti-chaos".
I am aware that undertaking "Anti-chaos" is a challenging task and will likely face ridicule from many. However, I am prepared to approach it with an entrepreneurial mindset, exploring and managing it with determination and passion.
Top comments (0)