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

这篇文章引自于阿里巴巴大牛的一份电子邮件，详细如下

软件架构师是 IT  行业里独一无二的职业，既要精通软件开发技术，又要掌握业务知识，还要周旋于公司不同部门之间，协调各种予盾。做到这些绝非易事。

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   ）