Chinaunix首页 | 论坛 | 博客
  • 博客访问: 381045
  • 博文数量: 71
  • 博客积分: 3226
  • 博客等级: 中校
  • 技术积分: 970
  • 用 户 组: 普通用户
  • 注册时间: 2007-12-04 14:55
文章分类

全部博文(71)

文章存档

2012年(8)

2011年(12)

2010年(11)

2008年(29)

2007年(11)

分类:

2010-05-05 08:40:43

软件架构师是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 , 等等。
下面内容摘自该书的标题,并给出了必要的补充说明, 由本书译者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 )
寻找自然的边界,分而治之。
阅读(4467) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

安何2010-05-27 09:38:31