Shulou(Shulou.com)06/03 Report--

The writer is Srinath, a scientist, software architect, and programmer working on distributed systems. He is the co-founder of the Apache Axis2 project and a member of the Apache Software Foundation. He is the co-architect of WSO2 Stream processor (wso2.com/analytics). Srinath has written two books about MapReduce and many technical articles. He got his doctorate. From Indiana University in the United States.

Through unremitting efforts, Srinath finally summed up 30 architectural principles, arguing that the role of the architect should be played by the development team itself, rather than having a dedicated architect team or department. Srinath believes that the role that an architect should play is a guide, a discussion initiator, a flower builder, not a definer and builder. In order to resolve architectural disputes and choices within the team, Srinath has developed the following 30 principles, which are widely accepted by members and become a way for novice architects to learn.

Photo by Muyuan Ma on Unsplash

basic principle

Principle 1:KISS (Keep it simple,sutpid) and keep everything as simple as possible. Solve the problem with the simplest solution.

Principle 2:YAGNI (You aren't gonna need it)-Don't do something you don't need, do it when you need it.

(editor's comment: examples of speculative development abound. Programmers said to themselves, "I'm sure I'll need this extra feature in the future, so implement it now in advance." As a matter of fact, this is the place where skills are most tested. we cannot close the door to the functions needed by YY, and we have to have an insight into the trend in terms of structure. )

Principle 3: climb, walk, run. In other words, make sure you run, then optimize to get better, and then continue to optimize to make it great. Iterate to do things, agile development ideas. For each function point, create a milestone (up to two weeks) and then iterate.

(editor's comments: quick feedback, a "slap on the head milestone" is better than no milestone.)

Principle 4: the only way to create a stable, high-quality product is to automate testing. Everything can be automated, and when you design, think about it.

(editor's comment: all automation should also consider ROI, such as for particularly volatile page layers.)

Principle 5: always want to input-output ratio (ROI). It's just worth it.

Principle 6: get to know your users and balance what you need to do based on it. Don't spend months building a devops user interface, and in the end you find out that those people only like the command line. This principle is a concrete manifestation of principle 5.

Principle 7: design and test a function as independently as possible. When you design, you should think about this one. This will solve a lot of problems for you in the long run, otherwise your function will have to wait for all the other functions of the system to be tested, which is obviously not good. With this principle, your version will be smoother.

Principle 8: don't do anything fancy. We all like high-end cool designs. In the end, we put a lot of features and solutions into our architecture, and then these things won't be used at all.

(editor's comment: does the boss like ppt? )

Function selection

Principle 9: it is impossible to predict how users will use our products. So embrace MVP (Minimal Viable Product), the minimum runnable version. The main idea is that you pick a few usage scenarios, figure it out, release it for users to use, and then decide what to do next based on experience and user feedback.

Principle 10: do as few functions as possible. When in doubt, don't do it, or even kill it. Many features are never used. At most, one extension point will be enough.

(editor's comment: the product manager may not listen, it is best to take data measurement to speak.)

Principle 11: wait until someone proposes it (unless it affects the core process, wait until it is needed).

Principle 12: sometimes you have to have the courage to say no to the client. At this point you need to find a better solution to solve the problem. Remember what Henry Ford once said: "if I ask people what they need, they will say I need a faster horse." Remember: you are the expert, you have to guide and lead. Do the right thing, not the popular thing. End users will thank you for providing them with a car.

Server-side design and concurrency

Principle 13: know how a server works, from hardware to operating system to programming language. Optimizing the number of IO calls is your preferred path to the best architecture.

Principle 14: understand the law of Amdhal synchronization. Sharing variable data between threads will slow down your program. Use concurrent data structures only when necessary, and use synchronization only when you must use synchronization. If you want to use a lock, make sure you have as little time as possible to hold the lock. If you want to do something after the lock, make sure you do what you will do in the lock.

Principle 15: if your design is a non-blocking and event-driven architecture, never block threads or do some IO operations in those threads. If you do, your system will be as slow as a mule.

Distributed system

Principle 16: stateless systems are extensible and direct. We should consider this at all times, and it is at least necessary not to create something that is not scalable and has a state.

Principle 17: make sure that the message is delivered only once, regardless of failure, which is difficult unless you want to control both the client and the server. Try to make your system lighter (use principle 18). You should know that most of the promised exactly-once-delivery systems are streamlined.

Principle 18: achieve an operation as idempotent as possible. This makes it easier to recover, and you are still in a state of at least once delivery at least once.

Principle 19: know CAP theory. Scalable transactions (distributed transactions) are difficult. If possible, use compensation mechanisms as much as possible. RDBMS transactions cannot be extended.

(editor's comment: new SQL, have a look. )

Principle 20: distributed consistency cannot be extended, group communication cannot be performed, and cluster-wide reliable communication cannot be carried out. Ideally, the maximum node is limited to 8 nodes.

Principle 21: in a distributed system, you can never avoid delays and failures.

(editor's comment: well, yes, for fail design. But you have to consider your users, your service provides SLA. Do you really need 7-24-365? )

User experience

Principle 22: know your users and be clear about their goals. Are they novice, expert or accidental users? How much they know about computer science. Geeks like extension points, developers like examples and scripts, and ordinary people like UI.

Principle 23: the best products do not require product manuals.

Principle 24: when you cannot make a decision between two choices, please do not pass this question directly to the user by providing configuration options. This can only make users more confused. If you don't have a choice as an expert, is it appropriate to give it to someone who knows less than you know? The best thing to do is to find a viable option every time; the second best way is to give the option automatically, and the third best way is to add a configuration parameter and then set a reasonable default value.

Principle 25: always set a reasonable default value for the configuration.

Principle 26: poorly designed configurations can cause some problems. You should always provide some sample values for the configuration.

Principle 27: the configuration value must be understood and filled in directly by the user. For example, users should not be allowed to fill in the maximum number of cache entries, but should be asked to fill in the maximum memory that can be used for caching.

Principle 28: throw an error if you enter an unknown configuration. Never ignore it quietly. Quietly ignoring configuration errors is often the culprit that takes hours to find bug.

A difficult question

Principle 29: dreaming of a new programming language becomes simple and straightforward, but it is often difficult to really master it. Don't change programming languages easily.

(editor's comment: "technical geeks" won't listen, so it's better to treat "personal practice" and "project adoption" separately.)

Principle 30: a complex and procrastinating interface is difficult, so don't try it unless you have a 10-person-year team.

(editor's comment: I have never believed in holistic code generation, such as MDA, or drag-and-drop modeling instead of writing code. If there are any successes, or in relatively narrow areas)

Finally, tell me how I feel. In an ideal world, a platform would be made up of multiple orthogonal components-each responsible for an aspect (for example, security,messaging,registry,mdidation,analytics). It seems that it is perfect for a system to be built like this. But unfortunately, it is very difficult for us to achieve such a state in reality. Because in the initial state of the project, a lot of things are uncertain, you can't achieve such independence, now I prefer that proper repetition is necessary at the beginning, when you try to eradicate them, you will find that new complexity has been introduced, and distribution itself means complexity. Sometimes the healing process is worse than the disease itself.

(editor's comments: different practices are adopted in different stages, and copying is often a copycat.)

Summary

As an architect, you should be like a gardener, more about pruning and weeding than defining and building, you should plan rather than direct, you should trim rather than define, discuss rather than label. Although it may feel fine in the short term, it can be beneficial to guide the team to find its own way in the long run. If you are not careful, it is easy to make architecture an empty vocabulary. For example, the designer will say that his architecture is wrong, but do not know why it is wrong. A good way to avoid this is to have a list of principles that is widely accepted as an anchor for people to discuss problems and a path for novice architects to learn.

This article is reproduced from ImportSource.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.