Architect's code of conduct (2)

First, ensure that the solution is simple and available, and then consider versatility and reusability.

The complexity of the system is often introduced by architects based on the design of versatility and reusability. many specific problems often do not require universal and reusable solutions. If there are multiple feasible solutions that are difficult to choose from, the first simple and then General principles can become the final criteria for evaluation. When architects provide specific solutions, they do not need to exclude general purpose and flexibility. However, if they leave the specific solution too early, they will only get lost in the infinite possibilities, it is overwhelmed by complicated configuration options, overload parameter lists, lengthy interfaces, and defective abstractions. First, simply meet the requirements. When repeated requirements occur again, it is a good way to achieve reuse through refactoring.

Architects should be dedicated

Architects who have been working for a long time are often separated from the technology itself and confused in abstraction. This is very dangerous and terrible. To gain the trust of other colleagues, architects should be more familiar with the business than the business staff, be more familiar with the specific code than the development staff, and be more aware of how to test effectively than the testing staff, like the main driver of a flight, although it does not need to be operated in person, it is experienced and constantly monitors the situation. Once an exception is detected, You can take action at any time. Architects should be ultimately responsible for project delivery and quality. Architects should participate in the project as much as possible, and should not split technical decisions and upward difficulties into others. They need to adopt a more pragmatic approach, such as hands-on research or discussion with other members.

Continuous integration is an important task for architects.

Ordinary developers focus on the small modules they are responsible for. They are only responsible for a single module, while architects are responsible for the entire system, continuous integration is a good way to effectively control the entire system. Architects have the responsibility to make it run.

Avoid progress adjustment errors

Although progress assurance is the responsibility of PM, architects who have the most say in technology should stand up when a change is about to happen and carefully analyze the necessity and risks of the change, support PM decisions to the maximum extent.

Art of trade-offs

We are a system, especially an Internet system. We are not a transformer, but a system with defects but meeting the current commercial needs. Therefore, architects need the art of choice, your architecture can meet the most urgent needs with limited resources, removing things that seem glamorous but useless.

Creating Database bastion hosts

In the upper-LayerProgramDuring the design, architects usually adopt simple implementation and then gradually reconstruct the agile method. However, we need to take a more cautious attitude towards a more stable backend database, because the database is the cornerstone of the entire system, both business design and technical design must maintain its stability, which is the basis for the stability of the entire system. We often find this phenomenon. After the first version of the program is launched, the tables in the database will only be added and will not be deleted, and the redundant fields will not be deleted. Every database change will cause everyone to be nervous, this will make the database design messy.

Attaching Importance to uncertainty

A superior architecture can reduce the overall importance of design decision-making, while a poor architecture will often highlight the importance of choice. If there are two reasonable choices, the architect should stop and try to find a decision with lower importance between the two, and understand that there are other choices besides the two, which is more valuable than the decision result itself.

Do not let go of inconspicuous problems easily

Project failures or online faults are often caused by inconspicuous problems in the project process, such as some special boundary situations. These problems cannot be discovered or solved by development masters, because their attention will focus on the main contradiction, architects of the time monitoring project should assume the obligation to discover these "Small bugs.

Let everyone learn to reuse

Architects are obligated to improve the developer's awareness of reusable problem solving. For example, the above measures:

• Let everyone Reuse what they canCodeShare with others in a timely manner
• Enhance code reuse usability and avoid misuse
• Let everyone realize that the existing resources are better than their own

Moderate Degree of abstraction of architecture documents

Architects often struggle to write architecture documents. If they write too many high-level documents, they will have a space hole without practical guidance. If they write too specifically, such as specifying various UML diagrams of the class, developers are constrained. To what extent does the document need to be written, the key is to meet the needs of others. For example, the business department wants to know from the document the implementation feasibility of various system functions, therefore, your documents must reflect how the main functions are met. Testers want to know how the system is transferred and how to test the system. Therefore, your documents must reflect the running process and system testability of the main modules of the system. Developers need to know the division of the respective modules of the system and the Interaction specifications between them. Therefore, your documents must reflect modular design. PM needs to know the risks of this project. Therefore, your document should reflect the risk points identification and how to avoid them. DBAs and O & M personnel need to know the data volume and performance of the system, so they need to specify how the system responds to the situation of large data volume. The key point is that the architect does not design for the purpose of design, but wants to understand why others need to read your documents and how to meet others' needs.

First try and then make a decision

There are many decision-making points in the design. Many architects like to make decisions based on experience in the ivory tower. I feel that this is what architects need to do. In fact, such an approach will often make you very passive. It is better to delay decision-making and throw the points for decision-making so that everyone can try it. In practice comparison, there is actually no need to make a decision, the right choice will naturally come out, which will further draw you closer and increase your enthusiasm and authority.

Master business knowledge

The role of the architect is to understand business issues, business goals, business needs, and design technical architecture to meet them. Understanding the business domain knowledge will help architects select an appropriate architecture model and better develop future expansion plans.

Coding is a design category

many people often compare software development to traditional industries and coding to a production process. Therefore, many front-line developers call themselves code workers, and many architects think that the same is true, developers are used as production tools to achieve their own design. In fact, coding should belong to the design category as opposed to the traditional industry. The real production process is actually the compilation, construction and release process completed by tools. The architect should regard coding as a design point. There are still many design points to be dug from the design on paper to the code after coding. The same output may come from a completely different coding, the value of the finished software is also completely different.