您的位置:首页 > 运维架构 > 网站架构

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

2013-07-11 14:09 435 查看
优秀的软件架构师应该同时掌握业务知识和技术能力。(转 http://www.sciencenet.cn/m/user_content.aspx?id=359261)
1. Don't put your resume ahead of the requirements.客户需求重于个人简历

2. Simplify essential complexity; disminish accidental complexity.简化根本复杂性,消除偶发复杂性

3. Chances are, your biggest problem isn't technical.关键问题可能不是出在技术上

4. Communication is King; clarity and leadership, its humble servants.以沟通为中心,坚持简明清晰地表达方式和开明的领导风格

5. Application architecture determines application performance.架构决定性能

6. Seek the value in requested capabilities.分析客户需求背后的意义

7. Stand up!起来发言

8. Everything will ultimately fail.故障终究会发生

9. You're negotiating more often than you think.我们常常忽略了自己在谈判

10. Quantity量化需求

11. One line of working code is worth 500 of specification.一行代码比五百行架构说明更有价值

12. There is no one-size-fits-all solution.不存在放之四海皆准的解决方案

13. It's never too early to think about performance.提前关注性能问题

14. Architecting is about balancing. Balance stakeholders' interests with technical requirements.架构设计要平衡兼顾多方需求,平衡兼顾相关各方的业务需求和项目的技术需求

15. Commit-and-run is a crime.草率提交任务是不负责任的行为

16. There can be more than one.不要在一棵树上吊死

17. Business drives.业务目标至上

18. Simplicity before generality, use before reuse.先确保解决方案简单可用,再考虑通用性和复用性

19. Archtects must be hands on.架构师应该亲力亲为

20. Continuously integrate.持续集成

21. Avoid scheduling failures.避免进度调整失误

22. Achitectural tradeoffs.取舍的艺术

23. Database as a fortress.打造数据库堡垒

24. Use uncertainty as a driver.重视不确定性注:如果出现两个合理的选择,架构师应该停下来,设法找出介于两者之间的具有更低重要性的决策,而不是简单地在两者之间做出选择。

25. Warning: problems in mirror may be larger than they appear.不要轻易放过不起眼的问题

26. Reuse is about people and education, not just architect.让大家学会复用注:即便是最精美的架构、最优雅的框架、可复用性最高的系统,也必须满足以下条件才可能被复用:- Know it's there 大家知道他们存在- Know how to use it 大家知道如何使用它们- Are convinced that it's better than doing it themselves 大家认识到利用已有资源好过自己动手

27. There is no "I" in architecture.架构里没有大写的"I"注:自我可能是最大的敌人。

28. Get the 1000-foot view.使用“一千英尺高”的视图注:“三万英尺高”的视图是指架构图里的框框线条,表示依赖关系、数据流和共享资源等;另一种视图是源代码,好比站在地面上看大地。前者太抽象,后者细节太多,以至于看不清整个架构。需要介于两者之间的 “一千英尺高”的视图。

29. Try before choosing.先尝试后决策

30. Understand the business domain.掌握业务领域知识

31. Programming is an act of design.程序设计是一种设计

32. Give developers autonomy.让开发人员自己做主

33. Time changes everything.时间改变一切注:- Pick a worthy challenge 选择值得投入精力的工作- Simple rules 简单原则 KISS(keep it simple and stupid)- Be happy with that old stuff 别跟以前的工作过不去

34. “Software Architect” has only lowercase a's; deal with it.设立软件架构专业为时尚早

35. Scope is the enemy of success.控制项目规模

36. Value stewardship over showmanship.架构师不是演员,是管家

37. Software architecture has ethical consequences.软件架构的道德责任

38. Skyscrapers aren't scalable.摩天大厦不可伸缩注:尽早发布、递归式部署

39. Heterogeneity wins.混合开发的时代已经来临注:混合编程是指在同一套软件系统中同时采用多种核心编程语言。架构师可以把若干个强大的开发工具组合起来使用(mashup)。

40. It's all about performance.性能至上

41. Engineer in the white spaces.留意架构图里的空白区域注:软硬件、细节的考虑

42. Talk the talk.学习软件专业的行话注:包括架构模式和设计模式

43. Context is King.具体情境决定一切

44. Dwarves, Elves, Wizards, and Kings.侏儒、精灵、巫师和国王注:小说《Cryptonomicon》:侏儒最勤劳、有精湛的手艺,精灵最有风度和修养、天赋很高,巫师拥有无限的魔力、能够创造奇迹,还有国王拥有团结所有种族的能力。软件架构师好比国王,应该熟悉各种人的性格特点,招聘不同性格的人加入自己的团队。

45. Learn from architects of buildings.向建筑师学习注:要成为伟大的建筑师,优雅丰富的心灵远比聪明才智重要。盖房子和别的手艺一样,所以努力都是为了结果,为了完成令人满意的工作。合格的建筑应该符合以下三个条件:实用、坚固、令人愉悦。建筑师首先应该是伟大的雕塑家,或者伟大的画家,否则他只不过是个建筑工人。天底下没有完美的建筑。

46. Flight repetition.避免重复

47. Welcome to the real world.欢迎来到现实世界

48. Don't control, but observe.仔细观察,别试图控制一切

49. Janus the architect.架构师好比两面神注:罗马神话里两面神(Janus)是司守门户和万物始末之神,他有两张面孔,兼顾前与后、过去与未来的能力。

50. Architects' focus is on the boundaries and interfaces.架构师当聚焦于边界和接口

51. Empower developers.

助力开发团队

52. Record your retionale.

记录决策理由

53. Challenge assumptions- especially your own.

挑战假设,尤其是你自己的

注:

Assumption is the mother of all screw-ups.

Don't assume- it makes an "ass" of "U" and "me".

54. Share your knowledge and experiences.

分享知识和经验

55. Pattern pathology.

模式病

56. Don't stretch the architecture metaphors.

不要滥用架构隐喻

57. Focus on application support and maintenance.

关注应用程序的支持和维护

58. Prepare to pick two.

有舍才有得

注:例如Brewer's conjecture- CAP theorem

59. Prefer principles, axioms, and analogies to opinion and taste.

先考虑原则、公理和类比,再考虑个人意见和口味

60. Start with a walking skeleton.

从“可行走骨架”开始开发应用

注:“可行走骨架”是对系统的最简单实现,它贯串头尾,将所有主要的构架组件连接起来。从“可行走骨架”开始,保持系统一直运行可用,增量式地进行培育,使其逐步成长。

61. It is all about the data.

数据是核心

62. Make sure the simple stuff is simple.

确保简单问题有简单的解

注:不要陷入“杀鸡用牛刀”的误区(simple problem-complex solution trap)

63. Before anything, an architect is a developer.

架构师首先是开发人员

64. The ROI variable.

根据投资回报率(ROI)进行决策

65. Your system is legacy; design for it.

一切软件系统都是遗留系统

66. If there is only one solution, get a second opinion.

起码要有两个可选的解决方案

注:期望第一个解决方案满足全部的需求和约束几乎是不可能的,必须根据优先级次序进行权衡,选择最符合需求的解决方案。

67. Understand the impact of change.

理解变化的影响

68. You have to understand hardware, too.

你不能不了解硬件

69. Shortcuts now are paid back with interest later.

现在走捷径,将来付利息

注:项目开发初期走捷径,日后会付出高昂的维护费用为代价

70. “Perfect” is the enemy of "good enough".

不要追求“完美”,“足够好”就行

注:在设计和实现上追求完美,会导致过度设计和模糊混乱的解决方案。“足够好”指的是剩余的不完美之处,对系统的功能、可维护性或性能不会产生任何有深远意义的影响。

71. Avoid "good ideas".

小心“好主意”

72. Great content creates great systems.

内容为王

73. The business versus the angry architect.

对商业方,架构师要避免愤世嫉俗

74. Stretch key dimensions to see what breaks.

拉伸关键维度,发现设计中的不足

75. If you design it, you should be able to code it.

架构师要以自己的编程能力为依托

76. A rose by any other name will end up as a cabbage.

命名要恰如其分

77. Stable problems get high-quality solutions.

稳定的问题才能产生高质量的解决方案

注:最好的架构师不是去解决难题,而是围绕难题展开工作。架构师要能将四处弥漫的软件问题圈起来并识别出各种边界,确保对问题有稳定的、完整的认识。

78. It takes diligence.

天道酬勤

注:勤奋是指具备坚强的毅力,并对系统的每项任务和每个架构目标,都投入足够多的精力。勤奋还意味着架构师必须要真正做好那些看似简单的任务。

79. Take responsibility for your decisions.

对决策负责

80. Don't be clever.

弃聪明,求质朴

注:不要依靠一些小伎俩、骗局或调包计的“聪明”,尽量用浅显易懂的质朴(dumb)方法,恰如其分地进行设计。

81. Choose your weapons carefully, relinquish them reluctantly.

精心选择有效技术,绝不轻易抛弃

注:以审慎的态度更新你的技术武器库。

82. Your customer is not your customer.

客户的客户才是你的客户

83. It will never look like that.

事物发展总会出人意料

84. Choose frameworks that play well with others.

选择彼此间可协调工作的框架

85. Make a strong business case.

着重强调项目的商业价值

86. Control the data, not just the code.

不仅仅只控制代码,也要控制数据

87. Pay down your technical debt.

偿还技术债务

88. Don't be a problem solver.

不要急于求解

注:不要立即着手去解决摆在面前的问题,而要看看自己是否可以改变问题。有时业务问题确实需要得到解决,但有时,或许并非那么迫在眉睫。

89. Build systems to be Zuhanden.

打造上手的系统(用户体验)

90. Find and retain passionate problem solvers.

找到并留住富有激情的问题解决者

91. Software doesn't really exist.

软件并非真实存在

注:软件是无形的,柔韧多变

92. Learn a new language.

学习新语言(沟通)

93. You can't future-proof solutions.

没有永不过时的解决方案

注:今天的解决方案会成为明天的问题。只要选择满足当前需求的最佳解决方案就行了。

94. The user acceptance problem.

用户接受问题

95. The importance of consomme.

清汤的重要启示

注:清汤(consomme)需要依靠简单的、不断重复地精炼浓缩。上品清汤非常澄澈。启示:澄澈,不断精炼,拒绝模棱两可、笼统、毫无根据的假设或无关的废话。

96. For the end user, the interface is the system.

对最终用户而言,界面就是系统

97. Great software is not built; it is grown.

优秀软件不是构建出来的,而是培育出来的(演化和适应性)
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: