I understand 97 things that the software architect should know.

I saw this introduction on fenng's blog today. It feels good. I just looked for it. the book hasn't come out yet. Let's take a look at the 97 articles listed first. Although the words are very short, they still make sense .... I have written my own understanding. Although I have been in charge of several projects, I feel that there is still 108,000 miles away from the architect. I simply understood it myself. in fact, fenng's blog post is not about books, but about reading books. What is the time for everyone to study? I have been reading technical books all the time and now I have read some management questions, ideological data. technology can be followed. It is faster to keep up with your thoughts. both internal and external functions must be practiced, but they cannot be quickly achieved. In most cases, the secret can be copied into several copies for everyone to see. However, you only know your skill level. learning ability is the most important in this age .. otherwise it will be eliminated.

 

97 things software architects should know

Book Information

Http://book.douban.com/subject/4745287/

 

1.Customer requirements over resumes (Nitin borwankar)

Customer requirements are paramount. The use of new technologies to make your resume more attractive is often counterproductive.

//-----

Here we are talking about the demand. In fact, I have heard a story about how to use a large wind power fan to blow empty boxes in shanzhai, while a large company spends a lot of money and uses various technologies to judge, in fact, the effects are the same. the three elements of the software, namely time, cost, and quality, are the key to choosing a balance point.

In addition, it is better to choose the technology you can control to avoid risks.

 

2.Simplify fundamental complexity Eliminate accidental complexity (Neal Ford)

Analyzing problems is like setting up the cloud to see the moon and the water.

// In the face of business analysis, I often use the user's use case diagram to analyze the actions performed by the roles, share these actions, and refine them, analyze the relation between the entity of the entity to be operated, and obtain the view based on the entity and relation. The result is displayed to the actor to see if the entity is required by the actor, several times. first, let's get started.

 

3.The key issue may not be technical issues. (Mark ramm)

The team works with each other to cut profits.

// The technology is only one aspect that can be learned and trained. However, if the team is not harmonious, the atmosphere of mutual inclusion will not work. teams are complementary and progress together. Now is not an era of personal heroes.

 

4.Focusing on communication, adhering to concise and clear expressions and enlightened leadership style (Mark Richard)

The communication should be concise and detailed, so do not drag the water.

// If you have any questions, you will know what to do and you will be able to take action. However, there is still a person who wants to develop a strong standard for the formulation of standards. Of course, you should also listen to your opinions.

 

5.Architecture determines Performance (Randy Stafford)

The architecture design is also a truth.

// The Reinforced Concrete era is still in progress, and the performance needs to be improved. The demand must be optimized first, and the function is better than the performance. However, we must not only improve our own design, but also grasp this, after all, what I see when I work for my boss is the effect.

 

6.Analyze the meaning behind customer needs (Einar landre)

The crux of the problem. Do not be confused by superficial demands.

// Not every requirement of the customer is required. Some of them can be omitted, while others can be implemented through technology. My own principle is to implement meaningful functions, avoid the complicated features provided by the customer without practical use.

 

7.Standing speech (Udi Dahan)

The standing speech is more effective.

// This is very rare. I had an early meeting in the past and canceled it later. This is related to the domestic environment.

 

8.Faults will eventually occur (Michael Nygard)

Preventive measures should be designed in advance to limit faults.

// Faults, mainly in terms of security, as well as the stability of hardware, which are hard to avoid. However, in terms of system security, it is really time-consuming to handle injection and cross-site issues, we need to implement all the development processes, pay attention to the filtering of variables, and review the submittedCode.

 

9.We often ignore the fact that we are negotiating. (Michael Nygard)

Engineers should change roles and learn negotiation skills in a timely manner.

// For analysts or architects, it is an interface role that connects developers and demand personnel. Sometimes, the time and interests of the development team must be taken into account and negotiation is required.

 

10.Demand quantification (Keith Braithwaite)

No rules.

// Requirement sorting is very important. I use mindmanager to export the file.

 

11.One line of code is more valuable than the five hundred lines of architecture description (Allison Randal)

Code that can work is the goal, and design is only the means to achieve the goal.

// The design and implementation are equally important. The design is to achieve better, and the implementation is to verify the design. This is the process of improvement. Only after practice can there be a better design.

 

12.There is no universal solution (Randy Stafford)

The software world has no omnipotent key.

// Individual projects and personalized designs should not be considered too much, but public projects should be put forward for reuse.

 

13.Pay attention to performance issues in advance (Rebecca Parsons)

Expand the performance test as soon as possible.

// Performance tests are often ignored in small teams. This is also a big problem. What I do now is

1. Database optimization, index, table structure, SQL statement, after the design of the E-R diagram, create the relevant business view, and then fill the data for testing

2. During the deployment on the interface, JavaScript and CSS will be compressed to reduce the page size.

3. Use ajax to reduce the number of information loaded at the same time on the page

4. Perform unit tests on business logic and focus on logical Performance

 

14.The architecture design must balance the needs of multiple parties (Randy Stafford)

Balance the technical needs of the project and the business needs of relevant parties.

// Business and technical needs. One is on the project demand side and the other is on the internal team. architecture Design often follows its own skillful framework. For business needs, it mainly involves interfaces, interaction with users, and user experience. It is often necessary for internal teams to adopt a popular technology.

 

15.It is irresponsible to submit a task rashly.(Niclas Nilsson)

Try to prevent developers from submitting tasks rashly.

// Code review. Few teams in code review will do it seriously. This is very common in China. I have not done anything in the company. It is also helpless...

 

16.Don't hold a tree(Keith Braithwaite)

Provide customers with a variety of solutions.

// Solution templates are used for solutions. Solutions modified for different companies are often ignored in China. The key lies in the wine table and relationship.

 

17.Business Objective first (Davemuirhead)

Technical decisions cannot be separated from the constraints of business objectives and actual conditions.

// It is the most important thing to be online within the specified time.

 

18.First, ensure that the solution is simple and available, and then consider versatility and reusability.(Kevlin Henney)

// Weigh time, money, and energy... code refactoring is still effective only when you are physically and mentally motivated.

19.Architects should have experienced (Johndavies)

Take the lead to win the trust of colleagues.

// The technology must have been verified and proven to be feasible.

 

20.Continuous Integration (DAVID Bartlett)

// Integration. This is to constantly improve your own architecture, or the framework. You can use it easily.

 

21.Avoid progress adjustment errors (Normancarnovale)

Refuse to adjust the project progress at any cost.

// Progress adjustment often comes from the boss or the demand side, which is also helpless.

 

22.Art of trade-offs (Mark Richard)

The architecture cannot meet all requirements.

// Build your own architecture in this field based on your own direction. You can use it easily to improve work efficiency.

 

23.Creating Database bastion hosts (Dan chak)

Define the data model at the beginning.

// Database design and reuse. The database design has been carefully considered in the recent period.

 

24.Attaching Importance to uncertainty (Kevlin Henney)

Delay decision-making and make constructive use of uncertainty.

// There are too many uncertainties and the decision-making process is often not verified.

 

25.Do not let go of inconspicuous problems easily (Dave quick)

Don't forget the story of a warm boiled frog.

// There are many problems caused by small issues, which are often caused by poor SQL writing, resulting in serious performance problems.

 

26.Let everyone learn to reuse (Jeremy Meyer)

To reuse existing resources, we must first change our mindset.

// This must be good at seeing othersArticleAnd other people's code. This is a good exercise now. I prefer to look at other people's code. I especially like to visit open-source websites such as Google Code and SourceForge.

 

27.The architecture does not contain uppercase letters."I" (Davequick)

Make yourself crazy.

// If you are not arrogant, you must set a standard and a standard with a decision maker.

 

28.Use"1,000 feet high"View (Erik doernenburg)

Select an appropriate architecture view.

// Scalable view is needed, small to block view, to achieve the overall view, class diagram and E-R diagram shown

 

29.First try and then make a decision (Erik doernenburg)

// Result demonstration required for decision making

30.Master business knowledge (Mark Richard)

// The business analysis capability requires the basic class

 

31.ProgramDesign is a design (Einarlandre)

Software development is also divided into two stages: design and production.

// Design and production have not been achieved

 

32.Let developers take the lead on their own (Philip Nelson)

// It is a good idea to expand the architecture or framework.

 

33.Time changes everything (Philip Nelson)

Select a job that is worth your effort.

// Whenever you do things seriously, it will always improve.

 

34.It's too early to set up a software architecture major (Barry Hawkins)

// Can this course class be explained?

 

35.Control Project Scale (Davequick)

// The scale of the project is dominated by the demand side

 

36.Architects are not actors, but housekeepers. (Barry Hawkins)

Don't forget your responsibilities.

// You need to comprehensively consider the resource time and progress.

 

37.Software Architecture Ethics (Michael Nygard)

The architect's decision will affect many people, so be careful.

// If the project is aborted, the architect must take great responsibilities. Of course, the project manager has more responsibilities.

 

38.The skyscraper cannot be scaled. (Michael Nygard)

But the software can.

// What kind of things should be designed first, and draw a picture for you to see

 

39.The era of hybrid development is approaching (Edward Garson)

// What is hybrid development?

 

40.Top performance (Craigrussell)

// Progress, performance, and automation. A balance is required, and an important aspect cannot be emphasized.

 

41.Pay attention to the blank area in the Structural Diagram (Michael Nygard)

The blank area is "filled" with various software and "hardware ".

// It is very important to write the remarks. Some implementations require both pre-and post-conditions.

 

42.Learn the industry of software (Mark Richard)

Peer chat is convenient.

// Blow it to the person you want to listen.

 

43.The specific situation determines everything (Edward Garson)

// It can be reused if it can be reused, and the research on personalized dongxituo is carried out.

 

44.Dwarf, Genie, wizards and kings (Evan cofsky)

Development teams should not be homogeneous.

// Perform their respective duties, complement each other, and work together, but I have not yet performed this in such a team

45.Learn from architects (Keith Braithwaite)

Learn from experiences in the construction industry.

// The design mode is still used. Don't make the transition. I will have 2 to 3... Ga, often used.

46.Avoid repetition (Niclas Nilsson)

// Repeat cannot be avoided

47.Welcome to the real world (Gregor hohpe)

The real world is more complex than the software world.

// Are these functions required in the real world?>

48.Take a closer look. Don't try to control everything. (Gregor hohpe)

49.Architects are like two gods (DAVID Bartlett)

Architects should look at each other and listen to each other.

50.Architects should pay attention to boundaries and interfaces(Einar landre)

Find the boundaries of nature and divide and conquer it.

51.Assist the development team ( Timothy high)

A good team is a guarantee of success. We should try our best to help the development team.

52.Record decision reason ( Timothy high)

Record the reasons behind architecture decision making and have extremely high ROI value.

53.Challenge hypothesis,Especially your own ( Timothy high  )

Speculation is the main source of a mess. Make sure that the software foundation is solid and reliable.

54.Share knowledge and experience ( Paul W. Homer)

Helping people around us improve constantly, and they will also help us make full use of our potential.

55.Pattern disease (Chad La Vigne )

Do not let the desire to show the skill of the design model mask the pragmatic truth.

56.Do not abuse architecture metaphor (David Ing)

Do not indulge in system metaphor, but let it drag your feet.

57.Focus on application support and maintenance (Mncedisi Kasper)

Application support and maintenance should never be considered after the event.

// This is still critical. Many times I don't want to get them out of development ..

58.Have a house ( Bill de hóra)

Cherish the opportunity to weigh and win without any constraints or restrictions.

59.Principles, principles, and analogy are better than personal opinions and tastes ( Michael Harmer)

60.Slave"Walking skeleton"Start application development ( Clint shank)

Incremental cultivation of system growth starting from "Walking skeleton".

61.Data is the core (Paul W. Homer)

Understanding the system from the perspective of "data is the core" can greatly reduce the complexity of understanding..

// Data is a core issue that needs to be properly resolved and backed up

62.Make sure that simple problems are solved (Chad La Vigne )

63.The architect is a developer first (Mike Brown)

In case of trouble, the architect cannot just blow a smoke ring, but is helpless.

// Technology is your strength

64.Based on the ROI (ROI) Make a decision ( George malamidis)

65.All software systems are legacy systems ( Dave Anderson )

The software will soon become obsolete, making modifications and maintenance inevitable.

66.There must be at least two optional solutions (Timothy high)

67.Understanding the impact of changes ( Doug Crawford )

Clearly understand the types and impacts of changes.

68.You have to understand the hardware ( Kamal Wickramanayake)

Hardware capacity planning is equally important to the software architecture.

69.Now take shortcuts and pay interest in the future (Scot Mcphee)

Pay off technical debt in time.

// This is a profound understanding of the problem ....

 

70.Do not pursue"Perfect","Good enough"Just do ( Greg Nyberg )

Avoid over-design.

71.Be careful"Good idea"( Greg Nyberg )

// Some changes, and reconstruction may not have to be done immediately. If you want to test it, there is no problem at all. Otherwise, it will be finished.

72.Content is king (Zubin Wadia)

73.Architects should avoid cynicism ( Chad La Vigne  )

74.Stretch the key dimensions and discover deficiencies in the design ( Stephen Jones )

75.Architects must rely on their own programming capabilities ( Mike Brown)

76.Naming should be appropriate ( Samgardiner)

Find out what you want to do.

77.High-quality solutions for stable problems ( Sam Gardiner )

78.Tiandao reward service ( Brian Hart )

Truly do the seemingly simple tasks and stick to the promises.

79.Responsible for decision making ( Yi Zhou )

80.Abandon smart, simple ( Eben Hewitt)

81.Carefully selecting effective technologies will never be easily abandoned ( Chad La Vigne  )

82.Customers are your customers! ( Eben Hewitt)

83.Things are always unexpected ( Peter Gillard-Moss)

Design is a process of continuous exploration and experimentation in a changing world.

84.Select a framework for harmonious coexistence between each other ( Eric Hawthorne )

Beware of an all-powerful framework.

85.Focuses on the commercial value of the project ( Yi Zhou )

86.Not only control code, but also control data ( Chad La Vigne  )

87.Technical Debt Repayment ( Burkhardt Hufnagel )

Balance between speed and architecture.

88.Do not rush to solve ( Eben Hewitt)

First, check whether the problem can be changed.

89.Build a system ( Keith Braithwaite)

90.Find and retain passionate problem Releaser ( Chad La Vigne  )

91.The software does not actually exist. ( Chad La Vigne  )

Software in the virtual world is flexible and variable.

92.Learning new languages ( Burkhardt Hufnagel )

Prevent communication failures and misunderstandings.

93.There is no permanent solution ( Richard Monson-haefel)

94.Questions about user acceptance ( Normancarnovale )

Reduces the risks caused by user acceptance issues.

95.Important inspiration of qingtang ( Eben Hewitt)

Software Architecture design requires continuous refinement and concentration.

96.For end users, the interface is the system ( Vinayak Hegde)

97.Excellent software is developed instead of being built ( Bill de hóra)

 

I still don't know much about it here. Wait for the book to come out and have a good look ..................

It seems that I have read a lot of books, but I have not read them carefully.