软件架构师应该知道的97件事

软件架构师是IT  行业里独一无二的职业，既要精通软件开发技术，又要掌握业务知识，还要周旋于公司不同部门之间，协调各种予盾。做到这些绝非易事，  博文视点   即将翻译出版的新书《软件架构师应该知道的97  件事》（97 Things Every Software Architect Should Know   ）探讨的就是这个主题。

本书的编辑Richard Monson-Haefel  是畅销书《  Enterprise JavaBeans   》和《  Java  消息服务   》的作者。Richard  邀请五十多位杰出的软件架构师分享工作经验和观点，帮助读者少走弯路。其中不乏大家熟悉的名字：

《  卓有成效的程序员   》的作者Neal Ford ，《  企业集成模式   》的作者Gregor Hohpe ， Servlets  和JSP  专家组和W3C RDF 工作组技术专家Bill de hÓra，  《  Web  应用程序快速开发   ：   使用TurboGears   》的作者Mark Ramm ，《  Release It!   》的作者Michael Nygard ，《  软件开发沉思录 》的作者之一Rebecca Parsons  博士，活跃于Perl  社区的女架构师Allison Randal  ，《   Java SOA Cookbook   》的作者  Eben Hewitt  ，  等等。

下面内容摘自该书的标题，并给出了必要的补充说明， 由本书译者SeanBV（他的CSDN博客 ）整理，推荐给大家。

1．   客户需求重于个人简历  （  Nitin Borwankar   ）

客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉，往往事与愿违。

2．   简化根本复杂性  ，消除偶发复杂性  （  Neal Ford   ）

分析问题好比拨云见月、水落石出。

3．   关键问题可能不是出在技术上  （  Mark Ramm   ）

团队同心，其利断金。

4．   以沟通为中心，坚持简明清晰的表达方式和开明的领导风格  （  Mark Richards   ）

沟通应当言简意赅、详略得当，别拖泥 带水。

5．   架构决定性能  （  Randy Stafford   ）

种瓜得瓜，种豆得豆，架构设计也是一 样道理。

6．   分析客户需求背后的意义   （ Einar Landre  ）

抽丝剥茧，洞见症结。不要被表面需求 迷惑。

7．   起立发言  （  Udi Dahan   ）

起立发言效果更好。

8．   故障终究会发生  （  Michael Nygard   ）

应该提前设计预防措施，限制故障。

9．   我们常常忽略了自己在谈判  （  Michael Nygard   ）

工程师应该适时转换角色，学习谈判的 技巧。

10．  量化需求  （  Keith Braithwaite   ）

没有规矩，不成方圆。

11．  一行代码比五百行架构说明更有价值  （  Allison Randal   ）

可工作的代码才是目标，设计只是达成 目标手段。

12．  不存在放之四海皆准的解决方案  （  Randy Stafford   ）

软件世界没有万能钥匙。

13．  提前关注性能问题  （  Rebecca Parsons   ）

尽早展开性能测试。 

14．  架构设计要平衡兼顾多方需求  （  Randy Stafford   ）

平衡兼顾项目的技术需求和相关各方的业务需求。

15．  草率提交任务是不负责任的行为    （  Niclas Nilsson   ）

要设法杜绝开发人员草率提交任务的念头。

16．  不要在一棵树上吊死    （  Keith Braithwaite   ）

为客户提供多样化的解决方案。

17．  业务目标至上   （ Dave Muirhead  ）

技术决策不能脱离业务目标和现实条件的约束。

18．  先确保解决方案简单可用，再考虑通用性和复用性    （  Kevlin Henney   ）

19．  架构师应该亲历亲为   （ John Davies  ）

身先士卒才能赢得同事的信任。

20．  持续集成   （ David Bartlett  ）

21．  避免进度调整失误   （ Norman Carnovale  ）

不惜一切代价拒绝调整项目进度的要求。

22．  取舍的艺术  （  Mark Richards   ）

架构不可能满足所有需求。

23．  打造数据库堡垒  （  Dan Chak   ）

一开始就要定义好数据模型。

24．  重视不确定性  （  Kevlin Henney   ）

推迟决策，建设性地利用不确定性。

25．  不要轻易放过不起眼的问题   （ Dave Quick  ）

别忘了温水煮青蛙的故事。

26．  让大家学会复用  （  Jeremy Meyer   ）

重复利用已有资源，首先要改变大家的观念。

27．  架构里没有大写的“I  ”   （ Dave Quick  ）

变让自己变成自大狂。

28．  使用“  一千英尺高”  的视图  （  Erik Doernenburg   ）

选择合适的架构视图。

29．  先尝试后决策  （  Erik Doernenburg   ）

30．  掌握业务领域知识  （  Mark Richards   ）

31．  程序设计是一种设计   （ Einar Landre  ）

软件开发也分成设计和生产两个阶段。

32．  让开发人员自己做主   （ Philip Nelson  ）

33．  时间改变一切   （ Philip Nelson  ）

选择值得投入精力的工作，别跟以前的工作过不去。

34．  设立软件架构专业为时尚早   （ Barry Hawkins  ）

35．  控制项目规模   （ Dave Quick  ）

36．  架构师不是演员，是管家   （ Barry Hawkins  ）

别忘了你的工作责任。

37．  软件架构的道德责任  （  Michael Nygard   ）

架构师的决定会影响许多人，务必慎重。

38．  摩天大厦不可伸缩  （  Michael Nygard   ）

但软件可以。

39．  混合开发的时代已经来临  （  Edward Garson   ）

40．  性能至上   （Craig Russell  ）

41．  留意架构图里的空白区域  （  Michael Nygard   ）

空白区域“充满”了各种软件和“硬件”。

42．  学习软件专业的行话  （  Mark Richards   ）

同行之间讲行话方便交流。

43．  具体情境决定一切  （  Edward Garson   ）

44．  侏儒、精灵、巫师和国王  （  Evan Cofsky   ）

开发团队不应该同质化。

45．  向建筑师学习  （  Keith Braithwaite   ）

借鉴建筑行业的经验。

46．  避免重复  （  Niclas Nilsson   ）

47．  欢迎来到现实世界  （  Gregor Hohpe   ）

现实世界比软件世界复杂。

48．  仔细观察，别试图控制一切  （  Gregor Hohpe   ）

49．  架构师好比两面神   （ David Bartlett  ）

架构师应该像两面神一样，眼观六路、耳听八方。

50．  架构师应关注边界和接口    （ Einar Landre  ）

寻找自然的边界，分而治之。

51．  助力开发团队  （  Timothy High   ）

优秀团队是成功的保障，要尽量助力开发团队。

52．  记录决策理由  （  Timothy High   ）

记录架构决策背后的理由，具有极高的投资回报价值。

53．  挑战假设,  尤其是你自己的  （  Timothy High      ）

臆断是事情搞砸的主要根源。务必要确保软件基石坚实可靠。

54．  分享知识和经验  （  Paul W. Homer   ）

帮助周围的人不断改善，他们也会帮助我们发挥出全部的潜力。

55．  模式病   （ Chad La Vigne  ）

不要让一展设计模式功力的欲望，遮蔽了务实的真知。

56．  不要滥用架构隐喻   （ David Ing  ）

不要耽溺于系统隐喻之中，反让它拖了后腿。

57．  关注应用程序的支持和维护   （ Mncedisi Kasper  ）

应用程序的支持和维护，永远都不应该是事后才考虑的事情。

58．  有舍才有得  （  Bill de hÓra   ）

珍惜需要权衡的时机，远胜毫无约束和限制。

59．  原则、公理和类比胜于个人意见和口味 （  Michael Harmer   ）

60．  从“  可行走骨架”  开始开发应用 （  Clint Shank   ）

从“ 可行走骨架” 开始，增量培育系统成长  。

61．  数据是核心（  Paul W. Homer   ）

从“数据是核心”这个角度去认识系统，能大大降低理解复杂度  。

62．  确保简单问题有简单的解   （Chad La Vigne  ）

63．  架构师首先是开发人员   （Mike Brown  ）

碰到麻烦时，架构师可不能只会干吹烟圈却束手无策。

64．  根据投资回报率（ROI  ）进行决策（  George Malamidis   ）

65．  一切软件系统都是遗留系统（  Dave Anderson  ）

软件很快便会过时，修改维护无可避免。

66．  起码要有两个可选解决方案（  Timothy High   ）

67．  理解变化的影响 （   Doug Crawford  ）

清楚认识变化类型及其影响。

68．  你不能不了解硬件（  Kamal Wickramanayake   ）

硬件容量规划，是和软件架构同等重要的事情。

69．  现在走捷径，将来需付息（  Scot Mcphee   ）

及时还清技术债务。

70．  不要追求“完美”，“足够好”就行（   Greg Nyberg  ）

避免过度设计。

71．  小心“好主意” （  Greg Nyberg  ）

72．  内容为王  （  Zubin Wadia   ）

73．  对商业方，架构师要避免愤世嫉俗（  Chad La Vigne  ）

74．  拉伸关键维度，发现设计中的不足（  Stephen Jones  ）

75．  架构师要以自己的编程能力为依托（  Mike Brown  ）

76．  命名要恰如其分（  Sam Gardiner  ）

弄清楚要做的究竟是什么。

77．  稳定的问题可以获得高质量的解决方案（  Sam Gardiner  ）

78．  天道酬勤（  Brian Hart  ）

真正做好那些看似简单的任务，坚守承诺。

79．  对决策负责（  Yi Zhou  ）

80．  弃聪明，求质朴（  Eben Hewitt   ）

81．  精心选择有效技术，绝不轻易抛弃（  Chad La Vigne  ）

82．  客户的客户才是你的客户！（  Eben Hewitt   ）

83．  事物发展总会出人意料 （  Peter Gillard-Moss   ）

设计是在不断变化的世界中持续进行探索试验的过程。

84．  选择彼此间能和谐共处的框架 （  Eric Hawthorne  ）

当心“无所不能”型的框架。

85．  着重强调项目的商业价值（  Yi Zhou  ）

86．  不仅仅只控制代码，也要控制数据 （   Chad La Vigne  ）

87．  偿还技术债务 （  Burkhardt Hufnagel  ）

在速度和架构间进行权衡，保持平衡。

88．  不要急于求解（  Eben Hewitt   ）

首先看看是否可以改变问题。

89．  打造称手的系统（  Keith Braithwaite   ）

90．  找到并留住富有激情的问题解决者 （  Chad La Vigne  ）

91．  软件并非真实的存在 （  Chad La Vigne  ）

虚拟世界中的软件是柔韧可变的。

92．  学习新语言 （  Burkhardt Hufnagel  ）

防止沟通不畅和误解  。

93．  没有永不过时的解决方案（  Richard Monson-Haefel  ）

94．  用户接受度问题（  Norman Carnovale  ）

减轻用户接受度问题带来的风险。

95．  清汤的重要启示 （  Eben Hewitt   ）

软件架构设计需要不断的精炼浓缩。

96．  对最终用户而言，界面就是系统 （  Vinayak Hegde   ）

97．  优秀软件不是构建出来的，而是培育起来的（  Bill de hÓra   ）

 

最后

以上就是端庄薯片最近收集整理的关于软件架构师应该知道的97件事软件架构师应该知道的97件事的全部内容，更多相关软件架构师应该知道内容请搜索靠谱客的其他文章。