97 notes that the software architect should know (6)

81. Careful selection of effective technologies will never be easily abandoned
A major part of the work of software architects is the selection of appropriate technologies to overcome difficulties. Carefully select familiar weapons and do not sort them easily.
Although it is risky to choose a new technology, its value is that it will often bring you a qualitative leap. However, you still need to be careful when selecting.

82. The customer is your customer!
Imagine that your customers are not your customers, but your customers are your customers. In this way, your customers will win.
For example, if you develop a website for a machine, you need to think of end users who use this website!
If your customers intentionally or unintentionally ignore the important matters that their customers value, you need to consider communicating with your customers or even giving up the project.

83. The development of things is always unexpected.
Design is a process of continuous discovery and should not begin to try to perfect the design. During the development process, there may be some minor changes constantly. Once these changes are accumulated, a major change needs to be made to the design. If we still try to maintain the design that has already gone like this, the more damage the original design.

84. Select a framework for mutual coordination
The software framework is the basis of the software system. When selecting a framework, we should not only consider the quality and characteristics of each framework, but also check whether the frameworks that constitute the system can coexist harmoniously. In addition, is it easy to add a new framework to it. That is, there is no overlap between them and an open, concise, and specialized framework is selected.
A better framework focuses on solving an independent logic domain and will not intrude into other fields that require a framework. Streamlined, inclusive, and flexible.

85. Emphasize the commercial value of the project
Stakeholders often lack the knowledge of software engineering and tell them about the software architecture. They often play a role in the architecture. Therefore, when obtaining funds for the project, efforts should be made to emphasize the commercial value of the project. Stakeholders are generally interested in the project and are more likely to reach an agreement.
Steps for building an architecture proposal as a typical commercial project:
A) form a value statement. That is, your decision summary is used to explain why the organization's business needs to adopt a specific software architecture. The focus should be on how the architecture improves productivity and business efficiency. Do not use strong technologies.
B) establish quantitative measurement standards. The more specific the quantification, the more persuasive the project will be, and the more confident the good architecture will bring great returns.
C) Let's look back at how traditional businesses are measured. It is more convincing to convert technical analysis into financial data.
D) know where to stop. Prepare a roadmap to capture the vision and clearly understand the value of each milestone. Let stakeholders decide where to stop. If each business value is significant, continuous financial support may be available.
E) find the right time.

86. Not only control code, but also control data
During the architecture planning process, data migration is often ignored by architects. Finally, data migration is often described as an aftercare remedy, and the entire process is completed manually, which is quite fragile. The management of data solutions and data content should be seamlessly integrated into the automated building and testing process as soon as possible, and the rollback function must also be provided.

87. Technical Debt Repayment
When a project has been put into practical use, there are usually two options:
A) take the right time to "do it right once", which may include refactoring and other work.
B) take the "shortcut" and enter some code to meet the current bug. You can quickly launch the modified product.
We should try our best to choose the first solution. The second solution will constantly accumulate technical debt, and the more difficult it will be to change.
However, if the time is too short, you can adopt the second solution. But after the change, you cannot stop it. In the future, you still need to consider this technical debt and clear it as appropriate.

88. Do not rush to solve
First, check whether the problem can be changed.

89. Build a ready-to-use system
We are tool makers. The system we create must help people do things. Otherwise, it will promote the meaning of existence.
"Getting started" is an easy-to-use tool.

90. find and retain passionate problem-solving persons
A good team is an important reason for project success! It is also necessary to maintain the stability of the team!
Create a healthy working environment. Good developers often get strong incentives from their recognition.
Beware of excessive criticism. excessive criticism may kill developers' creativity and reduce their productivity. You can make constructive criticism and suggestions, but do not force each solution to seem to come from you.
Operate the development team in the correct way. Team members work together to treat them equally and cultivate team spirit.

91. The software does not actually exist
Software is the virtual thing we create, which is easier to change than the counterpart in the physical world. Therefore, the product requirements may change constantly and the plan will be adjusted continuously.

92. learn new languages
The language includes various aspects, such as the language used to communicate with business personnel, the language used to communicate with programmers, and the language used to expand your knowledge.

93. There is no permanent solution
Today's solutions will surely become tomorrow's problems, and there will be no "Never-out" solutions.

94. Questions about user acceptance
To understand and measure the threats posed by the acceptance issue, and to mitigate these threats. For example, if you are looking for a project supporter who represents the interests of the user, you can directly communicate with the user and influence the user's acceptance. (Acceptance: for example, users do not want to accept a new system, and people do not want to implement a new system)

95. Important inspiration of qingtang
Qingtang is constantly refined and concentrated, and the software architecture should also learn how to make qingtang.

96. for end users, the interface is the system
To make the interface Easy to use, a good interface can help users improve productivity, so users will like our products more.
User interaction is as important as robustness and performance.

97. Excellent Software is not built, but cultivated
Starting from an early operational system, we gradually pushed it to the goal of success.