Fighting bird分享 http://blog.sciencenet.cn/u/tonia

博文

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

已有 6158 次阅读 2010-9-17 14:13 |系统分类:科研笔记

(续 http://www.sciencenet.cn/m/user_content.aspx?id=359261)

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.
优秀软件不是构建出来的,而是培育出来的(演化和适应性)

https://wap.sciencenet.cn/blog-425672-362756.html

上一篇:软件架构师应该知道的97件事(一)
下一篇:Ubuntu上安装R
收藏 IP: .*| 热度|

0

发表评论 评论 (0 个评论)

数据加载中...

Archiver|手机版|科学网 ( 京ICP备07017567号-12 )

GMT+8, 2024-5-29 04:13

Powered by ScienceNet.cn

Copyright © 2007- 中国科学报社

返回顶部