97 notes that the software architect should know (1)

 

1. Customer requirements over resumes

Do not select a new technology to solve problems in order to learn new knowledge or enrich your resume. Try to select a suitable technology to solve customers' problems.

If you are down-to-earth and considerate of the customer, choosing the right solution can reduce the pressure on the project, make the team more happy, and make the customer more satisfied, in this way, you will have more time to learn new knowledge.

 

2. Simplify fundamental complexity and eliminate occasional complexity

The fundamental complexity is the complexity of the problem itself, so it cannot be avoided. Incidental complexity is derived from the process of solving fundamental complexity, that is, the new problems brought about by the solution itself.

For example, a software framework designed to solve a problem, designing the framework itself is the occasional complexity introduced. Therefore, if the original problem is relatively simple, but the design or introduction of a too flexible framework may not be worth the candle. (Avoid over-design)

 

3. The key issue may not be technical.

Simple projects may also have problems. This is not because we have chosen a language or system, but the root cause is "people"

Therefore, it is necessary to help the team complete the project, communicate with the project members more, and correct the incorrect working methods of the team members in a timely manner.

Communication skills:

A) do not regard conversations as confrontation

If you change your mindset, discover the advantages of others, and consider communication as a matter of consultation, you will gain some benefits and avoid introducing the other party's alert.

B) do not communicate with people with emotions

When you are in an angry, frustrated, or worried mood, the other party may mistakenly think that your behavior is unfriendly.

C) try to set a common goal through communication

 

4. Focus on communication and adhere to concise and clear expressions and enlightened leadership style

Architects should avoid the disadvantages of giving only numbers to developers. Let developers understand the blueprint and decision-making process of the project, let everyone verify your architecture, and let developers participate in the formulation process of your architecture, in this way, developers are more willing to execute.

Architects should improve their communication skills to help you quickly and accurately understand the project objectives. To be concise and concise, use simple charts to express your thoughts.

I used a camera to take pictures of my thoughts on drawing on the whiteboard when I showed my team members. After the meeting, I shared my thoughts with you and sorted them out.

 

5. The architecture determines the performance

If there is a problem with the architecture, optimization is not enough to achieve the desired performance. Identify performance bottlenecks and optimization bottlenecks. If necessary, redesign the internal logic and deployment policies of the architecture.

 

6. Analyze the meaning behind customer requirements

Analyze the customer's requirements and why the customer raises such requirements. That is to say, we need to know the true meaning of the features and requirements required by the customer, so that we can take a simpler approach when achieving the customer's goal.

 

7. Standing up

Standing up and speaking are very important when many people make comments, especially when others are sitting. When the website was established, an authority and self-confidence were virtually added, making it easy to control scenes. The audience will not interrupt your speech easily.

When standing up, you can make better use of your body language. When there are more than 10 people, you can stand up and make a speech to keep yourself in touch with each audience. The role of eye contact and body language expressions in communication cannot be underestimated. The standing speech also makes it easier to control the tone, tone, speed, and voice, so that the voice can be further transmitted. When talking about the key points, pay attention to the slow speed of speech, and voice-speaking skills can also improve the communication effect.

 

8. faults will eventually occur

To prevent errors in program a, program B is added. However, errors may occur in program B itself. Therefore, faults and errors cannot be avoided, that is, preventive measures should be taken to prevent errors.

 

9. We often ignore the fact that we are negotiating.

Project investors may remove "things" to cut the budget ". When investors ask, "Do we really need this ?" Many engineers place themselves in the positions of engineers and answer some alternatives that do not use these items, but these alternatives are often very poor. In the investor's opinion, there are other options. He doesn't care about the solutions, and he will often ask you to remove these "things ".

In this case, we should put ourselves on the negotiator's point of view to explain the disadvantages of not using this scheme and the advantages of using it. Let investors clearly understand the importance of this solution.

 

10. Demand quantification

"Fast" and "responsive" cannot count the demand, and the demand must be quantifiable. For example, the response time is within Ms. If you do not have these numbers, you must have a description range, such as the upper limit and lower limit.

 

11. One line of code is more valuable than the 500 lines of architecture description

Remember that our goal is to work with code. design is just a means. Many architects are often attracted by abstract architectures and are addicted to the design process. Without a perfect design, the design is gradually improved in the implementation process. If you have the opportunity to develop it yourself, cherish this opportunity.

 

12. There are no applicable solutions

There is no general solution, and the problem is also very different. architects need to use situational awareness to solve the problem (similar to common sense ). Situational awareness needs to be developed and trained, and architects must continuously accumulate cases and experience to establish sufficient situational awareness. It usually takes ten years to solve system-level problems.

 

13. Pay attention to performance issues in advance

Perform performance tests as early as possible. If the Performance drops sharply at a time, it is easier to find out which changes caused the performance decline. If two weeks are used as an iteration cycle, the start time of performance testing should not be later than the third iteration. Especially for systems with demanding performance requirements, the verification will be subject to the timely delivery of projects.

 

14. The architecture design should balance the needs of multiple parties

The software architecture includes not only system modeling, interface definition, functional modules, winning mode, and performance optimization, but also security, usability, Product Support, release management, and deployment methods of the system.

Architects should not only create practical software for users, but also balance the goals of different departments, such as the requirements of CEOS for cost control, the requirements of operation departments for easy management, and the requirements of secondary developers for easy code reading and maintenance.

 

15. it is irresponsible to submit a task rashly.

If a lot of time is required for testing and verification before code submission, developers may submit tasks rashly to save time. Once a problem occurs, it will waste a lot of time on others. Therefore, it is necessary for the architect to improve this process by introducing automatic testing and continuous integration to correct developers' behaviors.

Architects should devote themselves to improving the system production efficiency, shortening the process, shortening the development time, improving the development experience, and reducing the code building time. This will also help eliminate the idea of developers submitting tasks rashly.