Make writing a habit together! This is the third day of my participation in the “Gold Digging Day New Plan · April More text Challenge”. Click here for more details.
Srinath is a scientist, software architect, and programmer working on distributed systems. He is a co-founder of the Apache Axis2 project and a member of the Apache Software Foundation. He is the co-architect of the WSO2 stream processor.
Srinath’s tireless efforts culminated in 30 architectural design principles, in which he argued that the role of the architect should be played by the development team itself, rather than by a team or department of architects. Srinath sees the role of an architect as a facilitator, discussion initiator, and flower builder rather than definer and builder.
In order to resolve architectural disputes and decisions within the team, Srinath developed the following principles, which are widely accepted by the team members and are easy to learn if the designer has never heard of them. Some of these principles are well known, and some are hard choices for us.
The basic principle of
Principle 1: KISS (Keep it Simple, SUtPID) Keep everything as simple as possible. Solve the problem with the simplest possible solution.
Comments: Simple is complex! If you want your code to be simple and easy to understand, you need to spend more time thinking about it.
Don’t get things You don’t need, YAGNI when You need them.
Comments: Have you ever imagined that a feature might be needed in the future, and then just implemented it, but it didn’t work later, causing code redundancy? Therefore, we can’t close our doors and imagine the features we need, but we need to be architecturally aware of trends.
Rule 3: Crawl, walk, run. In other words, make it work, then optimize it to get better, and then optimize it to make it great. Iterating to do things, agile development thinking. For each function point, create milestones (up to two weeks) and iterate.
Review: Quick feedback, a head-pounding milestone is better than no milestone at all.
Principle 4: The only way to create a stable, high-quality product is to automate testing. Everything can be automated, so think about that when you’re designing.
Comments: Unit testing is necessary, but there is no consistent standard for how you should do it. At the same time, automate everything with ROI in mind, for example, for a particularly volatile page layer.
Principle 5: ROI is always worth it.
Comments: can not use technology to solve the problem, do not use technology to solve. Technology is only a solution to the problem, and technology is a relatively higher cost solution. With a hammer in your hand, don’t look at everything as nails.
Rule 6: Know your audience and balance what you need to do based on that. Don’t spend months building a Devops user interface only to find out that people only like the command line. This principle is a specific manifestation of principle 5.
Comments: whether to stand in the user’s point of view to think about the problem? Is it new technology for new technology’s sake?
Principle 7: Design and test a feature as independently as possible. When you design, you should think about this one. This solves a lot of problems for you in the long run, otherwise your functionality will have to wait until everything else in the system is ready to test, which is obviously not good. With this in mind, your version will be much smoother.
Rule 8: Beware of fancy features and design. We all love high-end cool design; In the end, we built a lot of functionality and solutions into our architecture that would never be used.
Comments: Teacher Wu Jun said in the Beauty of Data: A good method is usually the most simple and clear method. Mathematics by its very nature is simple and straightforward, and software engineering is no different.
Feature selection
Principle 9: It is impossible to predict how users will use our products. So embrace the MVP (Minimum Viable Product), the Minimum Viable version. The idea is that you pick a few scenarios, you get them out there, you put them out there, and you decide what to do based on the experience and user feedback.
Comment on:
In the Lean Startup methodology, a feedback loop of “build, measure, and learn” is proposed. That is to say, when you have a new idea, you should develop it into a product code and put it into the market. Then, you can collect data to get feedback and see whether the previous idea is sound. You get one of two outcomes: good ideas are strengthened, and bad ones are discarded. Either way, you’ll generate new ideas and move on to the next cycle. In this feedback loop, the knowledge you gain is the most important because it is validated. This is also an important concept in the Lean Startup: Validated Learning.
At the same time, Lean Startup also introduces a very important concept, the minimum viable product, which many people call the MVP. In short, do more with less.
Rule 10: Do as few features as possible. When in doubt, don’t do it, even kill it. Many features are never used. At most, an extension point is enough.
Comments: When a product manager asks us to make a new product feature, we can ask the product managers some questions to help us make sure that the requirements that the product manager has proposed are really well thought out. Remember: Don’t do anything by default until you figure out why you’re doing it. Of course, product managers may not be listening, and it’s best to use metrics.
Rule 11: Wait until asked (unless it affects the core process, do it when you need to).
Comments: Any functional requirements, unless they affect core functions, do not do them until they are needed. What we build is not up to us or product managers per se, it’s up to the users.
Rule 12: Sometimes you have to have the courage to say no. You need to find a better solution to solve it. Remember what Henry Ford once said: “If I asked people what they wanted, they would say I wanted a faster horse.” Remember: you are the expert. You have to guide and lead. Do what is right, not what is popular. The end user will thank you for giving them the car.
Comments: mining the real needs of users, for example, users say I want to eat Lanzhou noodles, do you give users to make a bowl of Lanzhou noodles? It needs to eat Lanzhou noodles because it is hungry or because it wants to eat Lanzhou noodles. If it is the former, can we give it a steamed bread to meet the needs of users and the cost is lower?
Server design and concurrency
Principle 13: Understand how services work, from hardware to operating system to your programming language. Optimizing the number of IO calls is the preferred path to optimal architecture.
Principle 14: Know Amdhal’s Law about synchronization. Sharing mutable data between threads can slow down your program. Use concurrent data structures whenever possible, but use synchronization only when necessary. Try to hold as few locks as possible. If you plan to block while holding a lock, make sure you know what you’re doing.
Principle 15: If your design is a non-blocking, event-driven architecture, never block threads or do IO operations in those threads. If you do, your system will slow down like a mule.
Distributed system
Principle 16: Stateless systems are extensible and simple. Be familiar with and use the shared-nothing architecture as much as possible.
There is no centralized storage in the shared-nothing (SN) architecture. There is no competition for resources in the whole system. Always think about that, don’t build an unscalable, stateful system, that’s the bottom line.
Principle 17: Unless you control the code on both the client and the server, it is difficult to send a message once, fail or fail. Try to design more portable systems (Principle 18). Remember, most systems that promise exactly-once-delivery have been streamlined in some way.
Principle 18: Make an operation as idempotent as possible. That way, it’s easier to recover, and you can still receive at least once delivery.
Principle 19: Understand CAP theory. Scalable transactions (distributed transactions) are difficult. Use compensation mechanisms whenever possible. RDBMS transactions are not extensible.
Principle 20: Distributed consistency does not scale, nor does it allow group communication, nor does it allow reliable cluster-wide communication.
Principle 21: In distributed systems, you can never avoid delays and failures.
Comments: Design for FAIL. But you have to consider providing SLA for your users and your service. Is 7*24*365 really necessary?
User Experience (UE)
Rule 22: Know your audience and their goals. Are they novices, experts, or casual users? The extent to which they understand computer science. Geeks love extension points, developers love examples and scripts, and ordinary people love the UI.
Principle 23: The best products do not require a manual.
Comments: We need to keep our products easy to use. Many people think that documentation is not necessary under Agile development. In fact, even under agile development, some necessary documentation is still required, such as major updates, related hardware facilities, etc.
Rule 24: When you cannot decide between two options, do not pass the problem on to the user directly by providing configuration options. This only makes the user more confused. Is it appropriate to hand it over to someone who knows less than you when you, as an expert, can’t choose? The best thing to do is to find a viable option each time; The next best thing is to give the option automatically, and the third best thing is to add a configuration parameter and then set a reasonable default value.
Rule 25: Always set a reasonable default value for the configuration.
Comments: For example, I am making an OCR model training platform, so that the little white users who do not know the algorithm can also train the AI model without writing code. In order to make the product more concise, we shield many details. We also provide advanced configurations for flexibility, such as the number of model training iterations. At the same time, we will also provide a reasonable model value, so that the model effect trained by small white users can also reach excellent.
Principle 26: Poorly designed configurations can cause some problems. You should always provide sample values for the configuration.
Comments: Judgment questions are better than multiple choice questions, multiple choice questions are better than filling in the blanks. The configuration value should be as simple as possible. Ideally, it should be determined only by whether or not.
Principle 27: The value must be understandable and directly entered by users. For example, instead of asking the user to fill in the maximum number of cached entries, you should ask the user to fill in the maximum amount of memory that can be used for caching.
Rule 28: Throw an error if an unknown configuration is entered. Never quietly ignore. Quietly ignoring configuration errors is often the culprit that takes hours to find a bug.
Hard questions
Principle 29: Dreaming of a new programming language is easy and straightforward, but it’s often hard to master. Don’t change programming languages easily.
Comments: “tech geeks” don’t listen, so let’s separate “personal cultivation” from “project adoption” solutions.
Rule 30: Complex drag-and-drop interfaces are very difficult, don’t try them unless the team is prepared to invest 10 man-years in them.
Comments: Modeling by drag and drop instead of writing code is difficult and usually requires a lot of manpower. Success, if any, has been in relatively narrow areas.
Finally, let me talk about some things that have changed my mind over time. In an ideal world, a platform would be composed of multiple orthogonal components — each responsible for one aspect (for example, security, messaging, registry, mediation, analysis). It’s as if a system is perfectly built like this.
Unfortunately, it’s hard to get there in reality. Because in the initial state of the project, a lot of things are uncertain and you can’t achieve such independence, now I tend to think that appropriate repetition is necessary at the beginning, and when you try to remove them, you will find that new complexity is introduced. Distribution itself means complexity. Sometimes the healing process is worse than the disease.
Comments: There is no silver bullet in software engineering. Different stages adopt different approaches, and copying often leads to copycat.
conclusion
As an architect, you should be like a gardener, more pruning, weeding than defining and constructing, planning rather than ordering, pruning rather than defining, discussing rather than labeling.
While it may feel fine in the short term, coaching the team to find and find their way will pay dividends in the long run.
It’s easy to let architecture become an empty word if you’re not careful. For example, a designer might say his architecture is wrong, but he doesn’t know why. One way to avoid this is to have a commonly accepted list of principles that serve as an anchor for discussion and a learning path for new architects.
30 Shared Principles for Discussing Software Architectures