97件事

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 ）

防止沟通不畅和误解 。

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

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

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

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

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

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

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