Architect's code of conduct (IV)

Principles greater than personal taste

Many architects have rich experience and personal style, so that they often take personal taste as the basis for decision-making in their daily work. This may be feasible for ordinary developers, we encourage everyone to have personal characteristics, but architects should act in accordance with principles and maintain and abide by a set of universally recognized principles as a tool for judging right and wrong.

Start with "Walking skeleton"

Agile management advocates early integration. This principle works well in architecture design. In the initial stage, architects do not need to fall into certain difficulties or details. They should concatenate core modules as soon as possible and enable developers to make them simple to run. Once the skeleton is ready, then go to the fitness stage. The benefits of doing so can, on the one hand, eliminate misunderstandings between people as early as possible, and bring confidence in moving forward in the right direction.

Data is the core

Data is what everyone knows. As long as the system has valuable data, this system will have vitality. In architecture design, data is no small matter. If any data exists in the system, enough attention should be paid to it. It may be an obsolete field, however, it may one day be incorrectly referenced, or sometimes it is useful to be asked by others.

Making decisions based on ROI

Many architects think that computing and resource allocation are what PM wants to do. They have nothing to do with themselves. What they want to do is to design the optimal system. In fact, this optimization is not only the best technology. In actual projects, everyone is concerned about the optimal Roi. The boss wants to obtain products that meet the needs with the lowest investment, PM wants to release projects with the least manpower, and developers want to use lessCodeFunctions should be completed. As an architect, the input-output ratio should be an important factor in decision-making.

There are at least two optional Solutions

An experienced architect will provide multiple solutions to some key problems, analyze their advantages and disadvantages, and make a choice after making a general trade-off, this is a convincing way to explain and solve the problem.

Hardware is hard to understand

Software architects often cannot properly consider hardware factors for multiple reasons, but most of them cannot be separated from the lack of hardware. The best solution is to strengthen cooperation with infrastructure architects to jointly evaluate the architecture and design.

Architecture is trivial

Many trivial matters at the early stage of System Construction appear to architects as little things, such as unit tests, redundant library dependencies, version upgrades, and unreasonable code styles of developers, these things do not need to be solved as soon as possible. It will take several times to solve these problems in the future, and efficient architects will solve these "Trivial matters" as soon as possible"

Be alert to new technologies and not abandon old technologies easily

Many architects, including most developers, tend to pursue new technologies. However, risks and defects are hidden behind every new thing. Therefore, sufficient evaluations are required before each new technology is introduced, do not just look at the power side, but be more familiar with its potential dangers. Do not discard old technologies that have received practical tests. Some defects may be replaced by some new technologies. However, we should cherish the knowledge and maturity of these technologies, the more desirable attitude is to try to optimize it rather than discard it.

Stretch key dimensions and discover Design deficiencies

Architects prefer to design products under ideal conditions. Once an exception occurs or the data volume exceeds the assumptions made by the business party, the architecture will be exposed. Therefore, in the initial stage of the design, we can expand the key dimensions, make the runtime environment more complex, and predict more data volumes to be processed. In this way, we can find more deficiencies in the design.

Only stable problems can produce high-quality solutions

The best architect is not to solve the problem, but to work around the problem. He must be able to enclose the various software problems and draw various boundaries, ensure a stable and complete understanding of the problem. If the problem is stable, it will never bother you again after it is solved.

Responsible for decision-making

After some architects make decisions, they hand over the tasks to other developers for implementation and think that the subsequent tasks are irrelevant to themselves. In fact, making design decisions is only the initial stage of solving the problem's life cycle, to be truly responsible for decision-making, you can refer to the following methods:

• Fully understand the decision-making process. Record and communicate with each other
• Regular review of architecture decisions
• Implement architecture decisions and follow up the implementation process
• Delegate decision-making right to experts in the team

Technical Debt Repayment

In the system, there are more or less identified defects, such as low unit test coverage rate, poor testability, unsatisfactory performance, and a lot of bad code. architects often think of it as a weakness, if we want to eliminate them overnight, we should actually take them as debts and make plans and controllable to repay them. We must seize the time to repay them so that our cost and income ratio will be better.

 

Conclusion

The above code of conduct should not be recited, but be incorporated into daily work. It is a habit to say well and to succeed, only to get used to these successful practices, true success