新技术适用性检查表

技术总会过时，但要不要立刻拥抱新的技术？还是观望一段时间再上？或者坚守老技术的阵地？

这里的「新技术」不限于新的语言和框架，新的手法、新的语言标准规范，甚至是新的管理理念都算是新技术。我希望能给出一些「合理」的方法来评价是否要引入一个新的组件到系统中，而不是一味地通过自己的直觉或者喜好认为「我们一定要有这个」或者「这东西根本不能用」。当然，这些清单只适用于多人合作的情况。如果是个人项目，那么自然可以尽情尝鲜。

为什么要引入新的技术

首先问自己一个问题：我为什么需要引入新的技术？新的技术是否能给我的系统带来显著的提升，比如性能上的提升或者空间上的提升？新的技术是否能给我带来一些技术上的优势，比如更快的迭代时间或者更好的解耦合？它是否能降低开发人员犯错误的概率，比如有更好的语法或者更好的静态检查？如果对于以上答案都是否，那么最后一个问题：是否因为其他人都在用，所以我必须用，否则我可能处于不利地位？如果连这个问题都是否，那么几乎可以安全地认为引入这个技术是不必要的个人偏好。

系统是否能重构

如果在上一问中任何答案为「是」，那么考虑：我正在编写或者维护的系统能否经历一次重构而不会导致主要功能崩溃，以及重构会不会耗费非常大的人力？如果系统本身是不可重构或者重构代价太大的，那么很遗憾，新技术的引入可能并不会减少任何工作，而是会增加负担。

新技术是否稳定

如果在上一个问题中的任何答案为「是」，那么考虑：这个技术是否已经足够稳定，你已经可以把它用于生产环境？如果这个技术非常新，以至于你需要在生产环境中使用每夜构建版，那么你是否能够承担这个新技术出现意外导致的后果？如果这个技术和团队以往接触的内容都不同，你是否能确保其他人不会错用这个技术导致意外发生？如果这些问题的任何一个答案是「否」，那么把这个技术用于生产可能还是为时尚早。当然，你可能会争辩自己只在最后一个问题上回答了「否」，因为你不信任你的队友。我个人认为，团队合作的最大特点就在于你需要照顾队伍里走得最慢的那个人。一个人走可以走得很快，但一群人走可以走得很远。

新技术的前景

最后一个问题：你认为这个技术是否有任何发展前景，它承载的思想是否足够支撑这套系统？

这个问题一般争议比较大。因为从用户的角度而言，很难判定一项新的技术是否有发展前景。更何况发展前景有很大一部分是商业支持决定的，社区只是起到一个催化作用而已。

这个问题对于内部 DSL 也很难回答。这套系统或许会长久存在， 但是是否每个应届生进来都会想着去改写这套 DSL, 或者写一套新的 DSL 来代替它？或者这套 DSL 存在的意义是稳定作者在团队内的地位，因为除了作者没人能维护这套代码？这样的新东西，是无谓的开销还是有益的尝试？

这个问题，可以不回答，或者凭直觉和喜好回答。这个问题虽然是一个「是或否」问题，但是实际答案远比我们想象的要复杂。

写这个文章的一是为了提醒自己不要过分地追求新的内容，尤其是不要为了技术而技术；二是为了能够所谓 "Defend your work", 给自己准备一个清单，避免在被问到时哑口无言。