评估并选择技术
评估标准
文档
是否拥有完整的文档体系，这点很重要；不要相信所谓的代码及文档的说法；可以从以下几点考虑文档的价值：
- 是否及时更新（文档内容和软件版本匹配）？
- 是否提供入门文档？
- 是否提供深入的知道及样例文档？
- 是否提供有详细的接口文档？
- 文档描述是否清晰？
社区
- 社区规模以及活跃程度如何（一个活跃的小社区远比死气沉沉的大社区有价值的多）？
- 社区友好度（是否欢迎新成员并及时提供帮助）；
- 社区的价值共识是什么（你是否认可）？
贡献者的多样性
- 很多大型的技术社区背后往往有公司支撑；这时就需要考虑，如果这些公司不再赞助，将会发生什么？
- 社区本身是否足够强大到，可以忽略这个影响？并自行继续发展？
代码库
一般情况下，在使用某种技术时我们不必阅读源码，但是，如果使用的是开源技术，而且对我们的项目影响比较大，还是建议去阅读代码；从以下角度衡量代码本身：
- 可读性如何？
- 是否有完备的测试？
- 我们是否可以提交issue或修复补丁？
- 必要时我们是否可以fork代码？
可测试性
- 这项技术是否鼓励开发人员测试？
- 是否方便开发自动化测试程序？
更新历史
- 最后一次提交是什么时间？
- 最后一次发布是什么时间（成熟的软件或将死的软件发布周期都很长，需要学会区分）？
- 检查issue列表（是否长期有大量未修复issue）；
成熟度和稳定度
- 不要仅仅判断版本号（不同软件版本号规则不一样）；
- 新版本是否稳定（是否可以立马升级，还是要等几个小版本的修正后再升级）？
- 新旧版本接口是否兼容？
- 新版本升级是否需要做代码变更？
扩展性
- 是否拥有插件体系或模块化设计或保留扩展点，可以方便的增加新能力？
- 或者是只能给社区提需求，等待他们不可靠的排期？
支持
- 是否有渠道购买商业支持？
- 是否有在线求助渠道（问答社区、论坛等）？
- 看看在Stack Overflow中此技术的话题？
培训
- 是否可以找到商业培训资源？
- 如果没有的话，是否方便自己构建（比如官方的指南文档，样例等）；
招聘
- 是否可以方便招聘到拥有此技术的开发人员（可以尝试到招聘网站上搜索）；
- 这项技术在其它地方是否出现过（技术大会，技术论坛，业界专家博客等）？
- 我们的开发人员如何看待这项技术（如果大部分人反对，最好分析下是否有必要采用它）？
公司匹配度
- 此项技术和公司文化是否匹配（如果不匹配，务必慎重考虑）？
- 推行此项技术是否有政治阻力？
- 公司内是否已经存在有相同技术（如果有，需要慎重分析，给出合理理由决定采用哪种技术，并公开）？
安全性
- 此技术是否有一致的安全问题？
- 安全问题是否被快速修复？
授权
- 此项技术是哪种License？
- 如果开源技术，需要判断使用方式是否合法？
- 如果是商业技术，务必和供应商洽谈好（并做好背景调查，资金是否充足，是否稳定，已有客户是否满意等）；
使用程度
看看大众接受度，如果仅有极少的人在用这项技术，那么可能是两种情况：
- 情况一：技术比较烂，不实用，没有人愿意使用；
- 情况二：技术有点超前，大部分人未意识到这是一块没有打磨的宝石；
具体是哪种情况，需要架构师仔细分析并判断；
使用表格方式评估
根绝上面列出的这些评估项，也可以加入自己关注的项，然后给每项进行打分，也可以再给每一项分配一个权重（具体以当前项目的需求确定），最终计算出评估结果。
找到证据支撑
一般，一项新技术诞生时，我们能做的仅仅是纸面上的评估。其实，更重要的是第一手的信息，但是这些信息我们很难拿到。不可能通过写一个HelloWorld程序，就可以对这个技术做出全面评估。
我们需要首先明确我们的需求应用场景，然后分析出关键的用例，找出我们重点关注的点；然后在官方的样例上去尝试实现这些点，通过这个尝试，我们可以更进一步得出一些评估信息。
通过这个过程，我们也可以发现一些风险点，作为架构师，我们的工作就是尽早尽量发现风险，并做出预警，给出应对方案；
记住，风险并非是坏事。只要我们管理、应对得当，甚至可以给我们带来意想不到的好处。
政治
技术人员之所以喜欢技术，因为它是完全客观的，不是0就是1；但是，我们在工作中不可能脱离办公室政治，特别是架构师在推行工作时，一定要充分考虑到这方面的内容。
- 务必理解目前的办公室政治，可以和呆的最久的老员工交流，了解到这些信息。
- 哪种技术在推广时遇到的阻力最大？为什么？
- 考虑你要替换的技术当时为什么会引入？谁引入的？他对你将要替换他会怎么想？
- 确定哪些人对这个有决定有影响力？把他们尽量拉拢在一起，达成共识，形成同盟；
- 决策者对这个决定会怎么想？如果他们不同意，你需要想办法改变他们的想法；
另外，关注决策者或技术主管面临的问题，或想要达到的效果，如果你的技术刚好可以解决这些问题，尽情的去推销吧；
此外，如果依然不行，而且没有人直接阻止你这样做，那就大胆去做吧，因为“去的原谅，永远比取得授权要简单得多”，可以先斩后奏。不过，这样做之前先衡量下目前自己的位置，如果已经朝不保夕，建议先放弃。
名义上的变革
很多时候公司或组织所宣称的变革，其实名不副实，很有可能会换汤不换药；你强力推荐的新技术可能不会被采用，却会强制使用一个办公室政治所产生出来的一种技术或工具；一般情况下，这个结果不会有什么变化，除非你有足够的影响力。很多公司都是中心化的决策组织，所以，当你的提案提交上去之后，你除了祈祷之外，别无选择。
所以，当决策对你有利的时候，你很幸运；不过，当看到不利于你的决策是，也不要沮丧，这才是正常的情况。这时候，你能做的，就是这些：
- 第一步，再仔细分析对比，是否自己之前的选择有误；
- 第二步，如果确信选择正确，那么结果已经不可变，那么就尽量减少影响，如果增加代理层，将此项技术相关内容进行隔离，方便以后替换，也减少发生问题的影响；
- 第三步，合适的时机再提案自己的技术（当已有框架发生解决不了的问题时）；
另外，还有一点，如果对决策不满意，需要尽快做出自我调整，找到释放的方法，不要带着情绪工作，因为只有你对自己的职业生涯负责。
你应该如何选择
这个没有一个固定的答案；你的决定影响的范围越大，你应该拉更多的人进来，以达成一致意见；
当为项目组做决定时，你需要把做决策的过程透明的呈献给大家，即使别人不统一你的决定，至少看到你的努力；
甚至可以发现，你决策过程中的疏忽点，从而影响整个决策；
实践
既然已经认识到决策过程的重要性，以及办公室政治的影响，可以做以下尝试：
对比两项相似的技术：
- 你选择怎样的评估标准？为什么？
- 你偏向选择哪个？为什么？
考虑一个你正准备向公司建议的一项技术：
- 目前存在什么样的政治阻力？
- 你怎样去做来化解这些阻力？
架构思考读书笔记 一
架构思考读书笔记 二
架构思考读书笔记 三
架构思考读书笔记 四
架构思考读书笔记 五
架构思考读书笔记 六
