A summary and reflection on architecture design

A recent architecture (process) design, in short, is to design a process that provides APIs that allow other programmers to move business logic gradually to another set of frameworks. In the process of completing this design, there are still many experiences and lessons, which are worth thinking and documenting. In fact, these experiences can be seen in other places, but also listen to others to share, but only "the teacher said, in my heart has Obsession Yan", only if oneself experienced, will be more profound.

This address: https://www.cnblogs.com/xybaby/p/9763030.html

Simplicity is beauty.

Zen of Python mentions simple is better than complex.

In Google BigTable paper, the most important lesson we learned are the value of simple designs.

Specifically back to the design, because these processes are asynchronous, and to ensure a certain degree of atomicity, so when the flow of interaction, the need to maintain the state will increase, the probability of the problem is greater, so that in the middle of the failure of the situation rollback will be more troublesome. In the original version of the design, the flowchart has almost a page A4 paper, by reducing unnecessary processes, the final program flowchart less than half a page of A4 paper, the most important is that the process is easier to maintain, the probability of error is lower.

Of course, the simplification of the process will actually have some impact on the final business in some exceptional cases, which is actually to consider the price/performance ratio.

The principle of the Ames Razor: Do not add entities if not necessary.

　　

Talk to people more

Although I am responsible for this work, I find it useful to discuss it with people, whether it is a veteran or a small white.

If a veteran with relevant experience, often can sharply point out the problem, such as the above mentioned process simplification, is the old finger out. If the other person is interested in the whole design, will ask why, why these can actually help themselves to think, because many times, they did not think about why. Even if the other side does not understand what I do, in the description, explain a detail of the time also often have enlightened feeling, and the small yellow Duck debugging method similar to the wonderful.

　　

Speak with the data, not the brain.

This is in fact related to the 1th, the process is simplified, some users will be affected in some cases, the product manager's first reaction is unacceptable. But in order to deal with this part of the anomaly will complicate the process, the technical side feel low cost. The final solution is a buried-point test, where the data indicates that the percentage of players affected is very small, and PM accepts a streamlined process.

Talk is cheap,show me the data!

Communicate with users to give an experiential prototype as early as possible

This process is primarily intended for use by other programs within the project, and is only discussed with the core program at the outset, and is a general discussion, resulting in a process that is not entirely realistic.

　　

Interface design pursues one take

Interfaces are important, and once delivered, they are difficult to modify.

This is presented, because the beginning of the process design can not meet certain business scenarios, resulting in the need to modify some APIs, but the previous version of the API has been used in the code, in order to modify these APIs, need to communicate with the corresponding program, we focus on the replacement, testing. Fortunately, these interfaces are still used in the internal system, not related to online business, otherwise it is difficult to modify.

　　

Good interface

Easy to Use,hard to misuse, from how to Design a good APIs and why it Matters

Present, in the process, there will be some default action, the default parameters, the principle of design is that these default values are not working properly, and absolutely can not silently work in the wrong way.

Flowchart state machine help Think and discuss

In this design, often on the flowchart, state machine in a daze, found still very useful, can help clarify ideas, found anomalies. When discussing with others, the flowchart is much more intuitive than the verbal description.

Murphy's Law

Each step should have an exception, if so it should correspond to else, even if only a log.

In a complex process system, the self-healing of the state is very important, so that even if there are some anomalies, it will work properly.

　　

Summed up the feelings of the deepest points, not very systematic.

A summary and reflection on architecture design