Architect: A programmer who doesn't want to be an architect is not a good programmer

introduction 

A soldier who doesn't want to be a general is not a good soldier.

The dream of many programmers is to become an architect in the future.

Including when I first learned programming, I also aimed to be an architect. I felt that programmers who did not want to be architects were not good programmers, and hoped to become an excellent architect in the future. Just like Napoleon's famous saying: "A soldier who does not want to be a general is not a good soldier."

With the increase of work experience, I also began to participate in the architecture design. The more I know about architecture design, the more I feel that actually doing architecture design does not mean that you must have the title of architect.

Napoleon's famous saying, the original sentence is "Every French soldier carries a marshal's baton in his knapsack", which means "every soldier should have a marshal's baton in his knapsack".

The marshal's scepter means the overall situation and the way of thinking of the marshal. When a soldier has the marshal's scepter in his backpack, it means that the soldier can also have a big picture in his chest, have a marshal's thinking, and understand what the marshal is thinking on a specific battlefield, so that he can better execute orders and improve the overall combat effectiveness.

In fact, Napoleon's original intention was to encourage every soldier who went to the battlefield to have an overall view and the thinking of a marshal. It does not require everyone to be a general or a marshal.

This also applies to the technical field. For programmers, it does not mean that they must have the title of an architect, but they have a big picture in mind and the thinking of an architect, so that they can understand architecture design and write good programs. .

What is architect thinking?

Architecture design is to control the complexity of technology. For architects, there are several effective ways to control technical complexity: abstraction, divide and conquer, reuse and iteration.

Architect thinking is actually a collection of these kinds of thinking.

abstract thinking

Abstract thinking can be said to be the basis of the entire architecture design. Because for architectural design, it is to meet business needs, and business needs are some literal descriptions, prototypes, and UI design drawings. If these needs are finally turned into codes for machines to execute, they must be abstracted first. into a computer-recognizable model.

In fact, we are not unfamiliar with abstract thinking, because the mathematics we have learned since childhood has a lot of training in abstract thinking. For example, the problem of chicken and rabbit in the same cage we did when we were young seems very complicated, but if we can abstract the chicken into x and the rabbit into y, we can use the binary equation to list the corresponding equation to find the solution.

In software projects, when encountering similar scenarios, they will consider abstracting them and summarizing a rule and method. Sometimes even if the scenes are different, the common content can be abstracted, which can be used more conveniently.

In architecture design, abstract modeling of requirements can help us hide many irrelevant details. When designing high-level architecture, we can focus on several main models without caring about the detailed implementation in the model .

Divide and conquer thinking

One of the key points of architecture design is to divide and conquer complex systems and decompose them into small and simple parts. However, optical decomposition is not enough. At the same time, it is necessary to ensure that the decomposed parts can be integrated through the agreed protocol.

Divide and conquer thinking has many classic applications in architecture design. For example, a layered architecture isolates the UI part from its business logic part, so that the two parts can be changed independently without affecting each other. For example, UI interactive modification does not need to modify the business logic code, and the business logic part optimizes performance without modifying the UI interface. Each layer can interact through agreed methods or APIs.

There are also complex problems such as big data and high concurrency that we usually talk about, which are also solved by dividing and conquering. You must know that a single machine, no matter how you optimize its performance, has its limits. At peak times like "Double Eleven", the instantaneous traffic may be hundreds or tens of millions. It is necessary to design a reasonable strategy to divide it into different servers so that the traffic of each server will not be too large.

This kind of divide-and-conquer thinking is not only applicable to architecture, but also to ordinary programmers writing code.

For example, when some programmers write code, they like to put a lot of logic in a method or a class, which is extremely difficult to understand and maintain in the end. If they can be split into several small methods or small classes, not only the structure will be clearer, but also Easier to understand and maintain.

reuse thinking

Reuse is a very simple and effective way to improve development efficiency. By abstracting the same content, it can be reused in different scenarios.

When I was working on projects before, I accumulated some practical experience in frameworks and components, so I wanted to extract it into public code so that I can reuse it directly in the future. Later, I think these projects must be needed by many people, and it will be very practical if they can be reused. So I opened it to my GitHub , which solved the similar needs of many people, and now has more than 1,000 Stars.

Reuse thinking is also very common in daily program writing. For example, some programmers like to copy and paste code, so they often see a lot of duplicate code. If they want to modify it, they have to modify several places. If these repeated codes can be extracted into public classes or methods, a lot of duplication can be reduced, making the code more concise and easy to maintain.

iterative thinking

A good architecture design is usually not done in one step, but to meet the current business needs first, and then gradually evolve as the business changes.

Just like a business like Taobao, the architecture design behind it is not in place in one step, and it is split into many microservices. In the beginning, it was just an ordinary layered architecture. Later, as the business continued to expand, it gradually iterated into today's complex architecture.

This iterative thinking is also very important when writing programs. Because many programmers like to pursue perfection and expect to be in place in one step. However, the problem brought about by this is that the development cost will increase greatly, resulting in delays in progress. On the other hand, if the prediction of demand changes is incorrect, there will be a lot of redundant code, which is difficult to maintain later.

In fact, developers are no strangers to these thinking modes mentioned above, but they always ignore them intentionally or unintentionally in practice.

What does a good architect look like?

For programmers, it is not difficult to cultivate architect thinking. However, to be a good architect, architect thinking alone is not enough.

A good architect not only has good technology, but also understands business; he can design the architecture as a whole and realize the functions locally.

For example, if an architect with rich experience in Internet software architecture design wants to design architecture software in the construction industry, it must be difficult to design a good architecture in a short period of time, because he needs to be familiar with the business of software in the construction industry before he can Design a structure that meets the characteristics of the business.

There is a kind of architect called "PPT architect", which means that he is good at writing PPT and drawing architecture diagrams. Familiar with all kinds of popular nouns. But apart from the first-line development, little is known about the business and underlying basic knowledge. The architecture designed by such an architect is usually ungrounded, and it will be very difficult and costly to implement.

Because as an architect, if you don't write code, you can't appreciate the problems caused by poor design, and you can't make timely adjustments to the problems in the architecture.

Therefore, a good architect must be a programmer and be able to insist on being a first-line programmer. Maybe he doesn't need to write a lot of business code, but at least he must participate in part of the coding work and code review work to ensure the correct execution of the architecture.

A good architect must not only have technical depth, but also have a certain technical breadth. Because the selection of technology is usually not limited to one technology, it needs to be flexibly selected according to business characteristics and team characteristics.

Another ability of a good architect is communication ability . As a programmer, it may be good to develop your own modules, and you don't need too much communication work. But architects are different. In addition to architectural design, there is also a lot of communication work.

First of all, the architect should often deal with the product manager, repeatedly confirm the requirements, and understand the details of the requirements. Only in this way can he analyze the requirements clearly and understand various user scenarios.

Then the architecture designed by the architect must be shared with others through documents and meetings, so that others can understand the architecture and make good use of it.

Therefore, in order to become a good architect, several conditions need to be met:

- Architect thinking: have good abstract thinking, divide and conquer thinking, reuse thinking and iterative thinking;
- Understand business requirements: can understand business requirements well, and can design a good architecture according to business characteristics;
- Have rich coding skills Experience: Capabilities such as abstraction, divide and conquer, and reuse require a lot of coding practice to master; in addition, maintaining a certain amount of coding experience can also help verify architecture design; - Good communication skills: architects need to communicate and confirm requirements, and
need Let the team understand the architectural design.

With these conditions, you can become a good architect, design a good architecture, organize people and technology well, meet requirements and demand changes at low cost, and operate the system.

How to become a good architect?

There is no shortcut to becoming a good architect, and it takes more effort than ordinary programmers.

If you aspire to become an architect, my advice is:

1. To be a good programmer

Good technology is the basic condition for becoming an architect . You need to make your code easy to read, easy to extend, and reusable. In this way, a good architect's thinking can be gradually cultivated through a lot of coding practice.

2. Imitate more and learn more

At the beginning, you don't have to think about building a car behind closed doors and come up with a particularly awesome structure. On the contrary, it is better to understand the industry's mature and popular architecture first, and use it well.

Now there are many good open source projects on the Internet. These open source projects have a good architecture design. You can find a few projects related to your research direction, build them locally, and then try it yourself. It is best to create your own project. It is the simplest and most effective to develop or imitate once and learn by doing .

3. Choose a good industry and platform

In fact, software is subdivided into many industry fields. Major categories include Internet applications, enterprise applications, and game applications, and there are subdivided subcategories under the major categories. For example, enterprise applications are combined with businesses of various industries, such as construction industry software, which requires professional knowledge in the construction industry.

As I said earlier, architects must understand business and technology at the same time, and this industry knowledge cannot be accumulated in a short period of time. Therefore, if you want to be an architect, it is best to choose a suitable industry and accumulate enough industry knowledge early in an industry. When you do architecture design later, you can better design an architecture that meets the characteristics of the business.

At the same time, the business experience in these industries and the architectural experience combined with technology will also become your unique personal advantages and cannot be easily replaced.

And the platform is also very important. A good platform can give you more practice opportunities.

If you aspire to become an architect, you can't just bury your head in writing programs, but also make plans early, choose an industry and platform that suits you, and avoid detours.

Summarize

In fact, for programmers, it does not mean that they must have the title of architect, but they have a big picture in mind and the thinking of an architect. So that you can understand the architecture design and write good programs.

Architect thinking refers to having good abstract thinking, divide and conquer thinking, reuse thinking and iterative thinking.

In addition, without the title of architect, you can also do architectural design, as long as you have the ability of an architect.

A good architect needs to have:

- Architect thinking-
Understand business requirements-
Rich coding experience-
Good communication skills

If you want to become a good architect, there is no shortcut. You first need to be an excellent programmer, and then imitate and learn more about good architecture design.

Finally, it is necessary to choose a good industry and platform early, accumulate business knowledge in the industry, and obtain a large number of practical opportunities with the help of the platform.


recommended reading

Series sharing

------------------------------------------------------

------------------------------------------------------

My CSDN homepage

About me (personal domain name, more information about me)

My open source project collection Github

I look forward to learning, growing and encouraging together with everyone , O(∩_∩)O thank you

If you have any suggestions, or knowledge you want to learn, you can discuss and exchange with me

Welcome to exchange questions, you can add personal QQ 469580884,

Or, add my group number 751925591 to discuss communication issues together

Don't talk about falsehood, just be a doer

Talk is cheap,show me the code

Guess you like

Origin blog.csdn.net/hemin1003/article/details/130155785