97 notes that the software architect should know (4)

46.
Avoid repetition
If developers copy the content in the life-saving code, this part can be simplified or even extracted.
Eliminating replication is the responsibility of architects. If there are duplicates, they should re-study the framework to create a more complete abstract mechanism.

47.
Welcome to the real world
The real world is unpredictable, and unexpected things may happen at any time, such as the cancellation of orders by the customer and delay in payment.
If the real world is troublesome, don't be afraid, don't complain, just find a solution.

48.
Take a closer look. Don't try to control everything.
We have entered the era of distributed and loose coupling. Don't think about how to control everything. This will only allow you to design a tightly coupled and fragile solution. However, it is dangerous to scatter a hand. The correct method is: Observe carefully, extract the model, and then check for verification.

49. Architects are like two gods
We must have the ability to balance the future, past, and future. Listening, observing, and opening up the mind means meeting the current needs and taking into account future development plans. That is, to make the system easy to access and ensure system security, that is, to make the design conform to the current business process, but also reflect the management's consideration for future development planning. Only by integrating different ideas and taking into account different ideas and objectives can we develop products that are all happy.

50. Architects focus on boundaries and interfaces
Separation of concerns. For architects, the difficulty lies in finding the interface needed to set the boundary. Scenario maps provide architects with a powerful tool that enables them to focus on "what should be together and what should be separated ", in this way, they can implement a smart divide-and-conquer approach through smooth communication.

51. Assist the development team
To assist the development team as much as possible within the scope of their duties, we should not just say nothing. Ensure that developers have the required skills and regularly perform training, discussion, and practice. During the selection of developers, we also try to select those who are keen on learning and have highlights. When it does not violate the overall goal of software design, developers should make their own decisions. Developers should be well protected to avoid getting them involved in too much unimportant work.

52. Record decision-making reasons
Documents that record the reasons for making decisions on the software architecture are very useful for the long term, because the architecture will not change frequently, so there is no need to spend too much maintenance effort.
It generally records the following basic questions: 1. What decisions have we made? 2. Why is this decision made? 3. What other solutions are not used? And so on.
Use: 1. communication tools 2. Transferring projects to others 3. Writing documents will also force you to clarify the reasons for such a decision and help ensure that the Foundation is solid and solid. 4. This document is a good starting point when the relevant conditions change and you need to make a new decision.

53. challenge assumptions, especially your own
"Speculation is the root cause of a mess" --- weensen's "deferred decision" Law
It is necessary to clarify some assumptions, validate the assumptions with relevant empirical data, and finally make a decision. Facts and assumptions are two pillars for building software. Ensure that the software is solid and reliable.

54. Share knowledge and experience
The software industry is still very young, and it is very important to spread experience and knowledge to achieve sustainable development.
At the individual level, it is also conducive to growth, so as to better understand and correct known knowledge and experience.

55. pattern disease
It is good to avoid over-use mode.

56. Do not abuse structural metaphor
Metaphor provides a good medium for those goals that are generally abstract, complex, and changing. Whether it is communicating with other players or discussing the overall architecture with end users, it is very attractive to find tangible objects as a metaphor for what is being built. This was very effective at the beginning. They all use a language that allows everyone to feel the right direction and keep evolving. However, metaphor is also prone to misuse.
Misuse of metaphor may allow other team members to indulge in metaphor, And the metaphor cannot fully present the problem. For example, when the business system is still being conceived, Fang shared the most optimistic possible interpretation, and did not include any necessary constraints.

57. Focus on application support and maintenance
Most architects are developed by developers rather than system administrators, so they are easy to think about from the developer's perspective. As a result, the system administrator may encounter many problems, resulting in many new problems.
You must learn to consider multiple perspectives and introduce the support owner as soon as possible so that they can participate in the planning of application support.

58. have a house
Cap theorem: in Distributed Systems, the expected three features, consistency, availability, and partition fault tolerance, cannot be obtained at the same time.
Never give up questioning, because the architecture design dogma often weakens the delivery capability from the foundation. Trade-offs are inevitable and accept some trade-offs, which often produce creative and innovative results.

59. First consider principles, principles, and analogy, and then consider personal opinions and tastes
There are many advantages to guide the creation process with principles, principles, and analogy:
A) easier to document architecture B) easier to communicate with the personal opinions and experiences of legendary architects c) Clear architecture can free architects, etc.
These benefits cannot be obtained if you blindly create an architecture based on your personal experience, opinions, and taste.
Principles and principles can also ensure architecture consistency.

60. Develop applications from the "Walking skeleton"
The "Walking skeleton" is the simplest implementation of the system. It connects all the main structural components. Then, the small and incremental data can be continuously fed back to the correct direction.

61. Data is the core
In terms of concept, data is more refined and understandable than code. Even if you look at the system from the data-oriented perspective through the structure of the underlying information, you can reduce the system to a tangible set of details. Data plays a core role in most problems, and business problems spread to code through data. Only data truly forms the core of each system.

62. Ensure a simple solution to simple problems
It sounds easy to solve simple problems. Architects often tend to experience excessive design due to their high technical skills. The architect will start from subjective judgment or potential Uncertain Demands, resulting in a strong impulse to adjust the solution. Do not try to guess the future demand. The probability of an error is 50%, and the probability of an error is 49%. Instead of making subjective guesses about future demands, we should constantly generate real demands from feedback.