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

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

 

 
 
下面内容摘自该书的标题,并给出了必要的补充说明, 由本书译者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 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值