架构思考读书笔记 四

评估并选择技术

评估标准

文档

是否拥有完整的文档体系，这点很重要；不要相信所谓的代码及文档的说法；可以从以下几点考虑文档的价值：

1. 是否及时更新（文档内容和软件版本匹配）？
2. 是否提供入门文档？
3. 是否提供深入的知道及样例文档？
4. 是否提供有详细的接口文档？
5. 文档描述是否清晰？

社区

1. 社区规模以及活跃程度如何（一个活跃的小社区远比死气沉沉的大社区有价值的多）？
2. 社区友好度（是否欢迎新成员并及时提供帮助）；
3. 社区的价值共识是什么（你是否认可）？

贡献者的多样性

1. 很多大型的技术社区背后往往有公司支撑；这时就需要考虑，如果这些公司不再赞助，将会发生什么？
2. 社区本身是否足够强大到，可以忽略这个影响？并自行继续发展？

代码库

一般情况下，在使用某种技术时我们不必阅读源码，但是，如果使用的是开源技术，而且对我们的项目影响比较大，还是建议去阅读代码；从以下角度衡量代码本身：

1. 可读性如何？
2. 是否有完备的测试？
3. 我们是否可以提交issue或修复补丁？
4. 必要时我们是否可以fork代码？

可测试性

1. 这项技术是否鼓励开发人员测试？
2. 是否方便开发自动化测试程序？

更新历史

1. 最后一次提交是什么时间？
2. 最后一次发布是什么时间（成熟的软件或将死的软件发布周期都很长，需要学会区分）？
3. 检查issue列表（是否长期有大量未修复issue）；

成熟度和稳定度

1. 不要仅仅判断版本号（不同软件版本号规则不一样）；
2. 新版本是否稳定（是否可以立马升级，还是要等几个小版本的修正后再升级）？
3. 新旧版本接口是否兼容？
4. 新版本升级是否需要做代码变更？

扩展性

1. 是否拥有插件体系或模块化设计或保留扩展点，可以方便的增加新能力？
2. 或者是只能给社区提需求，等待他们不可靠的排期？

支持

1. 是否有渠道购买商业支持？
2. 是否有在线求助渠道（问答社区、论坛等）？
3. 看看在Stack Overflow中此技术的话题？

培训

1. 是否可以找到商业培训资源？
2. 如果没有的话，是否方便自己构建（比如官方的指南文档，样例等）；

招聘

1. 是否可以方便招聘到拥有此技术的开发人员（可以尝试到招聘网站上搜索）；
2. 这项技术在其它地方是否出现过（技术大会，技术论坛，业界专家博客等）？
3. 我们的开发人员如何看待这项技术（如果大部分人反对，最好分析下是否有必要采用它）？

公司匹配度

1. 此项技术和公司文化是否匹配（如果不匹配，务必慎重考虑）？
2. 推行此项技术是否有政治阻力？
3. 公司内是否已经存在有相同技术（如果有，需要慎重分析，给出合理理由决定采用哪种技术，并公开）？

安全性

1. 此技术是否有一致的安全问题？
2. 安全问题是否被快速修复？

授权

1. 此项技术是哪种License？
2. 如果开源技术，需要判断使用方式是否合法？
3. 如果是商业技术，务必和供应商洽谈好（并做好背景调查，资金是否充足，是否稳定，已有客户是否满意等）；

使用程度

看看大众接受度，如果仅有极少的人在用这项技术，那么可能是两种情况：

• 情况一：技术比较烂，不实用，没有人愿意使用；
• 情况二：技术有点超前，大部分人未意识到这是一块没有打磨的宝石；

具体是哪种情况，需要架构师仔细分析并判断；

使用表格方式评估

根绝上面列出的这些评估项，也可以加入自己关注的项，然后给每项进行打分，也可以再给每一项分配一个权重（具体以当前项目的需求确定），最终计算出评估结果。

找到证据支撑

一般，一项新技术诞生时，我们能做的仅仅是纸面上的评估。其实，更重要的是第一手的信息，但是这些信息我们很难拿到。不可能通过写一个HelloWorld程序，就可以对这个技术做出全面评估。

我们需要首先明确我们的需求应用场景，然后分析出关键的用例，找出我们重点关注的点；然后在官方的样例上去尝试实现这些点，通过这个尝试，我们可以更进一步得出一些评估信息。

通过这个过程，我们也可以发现一些风险点，作为架构师，我们的工作就是尽早尽量发现风险，并做出预警，给出应对方案；

记住，风险并非是坏事。只要我们管理、应对得当，甚至可以给我们带来意想不到的好处。

政治

技术人员之所以喜欢技术，因为它是完全客观的，不是0就是1；但是，我们在工作中不可能脱离办公室政治，特别是架构师在推行工作时，一定要充分考虑到这方面的内容。

• 务必理解目前的办公室政治，可以和呆的最久的老员工交流，了解到这些信息。
• 哪种技术在推广时遇到的阻力最大？为什么？
• 考虑你要替换的技术当时为什么会引入？谁引入的？他对你将要替换他会怎么想？
• 确定哪些人对这个有决定有影响力？把他们尽量拉拢在一起，达成共识，形成同盟；
• 决策者对这个决定会怎么想？如果他们不同意，你需要想办法改变他们的想法；

另外，关注决策者或技术主管面临的问题，或想要达到的效果，如果你的技术刚好可以解决这些问题，尽情的去推销吧；

此外，如果依然不行，而且没有人直接阻止你这样做，那就大胆去做吧，因为“去的原谅，永远比取得授权要简单得多”，可以先斩后奏。不过，这样做之前先衡量下目前自己的位置，如果已经朝不保夕，建议先放弃。

名义上的变革

很多时候公司或组织所宣称的变革，其实名不副实，很有可能会换汤不换药；你强力推荐的新技术可能不会被采用，却会强制使用一个办公室政治所产生出来的一种技术或工具；一般情况下，这个结果不会有什么变化，除非你有足够的影响力。很多公司都是中心化的决策组织，所以，当你的提案提交上去之后，你除了祈祷之外，别无选择。

所以，当决策对你有利的时候，你很幸运；不过，当看到不利于你的决策是，也不要沮丧，这才是正常的情况。这时候，你能做的，就是这些：

• 第一步，再仔细分析对比，是否自己之前的选择有误；
• 第二步，如果确信选择正确，那么结果已经不可变，那么就尽量减少影响，如果增加代理层，将此项技术相关内容进行隔离，方便以后替换，也减少发生问题的影响；
• 第三步，合适的时机再提案自己的技术（当已有框架发生解决不了的问题时）；

另外，还有一点，如果对决策不满意，需要尽快做出自我调整，找到释放的方法，不要带着情绪工作，因为只有你对自己的职业生涯负责。

你应该如何选择

这个没有一个固定的答案；你的决定影响的范围越大，你应该拉更多的人进来，以达成一致意见；

当为项目组做决定时，你需要把做决策的过程透明的呈献给大家，即使别人不统一你的决定，至少看到你的努力；
甚至可以发现，你决策过程中的疏忽点，从而影响整个决策；

实践

既然已经认识到决策过程的重要性，以及办公室政治的影响，可以做以下尝试：

对比两项相似的技术：

• 你选择怎样的评估标准？为什么？
• 你偏向选择哪个？为什么？

考虑一个你正准备向公司建议的一项技术：

• 目前存在什么样的政治阻力？
• 你怎样去做来化解这些阻力？

架构思考读书笔记 一
架构思考读书笔记 二
架构思考读书笔记 三
架构思考读书笔记 四
架构思考读书笔记 五
架构思考读书笔记 六