注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

软件大铺的博客

IT技术共享

 
 
 

日志

 
 

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

2011-11-19 22:27:10|  分类: 架构 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

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

寻找自然的边界,分而治之。

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 

  评论这张
 
阅读(428)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017