合理评估优缺点
评估缺点
在大部分技术人的眼里，新诞生的技术光环加身，都是优点，而原来津津乐道的正在使用的技术则漏洞百出。
作为架构师，一定要看到已有技术的优点，和新技术的不足；新技术的诞生，是为了弥补已有技术的不足，而不是带来新的问题。
当开发人员想你推荐某一项新技术，或他苦思冥想出的一个新点子时，不要直接推翻它，因为这不仅代表你否认了这个方案，也代表
你否认了他和他的想法。你需要使用引导的方式，结合当前已有的方案对比他的新点子，让他认识到我们已经有了更好的解决办法。
我们的重点是带领技术团队，在已有的道路上披荆斩棘，运送更多的货物，而不是不停的寻找新的道路；当已有的道路走不通时，我们也要毫不犹豫
的选择另外一条大路，或自己开辟新的道路。
你可以使用一个表格，列出一项技术的优缺点，然后给出原因，并向团队解释你选择某一技术的理由；
| 优点 | 缺点 |
|---|---|
| 开源 | 没有商业支持 |
| 组件可重用 | 发布周期长 |
管理风险
一项技术如果存在多个风险点，这些风险点并不全是等价的，有些风险可能更严重，怎么衡量这些风险呢？建议使用两项维度来衡量，如下表：
| 风险点 | 严重程度(1~10) | 发生可能性(1~10) | 风险评分 |
|---|---|---|---|
| 风险1 | 5 | 9 | 45 |
| 风险2 | 10 | 1 | 10 |
| 风险3 | 2 | 4 | 8 |
可以使用最终的风险评分（严重程度X可能性）来评估风险的整体影响；
深入衡量
技术人员初一接触某项新技术时，尝试过HelloWorld例子之后，往往会错以为这种技术非常牛叉。但是，随着深入钻研，就会发现它存在着各种各样的问题。
当学习某一项技术一段时间后，技术人员很容易得出一些结论，比如它应当增加XXX功能；这种结论很容易得出，因为你还没有深入了解它；
等你深入了解之后，你会得出另外一种结论，比如它应当去掉某些多余的能力或设计；
如果向了解某人对某项技术的了解程度，只需要问这两个问题，如果他只说出了第一点，那么他只是学习过这种技术；如果他能说出第二点，那么他肯定深入研究过这种技术；
新技术的光环
大部分新技术的产生都有一个固定的循环：
- 首先，一个团队遇到一个现有技术解决不了的难题，他们尝试了多种新的方法；
- 然后，突然发现其中一种方法很好的解决了这个问题，于是将这种方法包装分享给社区使用；
- 然后，有一些文章、博客开始介绍这种技术，然后有一些先行者宣城在项目中尝试这种技术，并取得了不错的效果；
- 然后，越来越多的媒体、业界大会都在介绍这种技术，越来越多的公司引入这种技术，一些激进人士宣称不采用这种技术将被淘汰；
- 然后，大量开发人员开始认识到这种技术的重要性，纷纷纳入自己的学习计划，在项目中引进；
- 然后，有些人开始发声，项目中引入这种技术后出现了一些奇怪的问题；
- 然后，越来越多的人开始发声，此种技术只使用解决特定的问题，不适用所有场景，要客观对待；
- 然后，此种技术导致的问题越来越多；
- 最后，某一团队发现了一种新的技术，可以解决这些问题（从第一步开始循环）；
其实，新技术本身并没有对错，关键在于使用的人，是否把它应用在正确的场景中；比如NoSQL数据库刚流行时，所有项目都从RMDB切换到NoSQL数据库，结果有些项目很成功，有些项目一塌涂地；
要判断一项新技术是否适合当前项目，可以这样尝试：
- 假定一种业务场景；结合这种技术，设计几个用例；
- 花费两天时间，使用这种技术实现用例；
- 总结，业务场景是否正确满足？
- 然后开始下一轮
多尝试几种典型的业务场景，不要怕花费时间，这比切换后用来解决问题的时间少多了。
很多时候，并不是因为这项技术不好，而是我们没有使用正确的工具去解决特定的问题。
使用正确的工具
传统行业，比如木工，往往有一大堆工具，一个好的木工，知道在做什么工作时使用哪种工具，他不可能使用一把锯子完成所有的工作；
在软件开发中也是一样，我们项目开发中会面临多个问题，需要学会辨别什么样的工具解决什么样的问题；
做出明智选择
作为架构师，需要保持独立的思考能力，不能因为大部分人都在使用这项技术而做出决定在项目中应用这项技术：
可以结合自己所了解的信息，从以下几点来考虑：
- 我的项目当前面临的是什么问题？需要哪些改进？
- 这个决定影响整个团队，还是仅仅一个应用？（因为公司范围的项目，技术仅是衡量因素中的一点）
- 公司内部是否已经有一个类似的技术可以解决这些问题？（如果有，需要进行技术对比选型）
- 这项新技术的引入对开发团队有多大的影响？（需要考虑开发习惯和学习成本）
- 这项技术在下一阶段将会怎样演进？（我们不能预测，但可以根据经验给出大概方向）
不要害怕做出决定，因为时间拉长来看，你当前做出的决定必定是错误的_
其它
技术人员总是乐于尝试新的东西，但在项目中使用需要慎重。作为架构师，需要进行把关。我们最好沿着已经铺好的路行进，因为这些已经被证实过切实可行，且有现成的经验，和成熟的支撑体系。
当技术人员自己重新造轮子时，所有的坑都要再趟一遍，时间和金钱的代价非常大。
如果阻止不了这些事情的发生，则事先声明“YOU build it, YOU own it”，让它自己承担这样做的后果。
实践
既然已经明白了分析技术的优缺点的重要性和方法，那么需要尝试一下练习这项分析技能：
- 创建一个流程图，详细描述各个决策点，用以决策在一组相似技术中寻找合适的技术；
- 选择一项你认为当前应该采用的技术，列出优缺点表格；将之与项目中当前使用的技术对比并分析；
- 选择你擅长的一项技术，然后分析可以去掉哪些特性以保持竞争力；
架构思考读书笔记 一
架构思考读书笔记 二
架构思考读书笔记 三
架构思考读书笔记 四
架构思考读书笔记 五
架构思考读书笔记 六
网友评论