Shulou(Shulou.com)06/03 Report--

Software architect is an enviable profession. In a country with mature market economy, its salary has reached the level of doctors, lawyers, certified public accountants and architects. However, there is no direct relationship between salary and career maturity. Under the heavy reward, there must be brave men, and high salaries often lead to temporary intermingling of the good and the bad in industries with imperfect training mechanisms. At present, we do not have a mature mechanism to train software architects, and architects are mostly self-taught by programmers. Programmers are good at dealing with computers, but not good at dealing with interpersonal relationships at work. However, experience shows that in addition to technical expertise, communication and cooperation skills, leadership coordination skills, and the experience of overall planning and choice play a more important role in the process of directing development projects, and these contents cannot be found in computer school textbooks at all. People who have just been promoted to software architects feel at a loss for a while because there are too many non-technical problems bothering them.

Software architect is a unique profession in the IT industry. He should not only be proficient in software development technology, but also master business knowledge, and coordinate among different departments of the company. This is by no means easy, and this is the subject of the upcoming book, 97 Things Every Software Architect Should Know, which will be translated and published by the blog Viewpoint.

The editor of this book, Richard Monson-Haefel, is the author of the best-selling books Enterprise JavaBeans and Java messaging Services. Richard invites more than 50 outstanding software architects to share their work experiences and opinions to help readers avoid detours. There are some familiar names: Neal Ford, author of effective programmers, Gregor Hohpe, author of Enterprise Integration pattern, Servlets and JSP expert group, and Bill de h ó ra, technical expert of W3C RDF working group, Mark Ramm, author of Rapid Development of Web applications: using TurboGears, Michael Nygard, author of Release It!, and Dr. Rebecca Parsons, co-author of Meditation on Software Development Allison Randal, a female architect active in the Perl community, Eben Hewitt, author of "Java SOA Cookbook," and so on.

At present, the book has been translated, and the post-production is under way, which is scheduled to be published in late April 2010. The following is a list of the topics and authors of the 97 articles in the book. We have collected the author's blog address or personal home page as much as possible for your reference. The Douban page of this book.

97 things a software architect should know:

1. Customer demand is more important than resume (Nitin Borwankar)

Customer demand is paramount. Fishing for fame goes against one's wishes.

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

Analyzing problems is like digging clouds to see the moon and getting to the bottom of the matter.

3. The key problem may not be technical (Mark Ramm)

If the team is of one mind, its advantages will break the gold.

4. Focus on communication, adhere to concise and clear expression and enlightened leadership style (Mark Richards)

Communication should be concise, detailed and appropriate, and don't drag your feet.

5. Architecture determines performance (Randy Stafford)

Reap what you sow, reap what you sow, and the same is true of architectural design.

6. Analyze the meaning behind customer requirements (Einar Landre)

Peel off the cocoon and see the crux of the problem. Don't be fooled by superficial needs.

7. Stand up and speak (Udi Dahan)

It is better to stand up and speak.

8. Failure will happen eventually (Michael Nygard)

Preventive measures should be designed in advance to limit failures.

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

Engineers should change roles at the right time and learn negotiation skills.

10. Quantify demand (Keith Braithwaite)

If there are no rules, there is no square.

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

Working code is the goal, and design is just a means to achieve it.

There is no one-size-fits-all solution (Randy Stafford)

There is no * in the software world.

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

Start performance testing as soon as possible.

14. Architecture design should balance multi-party requirements (Randy Stafford)

Strike a balance between the technical needs of the project and the business needs of relevant parties.

15. It is irresponsible to submit tasks hastily (Niclas Nilsson)

Try to put an end to the idea that developers submit tasks hastily.

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

Provide customers with a variety of solutions.

17. Business goals first (Dave Muirhead)

Technical decision-making can not be separated from the constraints of business objectives and practical conditions.

18. Ensure that the solution is simple and available before considering versatility and reusability (Kevlin Henney)

19. Architects should John Davies themselves.

Only by taking the lead can you win the trust of your colleagues.

20. Continuous Integration (David Bartlett)

21. Avoid schedule adjustment errors (Norman Carnovale)

Refuse the request to adjust the schedule of the project at all costs.

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

The architecture cannot meet all the requirements.

23. Build a database fortress (Dan Chak)

Define the data model from the beginning.

24. Value uncertainty (Kevlin Henney)

Postpone decision-making and use uncertainty constructively.

25. Don't easily ignore obscure problems (Dave Quick)

Don't forget the story of boiling frogs in warm water.

26. Let everyone learn to Jeremy Meyer.

In order to reuse existing resources, we must first change people's minds.

27. There is no uppercase "I" (Dave Quick) in the architecture

Turn yourself into a megalomaniac.

28. Use a thousand-foot-tall view (Erik Doernenburg)

Select the appropriate schema view.

29. Try before you make decisions (Erik Doernenburg)

30. Master business domain knowledge (Mark Richards)

31. Programming is a kind of Einar Landre.

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

32. Let developers make their own decisions (Philip Nelson)

33. Time changes everything (Philip Nelson)

Choose a job that is worth your energy, and don't mess with your previous job.

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

35. Control project size (Dave Quick)

36. The architect is not an actor, but a Barry Hawkins.

Don't forget your job responsibilities.

37. Moral responsibility for Software Architecture (Michael Nygard)

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

38. Skyscrapers are not retractable (Michael Nygard)

But the software can.

39. The era of mixed development has come (Edward Garson)

40. Performance first (Craig Russell)

41. Pay attention to the white space in the architecture diagram (Michael Nygard)

The blank area is "filled" with all kinds of software and hardware.

42. Learn the jargon of software majors (Mark Richards)

Speaking jargon among peers facilitates communication.

43. Context determines everything (Edward Garson)

44. Dwarfs, elves, wizards and kings (Evan Cofsky)

Development teams should not be homogenized.

45. Learn from architects (Keith Braithwaite)

Learn from the experience of the construction industry.

46. Avoid repetition (Niclas Nilsson)

Welcome to the real world (Gregor Hohpe)

The real world is more complex than the software world.

48. Watch carefully and don't try to control everything (Gregor Hohpe)

49. Architects are like two-faced gods (David Bartlett)

An architect should look at everything and listen to it like two faces.

50. Architects should focus on boundaries and interfaces (Einar Landre)

Look for the boundaries of nature and divide and rule them.

51. Support the development team (Timothy High)

A good team is the guarantee of success, so try your best to help the development team.

52. Record the reasons for decision (Timothy High)

Recording the reasons behind architectural decisions has a very high return on investment value.

53. Challenge assumptions, especially your own (Timothy High)

Speculation is the main source of things messing up. Be sure to ensure that the software foundation is solid and reliable.

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

Help the people around us improve continuously, and they will also help us to reach our full potential.

55. Model disease (Chad La Vigne)

Don't let the desire to show the power of design patterns obscure the pragmatic knowledge.

56. Don't abuse architectural metaphors (David Ing)

Don't indulge in systematic metaphors and let it hold you back.

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

Application support and maintenance should never be an afterthought.

58. Only if you have a house can you get it (Bill de h ó ra)

Cherish the opportunity that needs to be weighed, far better than no restrictions and restrictions.

59. Principles, axioms and analogies are better than personal opinions and tastes (Michael Harmer)

60. Start developing applications from "walkable skeletons" (Clint Shank)

Starting from the "walkable skeleton", the incremental cultivation system grows.

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 have simple solutions (Chad La Vigne)

63. Architects are first of all developers (Mike Brown)

When in trouble, architects can't just blow smoke rings and do nothing about it.

64. Make decisions based on return on investment (ROI) (George Malamidis)

65. All software systems are legacy (Dave Anderson)

The software will soon be out of date, and modification and maintenance is inevitable.

66. There must be at least two alternative solutions (Timothy High)

67. Understand the impact of change (Doug Crawford)

Have a clear understanding of the types of changes and their effects.

68. You can't help but know the hardware (Kamal Wickramanayake)

Hardware capacity planning is as important as software architecture.

69. Take shortcuts now and pay interest in the future (Scot Mcphee)

Pay off the technical debt in time.

70. Don't pursue "perfect", just "good enough" (Greg Nyberg)

Avoid overdesign.

71. Beware of "good idea" (Greg Nyberg)

72. Content is king (Zubin Wadia)

73. For the business side, architects should avoid Chad La Vigne.

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

75. Architects should rely on their programming skills (Mike Brown)

76. Name appropriately (Sam Gardiner)

Figure out what to do.

77. Stable problems can lead to high-quality solutions (Sam Gardiner)

78. Tiandao reward for hard work (Brian Hart)

Really do a good job in those seemingly simple tasks and keep your promises.

79. Be responsible for decisions (Yi Zhou)

80. Abandon cleverness and seek simplicity (Eben Hewitt)

81. Choose effective technologies carefully and never abandon them easily (Chad La Vigne)

82. The client of the customer is your client! (Eben Hewitt)

83. Things always develop unexpectedly (Peter Gillard-Moss)

Design is a process of continuous exploration and experiment in an ever-changing world.

84. Choose a framework that can live in harmony with each other (Eric Hawthorne)

Beware of the "omnipotent" framework.

85. Emphasize the commercial value of the project (Yi Zhou)

86. Control not only the code, but also the data (Chad La Vigne)

87. Repayment of technical debt (Burkhardt Hufnagel)

Strike a balance between speed and architecture.

88. Don't rush to solve (Eben Hewitt)

First of all, let's see if we can change the problem.

89. Create a good system (Keith Braithwaite)

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

91. Software is not real (Chad La Vigne)

Software in the virtual world is flexible.

92. Learning a new language (Burkhardt Hufnagel)

Prevent poor communication and misunderstandings.

93. No timeless solution (Richard Monson-Haefel)

94. User acceptance issues (Norman Carnovale)

Reduce the risk of user acceptance problems.

95. The important revelation of clear soup (Eben Hewitt)

Software architecture design requires constant refinement and concentration.

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

97. Excellent software is not built, but nurtured (Bill de h ó ra)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.