Grow on the shoulders of giants
By the way, a friend who has been a programmer for 17 years has worked as an architect in a world-class team like HP and Amazon for 10 years, and has also been a technical leader of small and medium-sized enterprises. Using CSDN to share his work insights, summaries of success, and reflections on some failures, let us no longer step on unnecessary pits and grow on the shoulders of giants.
"Ask the problem" first, then "solve the problem"
As a programmer, I am accustomed to facing problems and eager to solve them. I rarely think about design solutions as the issuer, and rarely look at the problem comprehensively. The typical contradiction common in team projects is the contradiction between the product team and the R&D team . As a R&D team, I often complain about the unreasonable needs of the product team and the lack of technical knowledge. In fact, you can try to move your work forward , not only to design the architecture and realize the needs of the product, but also to try to realize the needs of the customers , and even discover potential needs. Don't hesitate to heal your head and feet, be eager to complete the task without looking at the problem as a whole, and ignoring potential problems, leading to conflicts in the future!
And if you become a person who asks questions in design , you will find that while asking questions , you also need the same in-depth thinking in many cases . Designing a good problem is even more difficult than solving the problem.
So, to first "ask questions" and then "solve the problem"!
In fact, even Frederick P. Brooks Jr. (the author of "The Myth of Man-Month") in the field of software development would have the same sigh.
“The hardest part of design is deciding what to design.”
-- 《The design of design》, by Frederick P. Brooks Jr.
Have the courage to say no to "evil thoughts"
Because of human greed, there are always many "evil thoughts", or human inertia, which makes the brain produce many wrong, untimely, comfortable, and unreliable "evil thoughts". For software systems, you also need to want more: more functions, better performance, better scalability, scalability, etc., but at the same time, you will also be in your own preferences, and some selfish designs ("evil thoughts" "), this requires you to say no. As a software architect, you must understand that software architecture design is a trade-off or balance . When everyone is adding things to it, the architect should be the person who says "no" .
There are many trade-offs in the software design and definition process, such as:
- The trade-off between perfecting functions and releasing as soon as possible .
- The trade-off between scalability and performance .
The CAP principle is a good guide strategy for selection
The well-known CAP principle is a good guide strategy for selection. In order to make better choices and maintain the consistency of the architectural style, the architect should define some principles of choice based on the actual needs of the system at the beginning, such as:
- Data consistency has the highest priority.
- Early release of core functions is better than full release, etc.
- Non-functional requirements determine architecture
Because software is designed to meet the functional requirements of customers , many designers may think that the architecture is determined by the functional requirements to be implemented . But in fact , it is the non-functional requirements that really determine the software architecture.
Architects should pay more attention to non-functional requirements . Common non-functional requirements include : performance , scalability , scalability, and maintainability , and even include team technical level and release time requirements . There are always many designs that can realize functions, and the most suitable design can be selected after considering non-functional requirements.
The above architecture pattern comes from the first volume of "Pattern-Oriented Software Architecture". This set of books has been a must-read classic for architects for many years . The architecture-oriented model provides a good reference and guidance for different non-functional requirements. The Micro-Kernel mode in the picture pays more attention to scalability and availability (error isolation).
"Simple" is not "easy"
Many architects are often referred to keep it simple , but sometimes we mix confuse simple and easy . Simple and easy are also two words "simple" and "easy" in English .
“Simple can be harder than complex:You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.To be truly simple, you have to go really deep.”
--SteveJobs
Some real simple methods actually come from a deeper understanding of the problem and technology . These schemes are often not easily available, superficial methods . It can be said that there is a deep skill in it.
First, let's review the proportion of cost consumption in each stage of the software life cycle . The following is an analysis report from a well-known statistical agency. We can see that the maintenance part accounts for the largest proportion , and the simplification of this part will have the most global significance.
Share the experience of architects
Once developed a device management system , mobile operators use this system to manage mobile devices and realize management functions including automatic device registration , firmware and software synchronization . These functions are accomplished through some predefined interaction protocols between the management system and the mobile device .
Telecom experts will adjust and add these interactive protocols according to business scenarios and needs . At first, an easy-to-implement method was adopted , that is, the software engineering in the team would implement the protocol as corresponding code according to the instructions of the telecommunications expert. We soon discovered that this way made our work less simple.
“I believe that the hardest part of software projects, the most common source of project failure, is communication with the customers and users of that software.”
--Martin Fowler
As software development guru MartinFowler mentioned, " communication" often is the cause of software project failure main cause.
The biggest problem with the previous project is that in the operation and maintenance phase after the system is online , telecommunications experts and development engineers will continue to communicate on new protocol modifications and additions , and their domain knowledge and vocabulary are very large. Difference , which will greatly affect the efficiency of communication.
So this period, the system's operation and maintenance (modified protocol) has become very difficult , not only protocol update on -line time is slow , and software engineering due to the telecommunications agreement limited level of understanding, a lot of problems, to be in the line actually use to be telecom Experts have found that it has caused a lot of exchanges and repetitions.
Solve the problem
In response to the problems mentioned above , we later worked with telecom experts to design a protocol design language (and provide visual tools ). This design language uses a vocabulary familiar to telecom experts. Then through a program similar to a compiler, the protocol model defined by the telecommunications expert is converted into a Java structure in memory.
In this way , the operation and maintenance of the entire project becomes simple and efficient, eliminating inefficient communication and inaccurate manual conversion.
to sum up
It can be seen initially follow the instructions telecommunications experts, direct implementation of the agreement is the easier way , but on the entire software life cycle to look at it is not a simple and efficient way.
Always keep the passion for coding
Architects are also programmers . Code is the final realization of software . Stopping programming will gradually make you forget how you feel as a programmer, and more importantly, forget the "pain" in it , which can easily lead to unrealistic designs.
You may have heard of Distinguish Engineers (such as James Gosling, the father of Java) at Amazon's senior vice president level. Their annual coding volume is also very large, often over 100,000 lines.
Take risks first, never put risks last
A very important point in architecture design is to identify possible risks , especially the risks of non-functional requirements realization .
Because of these risks, often not functional requirements, so easy to be found in the early stages , but corrected the price, usually ratio correction functional requirements are many large, and may even lead to the failure of the project, earlier we also mentioned the non-functional requirements determine Improved architecture , such as data consistency requirements , response delay requirements, etc.
We should pass prototype , or in early iterations , identify the risks, able to address the legitimate framework .
Never put the risk at the end , even if a project fails , let it fail quickly . This is also a kind of agility.
Start with thinking about "problems" instead of rushing to start with "technology"
Technicians have an innate passion for new technologies. They are always willing to learn new technologies, and they are also more passionate to use new technologies.
But it is also likely to lead to a common problem, that is, "When we have a hammer when the nail to see what is " using some of the technology is not suitable to solve the problem at hand , often lead to complicate the simple question.
A team once maintained such a simple service. At first, it was a simple service using MySQL as data storage, which was developed and maintained by a member of the team. Later, a member became interested in the new DynamoDB at that time and learned relevant knowledge.
Then something like this happened:
Replaced MySQL with DynamoDB.
Soon it was discovered that DynamoDB did not support transaction features well . At that time, there was only a client library with extremely poor performance to support things . Due to the use of the client method , a large number of additional interactions were introduced , resulting in a performance difference of up to 7 times .
Solve the problem
At this time, this student adopted the eventually consistent technology that was widely popular in the NoSQL field at that time , through a Pub-Sub message queue to achieve final consistency ( that is, when the value of an object changes, an event will be generated , and then follow the logic of this change , it will subscribe to this notification , and change its associated data , in order to achieve final agreement different data).
Since then DynamoDB not provide SQL queries as easy machine system, in order to achieve data analysis, and again the introduction of EMR / MapReduceJob.
to sum up
At this point, you can see that the same function is implemented, but the complexity has greatly increased , and the maintenance work has changed from one person to a team.
Too busy keeps you behind
For IT people, busyness has become a habit , and overtime is often talked about. The "996" work system seems to have become a symbol of company efficiency.
And in fact make you over-busy behind .
Often meet some friends, in a company day and night did a few years , I did not stay to learn a little time for yourself . A few years later, but he added the company more "loyal", but the busy work, the same time also led to not have time to update their knowledge , so that they have left behind , and even job-hopping ability and courage have lost .
Being too busy will result in no time to learn and update your knowledge . Especially in this era of rapid development, in the work experience, finding that being too busy usually brings about the following problems:
Lack of learning has led to no improvement in work ability , while the problems faced have become increasingly complex .
In terms of technology and business, there is no greater lead and can only passively catch up . Just imagine, if you have been leading the industry for five years , would you still care, do you release one month earlier by working overtime?
In turn, the above problems will cause you to be busier and less time to improve your technical skills , which will quickly form a vicious circle .
Friends who have practiced fitness know that exercise alone is not enough . Nutritional supplements and exercise are equally important.
Personal technical growth is actually the same. Practice and learning are equally important. When you work in a field for a period of time, work is mainly practice for you . As you become familiar with the field, you can learn There will be less and less technology.
Ensure sufficient study time, do not forget the original intention, maintain ingenuity
Therefore, I hope that every technician must ensure sufficient study time , otherwise it is easy to become a frog at the bottom of the well , so as to avoid falling into the vicious circle mentioned above ; I hope that the great poet Qu Yuan's verse will encourage everyone: "The road is long and long. I will search up and down"; I hope all of us can not forget our original intention and maintain our originality!