怎么做最好的软件架构师？他们来告诉你！
时间:2016-01-31 20:38 来源:linux.it.net.cn 作者:IT
怎么做最好的软件架构师？他们来告诉你！
1． 不要轻易放过不起眼的问题 （ Dave Quick ）
别忘了温水煮青蛙的故事。
2． 让大家学会复用 （ Jeremy Meyer ）
重复利用已有资源，首先要改变大家的观念。
3． 架构里没有大写的“I” （ Dave Quick ）
不要让自己变成自大狂。
4． 使用“ 一千英尺高” 的视图 （ Erik Doernenburg ）
选择合适的架构视图。
5． 客户需求重于个人简历 （ Nitin Borwankar ）
客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉，往往事与愿违。
6． 简化根本复杂性，消除偶发复杂性 （ Neal Ford ）
分析问题好比拨云见月、水落石出。
7． 关键问题可能不是出在技术上 （ Mark Ramm ）
团队同心，其利断金。
8． 以沟通为中心，坚持简明清晰的表达方式和开明的领导风格 （ Mark Richards ）
沟通应当言简意赅、详略得当，别拖泥带水。
9． 架构决定性能 （ Randy Stafford ）
种瓜得瓜，种豆得豆，架构设计也是一样道理。
10． 分析客户需求背后的意义 （ Einar Landre ）
抽丝剥茧，洞见症结。不要被表面需求迷惑。
11． 起立发言 （ Udi Dahan ）
起立发言效果更好。
12． 故障终究会发生 （ Michael Nygard ）
应该提前设计预防措施，限制故障。
13． 我们常常忽略了自己在谈判 （ Michael Nygard ）
工程师应该适时转换角色，学习谈判的技巧。
14． 量化需求 （ Keith Braithwaite ）
没有规矩，不成方圆。
15． 一行代码比五百行架构说明更有价值 （ Allison Randal ）
可工作的代码才是目标，设计只是达成目标手段。
16． 不存在放之四海皆准的解决方案 （ Randy Stafford ）
软件世界没有万能钥匙。
17． 提前关注性能问题 （ Rebecca Parsons ）
尽早展开性能测试。
18． 架构设计要平衡兼顾多方需求 （ Randy Stafford ）
平衡兼顾项目的技术需求和相关各方的业务需求。
19． 草率提交任务是不负责任的行为 （ Niclas Nilsson ）
要设法杜绝开发人员草率提交任务的念头。
20． 不要在一棵树上吊死 （ Keith Braithwaite ）
为客户提供多样化的解决方案。
21． 业务目标至上 （ Dave Muirhead ）
技术决策不能脱离业务目标和现实条件的约束。
22． 先确保解决方案简单可用，再考虑通用性和复用性 （ Kevlin Henney ）
23． 架构师应该亲历亲为 （ John Davies ）
身先士卒才能赢得同事的信任。
24． 持续集成 （ David Bartlett ）
25． 避免进度调整失误 （ Norman Carnovale ）
不惜一切代价拒绝调整项目进度的要求。
26． 取舍的艺术 （ Mark Richards ）
架构不可能满足所有需求。
27． 打造数据库堡垒 （ Dan Chak ）
一开始就要定义好数据模型。
28． 重视不确定性 （ Kevlin Henney ）
推迟决策，建设性地利用不确定性。
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． 找到并留住富有激情的问题解决者 （ Chad La Vigne ）
90． 软件并非真实的存在 （ Chad La Vigne ）
虚拟世界中的软件是柔韧可变的。
91． 学习新语言 （ Burkhardt Hufnagel ）
防止沟通不畅和误解 。
92． 没有永不过时的解决方案（ Richard Monson-Haefel ）
93． 用户接受度问题（ Norman Carnovale ）
减轻用户接受度问题带来的风险。
94． 清汤的重要启示 （ Eben Hewitt ）
软件架构设计需要不断的精炼浓缩。
95． 对最终用户而言，界面就是系统 （ Vinayak Hegde ）
(责任编辑：IT)
| 怎么做最好的软件架构师？他们来告诉你！ 1． 不要轻易放过不起眼的问题 （ Dave Quick ） 别忘了温水煮青蛙的故事。 2． 让大家学会复用 （ Jeremy Meyer ） 重复利用已有资源，首先要改变大家的观念。 3． 架构里没有大写的“I” （ Dave Quick ） 不要让自己变成自大狂。 4． 使用“ 一千英尺高” 的视图 （ Erik Doernenburg ） 选择合适的架构视图。 5． 客户需求重于个人简历 （ Nitin Borwankar ） 客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉，往往事与愿违。 6． 简化根本复杂性，消除偶发复杂性 （ Neal Ford ） 分析问题好比拨云见月、水落石出。 7． 关键问题可能不是出在技术上 （ Mark Ramm ） 团队同心，其利断金。 8． 以沟通为中心，坚持简明清晰的表达方式和开明的领导风格 （ Mark Richards ） 沟通应当言简意赅、详略得当，别拖泥带水。 9． 架构决定性能 （ Randy Stafford ） 种瓜得瓜，种豆得豆，架构设计也是一样道理。 10． 分析客户需求背后的意义 （ Einar Landre ） 抽丝剥茧，洞见症结。不要被表面需求迷惑。 11． 起立发言 （ Udi Dahan ） 起立发言效果更好。 12． 故障终究会发生 （ Michael Nygard ） 应该提前设计预防措施，限制故障。 13． 我们常常忽略了自己在谈判 （ Michael Nygard ） 工程师应该适时转换角色，学习谈判的技巧。 14． 量化需求 （ Keith Braithwaite ） 没有规矩，不成方圆。 15． 一行代码比五百行架构说明更有价值 （ Allison Randal ） 可工作的代码才是目标，设计只是达成目标手段。 16． 不存在放之四海皆准的解决方案 （ Randy Stafford ） 软件世界没有万能钥匙。 17． 提前关注性能问题 （ Rebecca Parsons ） 尽早展开性能测试。 18． 架构设计要平衡兼顾多方需求 （ Randy Stafford ） 平衡兼顾项目的技术需求和相关各方的业务需求。 19． 草率提交任务是不负责任的行为 （ Niclas Nilsson ） 要设法杜绝开发人员草率提交任务的念头。 20． 不要在一棵树上吊死 （ Keith Braithwaite ） 为客户提供多样化的解决方案。 21． 业务目标至上 （ Dave Muirhead ） 技术决策不能脱离业务目标和现实条件的约束。 22． 先确保解决方案简单可用，再考虑通用性和复用性 （ Kevlin Henney ） 23． 架构师应该亲历亲为 （ John Davies ） 身先士卒才能赢得同事的信任。 24． 持续集成 （ David Bartlett ） 25． 避免进度调整失误 （ Norman Carnovale ） 不惜一切代价拒绝调整项目进度的要求。 26． 取舍的艺术 （ Mark Richards ） 架构不可能满足所有需求。 27． 打造数据库堡垒 （ Dan Chak ） 一开始就要定义好数据模型。 28． 重视不确定性 （ Kevlin Henney ） 推迟决策，建设性地利用不确定性。 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． 找到并留住富有激情的问题解决者 （ Chad La Vigne ） 90． 软件并非真实的存在 （ Chad La Vigne ） 虚拟世界中的软件是柔韧可变的。 91． 学习新语言 （ Burkhardt Hufnagel ） 防止沟通不畅和误解 。 92． 没有永不过时的解决方案（ Richard Monson-Haefel ） 93． 用户接受度问题（ Norman Carnovale ） 减轻用户接受度问题带来的风险。 94． 清汤的重要启示 （ Eben Hewitt ） 软件架构设计需要不断的精炼浓缩。 95． 对最终用户而言，界面就是系统 （ Vinayak Hegde ） (责任编辑：IT) |