软件架构师应该知道的97件事 - CSDN资讯

软件构架师

软件架构师应该知道的97件事 - CSDN资讯首页资讯空间学生论坛博客下载读书网摘程序员外包书店网址 CTO俱乐部乐知教育 D9区

您的位置：CSDN首页>资讯频道>正文

软件架构师应该知道的97件事2010-04-29 01:55|次阅读|【已有53条评论】发表评论关键词：新闻资讯|感谢liujiangCE的提供|收藏这篇资讯

精彩评论bvbook发表于 04-30 10:25

更多..

这书是“开源”的，全书的英文原稿在这： /wiki/index.php/97_Thing _The_Book回复|支持(2)反对(0)| 1条回复..

软件架构师是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 hra,《 Web应用程序快速开发：使用TurboGears》的作者Mark Ramm,《 Release It!》的作者Michael Nygard,《软件开发沉思录》的作者之一Rebecca Parsons博士，活跃于Perl社区的女架构师Allison Randal,《 Java SOA Cookbook》的作者 Eben Hewitt,等等。

更多精彩评论 ...

Google提供的广告

本周热点排行

更多

下面内容摘自该书的标题，并给出了必要的补充说明，由本书译者SeanBV(他的CSDN博客)整理，推荐给大家。 1.客户需求重于个人简历 ( Nitin Borwankar )客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉，往往事与愿违。 2.简化根本复杂性，消除偶发复杂性 ( Neal Ford )分析问题好比拨云见月、水落石出。

精彩专题

/a/20100429/218192.html[2010-4-30 20:42:16]

软件构架师

3． 关键问题可能不是出在技术上 （ Mark Ramm ）

英雄会,你的会解密“智慧软件”

团队同心，其利断金。

推荐博文

更多

4． 以沟通为中心，坚持简明清晰的表达方式和开明的领导风格 （ Mark Richards ）

FileHandler

沟通应当言简意赅、详略得当，别拖泥 带水。做程序员已经有白头发的进来聊聊核心模块的多语言版完成！5． 架构决定性能 （ Randy Stafford ）

看好电子书，不看好3G电子书Linux游戏产业迎来新曙光

种瓜得瓜，种豆得豆，架构设计也是一 样道理。AJAX（XMLHttpRequest）进行跨域请求方法详6．PythonWin的一个bug

分析客户需求背后的意义 （ Einar Landre ）

使用DeepEarth加载在线Google地图（卫星、街抽丝剥茧，洞见症结。不要被表面需求 迷惑。2010年百度被黑谷歌退出中国市场不为人知的内让技术人员看得懂的流程（3）——领域模型

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． 挑战假设, 尤其是你 …… 此处隐藏：3269字，全部文档内容请下载后查看。喜欢就下载吧 ……