97 things software architects should know

 

97 things software architects 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 fundamental 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.
5. Architecture determines performance (Randy Stafford)
The same is true for architecture design.
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. Demand quantification (Keith Braithwaite)
No rules.
11. One line of code is more valuable than the five hundred line of 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 suitable 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. architecture 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. Do not hold a tree (Keith Braithwaite)
Provide customers with a variety of solutions.
17. business goals 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. The architect should be personally (John Davies)
Take the lead to win the trust of colleagues.
20. Continuous integration (David Bartlett)
21. Avoid misadjustments (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. Pay attention to uncertainty (kevlin Henney)
Delay decision-making and make constructive use of uncertainty.
25. Don't let alone the inconspicuous problem (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" (Dave quick) in the architecture)
Don't turn yourself into a mad man.
28. Use the "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. 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)
Select a job that is worth your effort.
34. It's too early to set up a software architecture major (Barry Hawkins)
35. Control the 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. The skyscraper cannot be scaled (Michael Nygard)
But the software can.
39. The era of Mixed development is approaching (Edward Garson)
40. performance first (Craig Russell)
41. Pay attention to the blank area in the structural diagram (Michael Nygard)
The blank area is "filled" with various software and "hardware ".
42. Learning about the software profession (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. Avoid duplication (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 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-making reasons (Timothy high)
Record the reasons behind architecture decision making and have extremely high ROI value.
53. Challenge hypothesis, especially your (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. 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. 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. Start to develop applications from the "Walking skeleton" (Clint shank)
Starting from the "Walking skeleton", the system grows incrementally.
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 there is a simple solution to the simple problem (Chad la Vigne)
63. The architect is first a developer (Mike Brown)
In case of trouble, the architect cannot just blow a smoke ring, but is helpless.
64. Decision-making 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. There should be 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. take shortcuts now and pay interest in the future (Scot McPhee)
Pay off technical debt in time.
70. Don't pursue perfection. Just "good enough" (Greg Nyberg)
Avoid over-design.
71. Be careful with "good ideas" (Greg Nyberg)
72. Zubin Wadia)
73. Architects of commercial parties should avoid cynicism (Chad la Vigne)
74. Stretch key dimensions and discover deficiencies in design (Stephen Jones)
75. architects should rely on their own programming capabilities (Mike Brown)
76. Proper Name (Sam Gardiner)
Find out what you want to do.
77. High-quality solutions for stable problems (Sam Gardiner)
78. 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. The customer is your customer! (Eben Hewitt)
83. Unexpected things (Peter Gillard-Moss)
Design is a process of continuous exploration and experimentation in a changing world.
84. Eric Hawthorne)
Beware of an all-powerful framework.
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. Good software is not built, but nurtured (Bill de hóra)
Original article: Workshop.