软件架构师应该知道的97件事 笔记(六)

81. 精心选择有效技术，绝不轻易抛弃
软件架构师工作很大的一部分，是要选择用以攻克难题的合适技术。精心选择熟悉的武器，不到万不得已，不要轻易排序它们。
选择新技术虽然有风险，但其价值在于往往能为你带来质的飞跃。不过仍然要谨慎选择。

82. 客户的客户才是你的客户！
想象你的客户并不是你的客户，而你客户的客户才是你的客户，这样你的客户的客户赢了，你的客户也就赢了。
例如，你为某个机械开发一个网站，你要想到使用这个网站的最终用户！
如果你的客户有意无意的忽视他们的客户所看重的重要事项，这个时候你就需要考虑与你的客户沟通、甚至放弃这个项目。

83. 事物发展总会出人意料
设计是一个不断发现的过程，不要开始试图把设计做的很完美。在开发过程中，可能不断有一些微小的变化，这些变化积累起来就需要对设计进行一次大的变更，如果还是试图维持住已经走样的设计，就会越破坏原设计。

84. 选择彼此间可协调工作的框架
软件框架是软件系统的基础，选择框架时，不仅要考虑每个框架自身的质量和特性，还要关注共同构成系统的各个框架之间是否能和谐共处。而且后面是否方便地向其中加入新的框架。即选择彼此之间没有重叠，而且开放、简洁、精专的框架。
比较好的框架专注于解决某个独立的逻辑领域，且不会侵入其他必须框架的领域关注面。精简、包容、灵活。

85. 着重强调项目的商业价值
利益相关人士往往缺乏软件工程方面的知识，给他们讲软件架构，经常是对牛弹琴，他们认为架构是虚无缥缈的，所以，在为项目争取资金时，要着力强调项目的商业价值，利益相关者一般对这个比较感兴趣，而且更容易达成一致。
将架构提案打造为典型的商业项目步骤：
a)形成价值陈述。即你的决策摘要，用以说明组织的业务为何要采用特定的软件架构。重点要放在该架构如何提高生产力、改进业务效率等。不要强项这种技术如何高明。
b)建立量化的度量标准。量化越具体，项目也将越具有说服力，越能让人相信好的架构可以带来丰厚回报。
c)回过头来关联传统商业的衡量方式。如果能将技术分析转化为财务数据，则更有说服力。
d)知道该在哪里停止。准备好一张路线图，用以捕获远景目标，清楚地知道每一个里程碑将带来的价值。让利益相关者自己决定在哪里停止。如果每处的商业价值都十分显著，就可能获得持续不断的资金支持。
e)寻找恰当的时机。

86. 不仅仅只控制代码，也要控制数据
在架构规划过程中，数据迁移部分经常被架构师忽略。最后数据迁移往往是作为一项事后补救描述，而且整个过程由手工完成，相当脆弱。对数据方案和数据内容的管理，应当尽早无缝集成到自动化的构建和测试过程中，还必须提供回退功能.

87. 偿还技术债务
当已投入实用的项目出现了问题，往往会出现两个选择：
a)花合适的时间进行“一次做对”，可能包含一些重构之类的工作
b)走“捷径”，完全为了满足当前的bug而填的一些代码，可以很快的推出修改的产品。
应该尽量选择第一个方案，第二个方案会不断的积累技术债务，越往后就越难以改变。
不过如果时间很紧迫，可以采用第二个方案，但改完之后，不能就此止步，后续仍然要考虑这个技术债务，在适当的时候清理了它。

88. 不要急于求解
首先看看是否可以改变问题。

89. 打造上手的系统
我们是工具制造者，我们制造的系统一定要帮助人们做事，否则就推动存在的意义。
“上手”即容易使用的工具。

90. 找到并留住富有激情的问题解决者
优秀的团队是项目成功非常重要的原因！也要保持团队的稳定！
打造健康的工作环境。好的开发人员，常常能从认可中获得强烈的激励。
提防批评过度，批评过度可能会扼杀开发人员的创造力，降低其生产力。可以提出建设性的批评建议，但不要强求每个解决方案看起来好像都出自你手。
以正确的方式经营开发团队。如同团队成员并肩作战，对他们一视同仁，培养团队精神等。

91. 软件并非真实存在
软件是我们创造的虚拟物，相对于物理世界中的对应物，更易于改变。所以产品的需求可能会不断发生变化，计划不断调整。

92. 学习新语言
语言包括各方面的，如与业务人员交流的语言，与程序员交流的语言，以及扩大自己的知识面需要了解的语言等。

93. 没有永不过时的解决方案
今天的解决方案一定会成为明天的问题，没有“永不过时”的解决方案。

94. 用户接受度问题
去了解与衡量接受度问题带来的威胁，并朝能减轻这些威胁的方向开展工作。比如找代表用户利益的项目拥戴者，与用户进行直接的沟通并影响用户的接受度。（接受度：如用户不想接受一个新的系统，人们不愿意实施新的系统等）

95. 清汤的重要启示
清汤是不断精练与浓缩才成的，软件架构也应该学习清汤的制作方法。

96. 对最终用户而言，界面就是系统
要让界面易用，好的界面能帮助用户提高生产力，用户会因此更加喜欢我们的产品。
用户交互实际和健壮性、性能等一样重要的。

97. 优秀软件不是构建出来的，而是培育起来的
从小的可工作系统开始，逐渐把它推向成功的目标。