Something the software architect should know

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.

2.Simplify underlying complexity and eliminate occasional complexity (Neal Ford)

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

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

The team works with each other to cut profits.

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.

5.Architecture determines performance (Randy Stafford)

The architecture design is also a truth.

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

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

7.Standing up speech (UDI Dahan)

The standing speech is more effective.

8.Faults will eventually occur (Michael Nygard)

Preventive measures should be designed in advance to limit faults.

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

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

10.Keith Braithwaite)

No rules.

11.One rowCodeMore valuable than the five hundred-line architecture description (Allison Randal)

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

12.There is no universal solution (Randy Stafford)

The software world has no omnipotent key.

13.Focus on performance issues in advance (Rebecca Parsons)

Expand the performance test as soon as possible.

14.Architectural Design should balance the needs of multiple parties (Randy Stafford)

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

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

Try to prevent developers from submitting tasks rashly.

16.Don't hang on a tree (Keith Braithwaite)

Provide customers with a variety of solutions.

17.Business Objective first(Dave Muirhead)

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

18.Ensure that the solution is simple and available, and then consider versatility and reusability (kevlin Henney)

19.Architects should have experienced(John Davies)

Take the lead to win the trust of colleagues.

20.Continuous Integration(DAVID Bartlett)

21.Avoid progress adjustment errors(Norman carnovale)

Refuse to adjust the project progress at any cost.

22.The art of trade-offs (Mark Richard)

The architecture cannot meet all requirements.

23.Create a database bastion host (Dan Chak))

Define the data model at the beginning.

24.Attaching Importance to uncertainty (kevlin Henney)

Delay decision-making and make constructive use of uncertainty.

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

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

26.Let everyone learn to reuse (Jeremy Meyer)

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

27.There is no capitalized "I" in the architecture"(Dave quick)

Make yourself crazy.

28.Use a 1,000 feet high view (Erik doernenburg)

Select an appropriate architecture view.

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

30.Knowledge in the business field (Mark Richard)

31.ProgramDesign is a design(Einar landre)

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

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

33.Time changes everything(Philip Nelson)

Select a job that is worth your effort.

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

35.Control Project Scale(Dave quick)

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

Don't forget your responsibilities.

37.Michael Nygard)

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

38.Michael Nygard)

But the software can.

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

40.Top performance(Craig Russell)

41.Michael Nygard)

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

42.Learning the profession of software (Mark Richard)

Peer chat is convenient.

43.The specific situation determines everything (Edward Garson)

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

Development teams should not be homogeneous.

45.Learn from architects (Keith Braithwaite)

Learn from experiences in the construction industry.

46.Niclas Nilsson)

47.Welcome to the real world (Gregor hohpe)

The real world is more complex than the software world.

48.Observe carefully and do not 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.Timothy high)

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

52.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.Sharing 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.

58.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.Start to develop applications from "Walking skeleton" (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..

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.

64.Decision Based on ROI (George malamidis)

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

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

66.At least two optional solutions (Timothy high)

67.Understand 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 for the future (Scot Mcphee)

Pay off technical debt in time.

70.Do not pursue "perfection". Just "good enough (Greg Nyberg )

Avoid over-design.

71.Be careful with "good ideas "(Greg Nyberg )

72.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 (Sam Gardiner)

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.The development of things is 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.Keith Braithwaite)

90.Find and retain the passionate problem solver (Chad la Vigne )

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

Software in the virtual world is flexible and variable.

92.Learn new languages (Burkhardt Hufnagel )

Prevent communication failures and misunderstandings.

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

94.Questions about user acceptance (Norman carnovale )

Reduces the risks caused by user acceptance issues.

95.An important revelation of qingtang (Eben Hewitt))

Software Architecture design requires continuous refinement and concentration.

96.For end users, the interface is the vinayak Hegde)

97.Good software is not built, but developed (Bill de hóra)

 

From: http://blog.csdn.net/qfkfw/article/details/5543187