97 things software architects should know

Translated by a friendArticle: 97 things software architects should know

1. customer requirements are more important than personal resumes (Nitin borwankar. The use of new technologies to make your resume more attractive is often counterproductive. 2. Simplify fundamental complexity and eliminate occasional complexity (Neal Ford) analyzing problems is like setting the cloud to see the moon and the water. 3. The key issue may not be the technical consistency of the Mark ramm team. 4. Take communication as the center, adhere to the concise and clear expression and open-minded leadership style (Mark Richard) communication should be concise, detailed and appropriate, do not drag water. 5. Architecture determines Performance (Randy Stafford) the architecture design is also a truth. 6. Analyze the meaning behind customer needs (Einar landre. Do not be confused by superficial demands. 7. The standing speech (UDI Dahan) 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 switch roles and learn negotiation skills in a timely manner. 10. Keith Braithwaite has no rules. 11. One row Code The code that is more valuable than the five hundred-line architecture description (Allison Randal) can work is the goal, and the design is just a means to achieve the goal. 12. There is no universal solution (Randy Stafford) There is no omnipotent key in the software world. 13. Pay attention to performance issues in advance (Rebecca Parsons) Perform a performance test as early as possible. 14. The architecture design should 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) to try to put an end to developers' thoughts on submitting the task rashly. 16. Don't hold a tree (Keith Braithwaite) provides customers with a variety of solutions. 17. Business Objective first - Business-driven (Dave Muirhead) technical decisions cannot be separated from the constraints of business goals and actual conditions. 18. First, ensure that the solution is simple and available, and then consider versatility and reusability. (Kevlin Henney) 19. architects should take the lead of John Davies to win the trust of their colleagues. 20. David Bartlett 21. Avoid Norman carnovale's refusal to adjust the project progress at any cost. 22. The alternative art (Mark Richard) architecture cannot meet all requirements. 23. Creating Database bastion hosts (Dan Chak) data models must be defined at the beginning. 24. Pay attention to uncertainty (kevlin Henney) To postpone decision making and make constructive use of uncertainty. 25. Don't let alone the inconspicuous problem (Dave quick). Don't forget the story of the 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 upper-case I (Dave quick) in the architecture to make yourself crazy. 28. Use the "1,000 feet high" View (Erik doernenburg) to select an appropriate architecture view. 29. First try and then make a decision (Erik doernenburg) 30. Master business domain knowledge (Mark Richard) 31. Program Design is a design (Einar landre) software development is also divided into two stages: design and production. 32. let developers take the lead (Philip Nelson) 33. Time Changes Everything (Philip Nelson) to choose the jobs that are worth the effort, and don't go through with the previous jobs. 34. It's too early to set up a software architecture major (Barry Hawkins) 35. Dave quick 36. Architects are not actors, but housekeepers (Barry Hawkins) Don't forget your responsibilities. 37. Decisions made by Michael Nygard, architect of software architecture, may affect many people and must be careful. 38. The skyscraper cannot be scaled (Michael Nygard), but the software can. 39. The era of Mixed development is approaching (Edward Garson) 40. Top performance (Craig Russell) 41. Check that the blank areas in the structural diagram are "filled" with various software and hardware ". 42. Learn how to communicate with other software professionals. 43. The specific situation determines everything (Edward Garson) 44. The gnomiters, elves, wizards, and kings (Evan cofsky) development teams should not be homogeneous. 45. Learn from architects (Keith Braithwaite) from experiences in the construction industry. 46. Avoid repetition (Niclas Nilsson) 47. Welcome to the real world (Gregor hohpe). The real world is more complex than the software world. 48. Take a closer look and don't try to control everything (Gregor hohpe) 49. Architects are like David Bartlett. architects should look at things like two gods. 50. Architects should pay attention to boundaries and interfaces (Einar landre) Find the boundaries of nature and divide and conquer it. 51. Helping the development team (Timothy high) Excellent Teams is a guarantee of success. We should try our best to help the development team. 52. Record the Decision-Making reason (Timothy high) record the reasons behind the architecture decision, with 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) helps people around us improve constantly, and they will also help us to realize all our potential. 55. Chad la Vigne should not expose the desire to show the skill of the design pattern to conceal the pragmatic truth. 56. Do not abuse the architecture metaphor (David Ing). Do not indulge in the system metaphor, but drag it down. 57. Focusing on application support and maintenance (mncedisi Kasper) Application support and maintenance should never be taken into consideration afterwards. 58. Have a house (Bill de hóra) cherish the opportunity to weigh and win the game without any constraints or restrictions. 59. principles, principles, and analogy are better than personal opinions and tastes (Michael Harmer) 60. starting from "Walking skeleton" to developing applications (Clint shank), starting from "Walking skeleton" to incrementally cultivate system growth. 61. Data is the core (Paul W. Homer) to understand the system from the perspective of "data is the core", which can greatly reduce the complexity of understanding. 62. Make sure that the simple problem has a simple solution (Chad la Vigne) 63. The architect is a developer first (Mike Brown) when you are in trouble, architects can't just blow smoke circles but be helpless. 64. Decision-making based on ROI (George malamidis) 65. All software systems are legacy systems (Dave Anderson) and 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) to clearly understand the types and impacts of changes. 68. You have to understand the hardware capacity planning of the hardware (Kamal Wickramanayake), which is equally important to the software architecture. 69. take shortcuts now and pay off technical debt in time in the future (Scot McPhee. 70. Don't pursue perfection. Just "good enough" (Greg Nyberg) to avoid over-design. 71. be careful with Greg Nyberg 72. the content is Zubin Wadia 73. for the business side, architects should avoid cynicism (Chad la Vigne) 74. stretch the key dimensions and find out the deficiencies in the design (Stephen Jones) 75. Architects must rely on their own programming capabilities (Mike Brown) 76. name Sam Gardiner to find out exactly what to do. 77. Stable issues can be achieved with high-quality solutions (Sam Gardiner) 78. Brian Hart is truly doing simple tasks and sticking to their promises. 79. Take responsibility for decision making (Yi Zhou) 80. Abandon intelligence, seek simplicity (Eben Hewitt) 81. Carefully select effective technologies and never easily discard (Chad la Vigne) 82. Customers are your customers! ( Eben Hewitt) 83. Peter Gillard-Moss is a process of continuous exploration and experimentation in a changing world. 84. Eric Hawthorne, a framework that can coexist harmoniously, should be "omnipotent. 85. Emphasize 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. Building a system of titles (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. Learning new languages (Burkhardt Hufnagel)

Prevent communication failures and misunderstandings.

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

94. User Acceptance issues (Norman carnovale)

Reduces the risks caused by user acceptance issues.

95. Inspiration of qingtang (Eben Hewitt)

Software Architecture design requires continuous refinement and concentration.

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

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