软件架构师是个让人羡慕的职业,在市场经济成熟的国家,其薪酬已
经达到医生、律师、注册会计师、建筑设计师的水平。但是薪酬高低与职业成熟度没有直接的关系。重赏之下必有勇夫,高薪往往造成培养机制不健全的行业出现暂
时的良莠不齐。目前我们还没有培养软件架构师的成熟机制,架构师大多是程序员自学成材。程序员擅长和电脑打交道,却不善于处理工作中的人际关系。然而经验
表明,除了技术特长,沟通协作的技巧、领导协调的能力、统筹取舍的经验在指挥开发项目的过程中起着更重要的作用,而这些内容在计算机学院的课本里压根找不
到。刚刚升任软件架构师的人,都有一段时间觉得茫然失措,因为有太多非技术问题困扰着他们。
软件架构师是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
,
等等。
目前这本书已经翻译完成,博文视点正在紧张地进行后期制作,计划2010
年4
月下旬出版。以下是书中97
篇文章的主题和作者列表。我们尽可能收集了作者的博客地址或个人主页,方便大家浏览参考。本书的豆瓣页面
。
软件架构师应该知道的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
)
从“ 可行走骨架” 开始,增量培育系统成长
。
-->
- 该日志由 inducing 于11年前发表在综合分类下,最后更新于 2013年02月28日.
- 转载请注明: 软件架构师应该知道的97件事 | 学步园 +复制链接