现在的位置: 首页 > 综合 > 正文

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

2013年02月28日 ⁄ 综合 ⁄ 共 3287字 ⁄ 字号 评论关闭

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

软件架构师是个让人羡慕的职业,在市场经济成熟的国家,其薪酬已
经达到医生、律师、注册会计师、建筑设计师的水平。但是薪酬高低与职业成熟度没有直接的关系。重赏之下必有勇夫,高薪往往造成培养机制不健全的行业出现暂
时的良莠不齐。目前我们还没有培养软件架构师的成熟机制,架构师大多是程序员自学成材。程序员擅长和电脑打交道,却不善于处理工作中的人际关系。然而经验
表明,除了技术特长,沟通协作的技巧、领导协调的能力、统筹取舍的经验在指挥开发项目的过程中起着更重要的作用,而这些内容在计算机学院的课本里压根找不
到。刚刚升任软件架构师的人,都有一段时间觉得茫然失措,因为有太多非技术问题困扰着他们。


软件架构师是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






从“ 可行走骨架” 开始,增量培育系统成长


-->

作者:

抱歉!评论已关闭.