不聊技术的技术选型

内容来至：https://insights.thoughtworks.cn/choosing-technology-guide/，请查看原文。
以下是截取的部分内容：

有一些技术选型策略可能会导致灾难性的失败，这些选型中存在一些共同的反模式，比如：

舆论驱动选型

人云亦云，盲目听信外人或者某些布道师的主观性言论，这就是舆论驱动选型。它往往会带来灾难。

做任何决策时，如果要借助参考资料，请记住：最重要的不是它告诉了你什么，而是它对你隐瞒了什么，这些隐瞒的信息最终会置你于险境。

特别是当该资料的作者对某项技术具有显著的倾向性时，请深入想想，他向你推荐的每一项优点是否真的“对你”有价值，以及它背后的代价是什么。比如，推崇“自由”的技术往往不够“严谨”，如果你的产品需要严谨，那么请把“自由”看做减分项而不是加分项。比如，推崇“体积小”的技术在现在动辄几T硬盘、几M带宽的环境下，到底对你来说有多大价值？它是不是因为没有其它的优点了才把这种细枝末节亮出来吸引你？

即使是调查报告之类的客观参考资料，也需要了解其背景。比如一份只发给程序员的调查报告，可能会发现 Chrome 的使用率超过了 99%，但显然它对你的面向普通用户的产品毫无价值，只会给你带来风险。同时，要注意很多调查报告的设计是有主观倾向性的，甚至题目的排列顺序都会给最终结果带来 10% 以上的偏差。所以，一定要仔细分析其中立性、客观性以及调查对象在你的目标场景下的代表性。

单一指标驱动选型

根据任何一个单一指标进行选型都会给你带来灾难，更何况很多指标并不适合作为选型的依据。

有些指标很容易操纵，比如 GitHub 仓库上的 Star 就是很容易操纵的，在淘宝网上还有专门购买 GitHub Star 的服务，而 GitHub 的年度报告中也已经不再把 Star 作为主要指标使用。即使是那些不容易造假的指标，比如 commit 数量，其实也不适合作为主要指标使用，它可能意味着作者具有良好的工程习惯和足够勤奋，但也可能意味着代码库质量堪忧，因此不断推出补丁。

当然，有一些客观指标还是比较适合作为主要指标来使用的，但也不要盲目相信数字。比如单元测试中覆盖率较高的项目，确实通常质量比较好，但是我也见过一些只有调用却没有断言的测试，那些测试的覆盖率也会很高，但却是假的。所以，如果要评估其质量，最好还是亲自打开看一看。

即使你选出了一些主要指标，并且确信它们没有造假，也仍然不能简单地把它们加起来或加权平均来得出一个数字进行比较。你要综合评估这些指标对你的目标产品、目标用户、目标团队的价值。如果技术选型只是个数字游戏，那还要你干嘛？

话语权驱动选型

这几乎是最糟的选型，但却屡见不鲜。技术栈的更迭往往会带来话语权的变化，而这将给公司带来灾难。

对于高级技术决策者，需要有战略定力，应该以一种规范的、用事实说话的方式来控制技术选型的副作用。我曾见过一帮程序员“偷袭珍珠港”导致架构师被迫辞职的惨剧，我当时的意见是：这是 CTO 的锅。团队由于选择技术栈而产生了话语权之争，说明制度设计和文化建设出了大问题，这只能由 CTO 背锅。

所以，如果你是个技术决策者，那么应该尽早站出来，发挥你的职权和非职权影响力，抑制这些负面文化，而不是任由其发展，最终破坏公司的总体技术路线，甚至技术氛围。

粉丝驱动选型

对于生命线产品，最糟糕的选型莫过于粉丝驱动选型了，这次可没有“几乎”。对于技术人员来讲，最重要的特质是客观冷静，这样才能配得上“专业”二字。而拜大神，当作玩笑尚可，如果让它影响到你的决策，那么你就应该趁早隐退了，免得将来被迫引咎辞职。

虽然也曾被人称作“大神”，但我一般会提出反对，至少不作正面回应。我已工作二十多年，太清楚业界百态了。实际上，很少有人真的配得上大神的称号，举世可能只有 Anders Hejlsberg、Bob 大叔、Martin Fowler、Jeff Dean 等少数几位。不过我相信如果你当面叫他们大神，他们也会反感的。

就算是对于这些举世公认的大神，也不应该成为你技术选型的依据，顶多是相信他们会珍惜名誉、不会粗制滥造而已，因为即使是精品也仍然有着明确的适用范围，超出这个范围它也可能会成为毒药。

当然，对于边缘产品，进行粉丝驱动选型也未尝不可，甚至可能更好。只是得记住，要做就请做好，别给你的偶像丢脸，更不要做好之后就觉得公司一定要把它应用于生命线产品中。

注：侵删。