Author: Srinath Perera
As we all know, the role of the architect, is more interested in planning, rather than directing, shaping, rather than dominate, the significance of its existence, is to guide the discussion, rather than their own to dominate everything.
However, should the specific how to implement it? The authors analyzed 30 recognized architectural principles to help you solve this problem. Maybe some principles, you never heard of, but you can quickly learn to read.
I believe you learn to work together will be more effective, and perhaps also help you avoid a lot of unnecessary overtime!
At WSO2, the time I have been involved in the assessment framework for eight years. WSO2's products are very rich, such as WSO2 ESB, WSO2 API Manager and WSO2 SP are well known. In the past eight years, we have many products and features are discussed, design, improvement and redesign.
We are in the process of design software, a key point to grasp is: software architecture is not the architect responsible for the design. Our architecture is not developed by the architect, then handed over to others to implement.
Instead, the architecture of the design team responsible for the real task of writing code. Architect responsible for the design engineer to repair the structure, complete planning and improvement. Our architecture team is instructor and gatekeepers, rather than dictator.
In the short term, it is developed by an architect architecture really quick and affordable. However, in the long run, we will form a team, let them keep thinking, improve infrastructure, and from their mistakes to improve themselves.
When we focus on the team, they will naturally over time and get better. The primary task of the architecture team is: as far as possible to ensure the architecture easy to implement. In addition, the architecture review was flawed.
Architecture Review as Paul describes it: architects involved, listen for a while, make a few comments and then left. As an architect, you express their views and opinions on the architecture understandable. However, if you are careful enough and put in, your opinion might make the team feel confused, the team will not be able to determine what the correct approach in the end yes.
Next, I will be 30 architectural principles to list, some of the principles are well known, while others are from my personal experience and hard work.
The basic principle
Principle 1: KISS (the Keep the Simple IT, sutpid) and keeping everything as simple as possible, with the most simple solution to solve the problem.
Principle 2: YAGNI (you do not need it) the principle of building only when needed.
Principle 3: first learn to crawl before you learn to walk, and finally learn to run. In other words, to be able to ensure normal operation, and then optimize it to make it better, and finally gradually make it perfect. Diego dai use development, using agile development model. Formulate a development cycle (up to 2 weeks) for each function, and then continue iteration.
Principle 4: automated testing is stable, the only way to build high-quality products. Enhance creativity through automated testing, everything can be automated! In the design should carefully consider automation.
Principle 5: focus on return on investment (ROI) and the most attention on the most important place.
Principle 6: understand the user and balance resources accordingly. Most products have thousands of end-users, requires roughly 20 developers and 100 DevOps staff. Do not spend a few months to build a DevOps less likely to use user interface (they prefer the script). This is a special case Principle 5.
Principle 7: functional design and testing as independent as possible. If you take this into account, in the design of a long-term point of view, it will save a lot of trouble, or you can start testing the entire system only when all the building is completed. In addition, follow this principle, the release will be more successful.
Principle 8: alert search engines bells and whistles architecture program. We are born like very eye-catching design. If you Annaibuzhu, can be able to function and do not need too much solution is introduced into your architecture.
Feature Selection
Principle 9: Want to know exactly how users use our products is very difficult. So we have to implement MVP (minimum viable product). The core of the concept is that: first, the development of a number of use cases, complete with cases related functions involved, an immediate release product, and then optimize the product based on feedback and experience.
Principle 10: Minimize function, in case of doubt it is deleted. Many features are never used, you only need to stay for one interface can be extended.
Principle 11: listen to customers, to see what features they want.
Principle 12: When a customer requested features affect other modules, customers must have the courage and the debate. From the overall situation, try to find another way to deal with the problem. Like Fords put it, "Whenever I ask what the customer needs, they always said I need to run faster horse." Remember, you are the expert. You should dominate everything, and expertise to make the right decisions. Although the user may then some doubts, but in the end they will thank you.
Design and concurrent server
Principle 13: To know how to run a server from the hardware to the operating system until programming language. The number of calls to optimize IO is the first choice of the road you access to the best architecture.
Principle 14: follow the law Amdhal of sync. Variable data shared between threads will reduce the speed of the program. If possible, concurrent data structure, and is used only when necessary synchronization. As little as possible the use of locks. If you intend to obstruction during thread lock, make sure you know enough about the details, because there is a big risk here.
Principle 15: If your design is based on event-driven, non-blocking architecture, do not block the thread or threads to perform IO operations. Once this is done, the system will slow as a snail.
Distributed Systems
Principle 16: stateless system having a good scalability. We are here to understand and use without sharing architecture.
Principle 17: case unless you can control all the code in the client and server, the message delivery failure is inevitable. Try to reduce your system-dependent factors (such as use Principle 18).
Principle 18: embodiment idempotent operations as possible. So it is very easy to restore, you can at least ensure delivery no problem.
Principle 19: Learn CAP theorem. Scalable Affairs (distributed transactions) is difficult. Wherever possible compensation, based RDBMS transactions difficult to expand.
Principle 20: Distributed system does not support extended consensus can not perform group communication, reliable messaging cluster-wide is not supported. The maximum node limit is about eight nodes.
Principle 21: In a distributed system, it's hard to hide a distributed system delays and failures. (See distributed computing error explanation).
user experience
Principle 22: Know your users and their goal: he is a novice, expert or casual user? How much his understanding of computer science? Geeks valued extensions, developers focus on examples and scripts that person might care about the interface.
Principle 23: The best product should not require a user manual, a user should look it will be used.
Principle 24: When you can not decide between two options, not to present the problem by way of configuration options. This will give users and architects trouble. For details of how the system works, they do not understand you, how can they make a decision? The best solution is to find an effective option every time; followed by automatic choice; third option is to add configuration parameters and set reasonable defaults.
Principle 25 : Always have a reasonable configuration defaults.
26 principle: poorly designed configuration will cause trouble, always configure few examples of value.
27 principle: ask the user to configure the value of the time, users do not need to pay attention to select the value set (for example, do not ask the maximum number of cache entries to user needs, but he wanted to ask for the amount of memory cache)
Principle 28: If you find an unknown configuration, an error is thrown. Never ignore it. During commissioning, silent configuration errors we will waste a lot of modal time.
difficulty
Principle 29: to try new language is easy, but it is difficult to use properly. Unless the company is willing to set up a team of ten people a year and spend time to learn, or try not to do so. If you still did not give up, please read the five questions related to language design before making a decision.
30 principle: combination of drag and drop UI difficult to achieve, unless the team is ready to put the resources of 10 person-years, do not do it.
Finally, talk about my feelings. Ideally, it should be a platform by a plurality of orthogonal components, each component is responsible for one aspect (e.g., security, messaging, registration, mediation, analysis, etc.). The system uses these functional building will be the best.
Unfortunately, in reality, it is difficult to achieve such a state. Because in the initial state of the project, many things are uncertain, you can not do this independence, and now I think in the beginning of the appropriate repetition is necessary, when you try to eradicate them, you will find that the introduction of the new complex, distributed itself implies complex. Sometimes the cure itself more worse than the disease process.
to sum up
As an architect, we should think like gardeners, shaping, planning and removal of weeds rather than defining and building. Although in the short term, it is developed by an architect architecture really quick and affordable. However, in the long run, the team's strength is the strongest.
If you are careful enough and put in, you just point out the error, but not the Dominican cause of the error, then your opinion might make the team feel confused. One way to avoid this is to have a set of generally accepted principles that are to follow the basic points of the discussion of architecture, but also a good resource for beginners to learn architecture. So I want to be a good architect, still need a long time to hone and verification, of course, always keep learning state is also very important. When you learn more knowledge, you will be clearer framework to solve complex problems.
Thank you for patience and ability, I read La miles long-winded article
We, as a programmer, wants to become an architect, this process is long and difficult ......
Here I also share a copy of your collection of finishing Android studying architecture PDF + Video + Interview + document source notes , as well as advanced technical architecture Advanced Brain Mapping, Android interview with thematic development, advanced materials advanced architecture to help you enhance Advanced Learning , but also saves everyone time online in search of information to learn, you can also share with close friends studying together
If you have a need, you can point Like + Comment