97 notes that the software architect should know (2)

16. Do not die in a tree.

There is no architecture, strategy, or viewpoint that can solve all business problems. We must acknowledge that the world is chaotic, and solutions are diverse and inconsistent.

 

17. business objectives first

The architect must be a bridge between the business department and the Technical Department, take into account the interests of both parties, and use the business objectives to drive project development.

Architects should evaluate the commercial value of the project and use high ROI as a directory to avoid making incorrect technical decisions. The long-term interests of the software development team can be guaranteed only when the business team is cautious and the project development is driven by the business objectives.

In the process of software product formation, decisions need to be made continuously based on feedback. Software developers can make micro-technical decisions, and business decisions are determined by the business department.

 

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

Simply emphasizing universality without considering specific applications will lead to many confusing options and uncertainties. Redundant functions are often idle or misused. If there are multiple optional solutions, "first simple and then General"

At the beginning, the pursuit of universality in theory often leads to the departure of the solution from the actual development goal. In addition, this theoretical universality is often based on incorrect assumptions. Therefore, it is impossible to provide valuable solutions, but it will only cause problems. It can be simplified only after understanding the requirements.

 

19. architects should be dedicated

Competent architects can speak on behalf of the technical team and understand business knowledge to urge the technical team to meet business needs. In addition, we should be able to use a model to lead the team and be competent for all the work of the team, from network cabling, configuration, unit test code writing, and testing. We also need to be able to locate the problem, explain the cause of the problem to everyone, or provide a solution.

Architects should participate in the project as early as possible and work side by side with team members. The degree of attention to the details often determines the quality of the project. If you encounter a problem, do not just throw it to others. You can do your research or consult other outstanding architects.

 

20. Continuous Integration

The source code submission or change trigger tool automatically builds and tests the project and reports the results.

 

21. Avoid making progress adjustments

If you want to speed up, the progress will lead to many problems, such as poor design, poor documentation, possible quality problems, and the number of rushed code bugs will also increase significantly.

As an architect, you should avoid catching up with the schedule. If you must release it in advance, try to remove some unimportant functions and add them later.

 

22. Art of trade-offs

The fish and the bear's paw cannot have both sides. There is no perfect design: high performance, high availability, high security and high abstraction. And do not want to fulfill all the requirements.

Architecture Tradeoff analysis method (ATAM) and cost benefit analysis method (cbam) are both tools to help architects make trade-offs.

 

23. Build a database bastion host

No matter how the business develops or how the personnel changes, the data remains unchanged and will be stored forever. Therefore, creating a strong data model starts from the first day. Database errors are catastrophic. Once the data is damaged, even if the design problem of the data layer is fixed later, the lost data cannot be recovered.

To make full use of the role of a relational database and make it part of an application, you must have a profound understanding of business needs from the beginning of database construction. Although agility in common development methods has proved to be a very good method, the database design should be conservative and be carefully designed before the beginning.

 

24. Pay attention to uncertainty

During the design process, when there are multiple possible solutions, you should carefully consider which one to adopt or postpone the decision. When more information is collected, and then make better choices in the future. But it cannot be too late to use the information before it becomes invalid.

If you are still unable to decide which implementation method you want to adopt, you can use separation or encapsulation to isolate the decision-making from the decision-making code, in this way, the cost can be minimized when making changes. A superior architecture will minimize the cost of this change.

 

25. Do not let go of inconspicuous problems easily

No way: as long as there is a possibility of an error, it will certainly make an error.

Do not ignore small problems. It may be a major disaster in the future. Everyone in the team usually focuses differently. When someone asks a question, they should pay as much attention as possible.

Everyone has blind spots and deficiencies that are hard to identify and accept. When there is an "inappropriate" feeling, this feeling is magnified and valued.

 

26. Let everyone learn to reuse

Let everyone know about your framework, library, or design, and then let everyone know how to use it.

Generally, experienced people like to find existing solutions.

 

27. There is no capitalized "I" in the architecture"

Architects cannot take responsibility for themselves. When others criticize our design, they must learn to accept and learn.

To avoid believing that you are more familiar with the requirements than the customers or treat developers as resources, you must work closely with the customers. To drive the architecture, you must pay attention to teamwork. The architecture belongs to the team, check your work and reflect on yourself, and eliminate some common problems caused by "Self-Consciousness.

 

28. Use a 1,000 feet high view

To judge the quality of the software, we can't see clearly from the architecture diagram. It's too abstract. From the source code, we can easily lose ourselves and have too many details. Select a view between the two, that is, it can contain enough information, and will not be stuck in the details.

 

29. First try and then make a decision

The later the decision is made, the more information is available, but more does not mean enough. Perfect decisions can only come after the event.

Before making a decision, you can discuss the solution with the developer, and then try to make a better decision based on the results when the decision point approaches.

It seems a waste of time to try multiple solutions, but it may be the lowest cost.

 

30. Master business knowledge

Understanding the business field knowledge helps you select an appropriate architecture model and better develop future extensions to adapt to changing industrial trends. They can also use industry terms that corporate executives and users are familiar with to communicate with them.