程序员与新技术之间的「爱」与「恨」
这里是Z哥的个人公众号
每周五早8点 按时送达
当然了，也会时不时加个餐～
我的第「80」篇原创敬上
5900字巨献奉上
我们大部分做技术的，对新技术是又爱又恨。
爱的是他能让枯燥反复的工作重新获得新鲜感。
恨的是新技术太多了，学不动啊。
真到了实际要运用的时候，不同人对待新技术的态度相差很大，有的看上去很积极，有的又看上去很排斥。
一般来说，技术团队的管理者往往是“排斥者”，而团队的成员是“拥抱者”的概率居多。
看看下面这个景象是不是很熟悉？
程序员小明：老大，XX系统太乱了，需要重构一下。我建议用XX技术，它的优点有XX、XX、XX。我开了一个分支，在项目中引入测试过了，没啥问题。重构应该要趁早，否则简直是煎熬啊，而且越拖改造成本越大。SDK都找好第三方的了，成熟的。有一千多个star，作者说它的性能比现在我们在用的要好上X倍。
Leader小王：为什么需要引入？ 你现在遇到了什么问题需要它来解决？
程序员小明：这不是正好打算重构嘛
Leader小王：他的缺点是什么？
程序员小明：……
Leader小王：引入的过程是怎么计划的？分几个阶段？预计的时间节点？
程序员小明：……
此时，小明的心里肯定有一万只草泥马奔过。这不就是典型的保守派反对革新派的最好体现么。
其实Z哥觉得，引入新技术是好事，也是一个组织寻求专业性进步的必经之路。
但是，你回想一下你工作中用到过的新技术，哪怕是引用一个很小的类库，有没有被“坑”过？我估计每个人都被“坑”过吧：D
这些“坑”其实是由于我们自己之前做出的错误选择所导致的。而导致作出错误选择的原因是因为，在对待新技术上，我们仅仅通过片面的信息做判断是不够的。
当你看到各大技术社区的官方公众号都在说某个新技术好的时候，有没有观察过，他们一年有说过几次什么新技术不好？
当你听说某个新技术以N倍性能碾压其它框架的时候，是不是有考虑过，信息提出者的测试方式是否严谨、客观？
哪怕在技术圈被广为认可的github star数，在某宝上都已经出现了提供刷star送fork的服务了……
不过这还不是最可怕的，最可怕的还属粉丝文化。因为XX在用，所以这玩意好；因为这是XX出的，所以这玩意好。
围城里的人总觉得外面的世界精彩，做技术的我们也是。随着时间的推移，老技术对我们来说越来越无趣，总觉得外面的新技术如此的美好。
Z哥仔细想了一下背后的原因，猜测可能是以下三点。
第一，放出消息的源头往往是新技术的创造者。
那自己肯定不会拆自己的台，所以你在网络上看到的新技术的信息，大多都是正面的。
第二，哪怕我们抱着求实的心态来选择，也会不自觉的将验证外界宣传的优势是否属实，作为优先考虑的下手点。
这其实就被引导到新技术擅长的方面去了，进一步扩散了新技术优点的传播。
相对的，缺点和缺陷是充满未知性的，创作者自己知道的信息也不一定全，要不然也不会产生bug了。
第三，经过大量正面舆论的熏陶，会让你对它“心生期待”。此时，你心里的天平就已经倾斜了，促使你只会看到自己希望看到的“有利”信息。
这正如，医生被打了，患者就大肆说打得好，而其它的医生就无比委屈的说这行没法干了。道理是一样的。
所以总的来说，相比一个新技术的优点，其实，它的缺点、或者说边界是什么，更有价值。
但缺点只有实际踩到坑了才会知道，这个需要投入时间去实践。再加上“揭别人短”相当于给自己树敌，代价是很大的，所以那些遇到“坑”的人愿不愿意分享出来还不好说。
其实，并不是所有的慎重都等于保守。
新技术、新理念的出现，自然有它的诱惑，技术总是在不断前进，拥抱变化本身没有问题。但是引入不成熟的技术看似能带来短期的收益，但是它潜在的风险以及间接成本（跨组织的影响、长期的维护成本等）可能远远大于收益。
所以，要“正视”新技术，我们还是要回到价值本身来看。
在产品经理届有一个很知名的公式，是百度贴吧之父俞军提出的：用户价值=(新体验-旧体验)-替换成本。
其实在技术领域也适用，我们来改造一下：技术价值=(新效益-旧效益)-替换成本。
带着这样的一个公式去思考，我们才能清楚的认识到这个新技术对你的意义到底是什么？
新技术理应让我们的工作能够开展的更好，而不是相反。
所以，我们除了要看到新技术的好处之外，还要思考好处的背面是什么？以及想想是不是有什么部分被我们忽略了？
Z哥认为可以从两个角度来考虑这个事情。
一个是考虑的维度要“广”
一个是准备的程度要“深”。
考虑的维度要“广”
“广”并不是单纯数量的多少，而是我们不能仅仅站在技术维度来考虑这个事情。
Z哥认为至少需要从3个维度来考虑，从重要性从高到底分别是：业务 > 人 > 技术。
首先，关于「业务」这个维度，我们要先弄清楚当前业务上面临的问题是什么，什么是最重要的。
我们必须贴着业务来选择，因为在不同的业务阶段，会有不同的选型方式。
初创期，最重要的是“灵活”、“快速”。
成长期，最重要的是“可靠”。
维护期，最重要的是“低成本”。
关于维护期，我想多说几句。我知道做技术的人中有不少是「完美主义」者，可能你会觉得「低成本」不就是将就嘛，得过且过。
这种感觉我懂。
但是作为一个过来人，我想劝你一句，回到现实。
代码永远有变乱的趋势，因为功能永远是增加多于删除的，代码复杂度会随着代码行数的增长而增长。
在维护期，你必须得正视各种遗留代码的迁移成本，如果改变技术选型会带来遗留代码重写，这背后带来的代价业务必然无法承受，那么我们就不得不考虑在现有技术选型之上做一些小修小补或者螺旋式上升的重构。
正因为技术选型和业务相关，所以你会发现身边的情况符合以下规律：
新技术往往被创业公司或大公司的新兴业务使用
中大型公司的核心业务则更倾向于用稳定的技术，至少三五年以上吧。
一个公司如果长期使用一种技术，就会倾向于一直使用下去，甚至连版本都不太愿意更新。
现在你应该明白了，这些现象背后都是有道理的。
如今的互联网讲究的是精细化，在运营层面讲究的是用户分层。其实我们做技术的也可以考虑精细化和分层。
除了前面提到的「初创期」、「成长期」、「维护期」三个粗粒度的时期，我们还可以在同一个时期精细化的“横切几刀”。
怎么切法？
其实就是再做一下归类。
短生命周期产品和长生命周期产品？
边缘产品和核心产品？
Z哥认为，只有长生命周期&边缘产品才适合引入新技术。
因为只有这样，你才有足够的时间去“踩坑”，不会半途而废。而且，也只有边缘产品才能有“命”支撑你折腾下去。
我们再聊聊第二重要的维度「人」。
康威定律深刻地影响着很多方面，技术选型也不例外。特别是做宏观技术选型时，必须考虑它在最终技术架构中的位置，以及与团队沟通结构的匹配程度。
即使是一项很先进的技术，假如它与体系中的其它技术栈不匹配，也可能导致翻车。
另外，团队里面必须要有负责任的人员能够hold住新技术。
那么，什么才算hold得住？
我觉得C++之父Bjarne Stroustrup在他的《A tour of C++》中对熟练度的分层已经有了很好的阐述。
他将程序员们掌握一项新技术的熟练度分为了4个层次（顺序由初级到高级）：
Stranger（陌生人）：听说过没实践过，只是知道一点术语、人名等。
Tourist（旅行者）：实现过一个完整功能。
Resident（居住者）：了解这项技术能做什么，不能做什么。
Architect（架构者）：有改进这项技术的能力。
Z哥我个人认为，负责运用这个新技术的人至少要达到「旅行者」水平，才是一个比较稳妥的情况。
如果你的团队中有一个「居住者」可以随时去咨询，那就更棒了。
关于「人」，还有一点可能是很多没做过leader的小伙伴不太会有感觉的，就是人员流动性导致的「单点风险」。
如果一项新技术引入后，将它引入的人员没过多久撂摊子走了。按照劳动法，这个人可以只停留最多1个月。如果再遇到那种职业操守差一些的就更麻烦了……
想象一下假如你是leader，这事发生在你头上，是不是很头疼？虽然额外多花点精力也能搞定，但这中间的风险和成本其实是整个组织在承担。
最后，第三个维度——「技术」。
Z哥认为对「技术」的关注点主要看三个方面。
第一，关注技术的优缺点，取其长避其短。可以问自己以下几个问题：
基于当前的技术栈是否有解决方案？与之相比，新技术的优势在哪，是否显著？
是否将所有潜在的解决方案和新技术都纳入考虑范围了？
所有的解决方案中，当前这项新技术的优势体现在哪儿？
使用新技术，会带来哪些新问题，严重么，我们能否解决掉？（如运维、培训学习、潜在风险等）
关于第4点还有两个延展问题：
如果这项新技术可以替代现有的一些方案，那么我们能不能保证将来把相关的开发都迁移到这项新技术上？
如果不能保证，那么如何确保这项新技术未来有足够的精力去“填坑”和进一步深入？
第二，弄清楚该技术值不值得“长期信赖”。这需要我们对它的发展前景有一定的认识。
建议你可以从以下6点来考量。
1.一项优秀的技术和企业一样，应该有其明确的定位和发展路线。清楚地表明自己要做什么、不做什么，以及未来一段时间的规划。
大多数情况下，说自己的框架“包治百病”、多么多么完美的，往往在未来等待你的是“大坑”。
2.有没有持续投入的人或者社区。开源技术的物质收益是微乎其微的，所以一项开源技术要想走的远，关键就看背后的支持者是谁。
这对个体来说是很难的，所以大部分情况下，选用背后有知名组织支撑的技术，会更靠谱一些。比如各大互联网巨头、XX基金会等。
3.问题解决的速度如何。这其实是对前面这点的补充，体现的是维护这个技术的组织活跃度和积极性如何。
想象一下，当你在生产环境遇到一个棘手的问题，提了一个issue但迟迟没人响应，是多么揪心的一件事。
4.源码质量。源码质量除了通过阅读代码获得的主观评价之外，还可以通过「单元测试覆盖率」来观察。因为单元测试体现的是维护者的工程化意识和能力。
5.文档质量。如果文档很杂乱的话，说明维护者缺少站在使用者考量的意愿。可能未来会有很多华而不实的功能出现。
6.开源协议。有的协议比较宽松，如BSD、MIT；有的协议相对严格，如GPL。大部分情况下，选择的协议越宽松，发展的速度和前景都会更好一些，毕竟对大家来说，自由意味着更少的顾虑，更广的运用空间。
第三，永远不要忘了「技术成熟度曲线」的存在。
有些新技术由于有大牛或者大公司背书，一经推出很快就成热门了。但是，几乎所有的新技术都得经历下面这么个周期。
▲图片来源于网络，版权归原作者所有
所以，我们还是要注重技术推出的时间有多久，以及业界有多少实际的使用案例、口碑如何。以此来判断现在是不是处于「稳步爬升期」和「成熟期」。
真正搞清楚了上述「业务」、「人」、「技术」这三个维度的考量，心里就“有谱了”。
接下去再通过几个步骤的充分准备，层层深入。
准备的程度要“深”
Z哥建议的准备过程是分为5个步骤。
前面四步本质上就是一个筛选的过程，越往后剩下的方案会越来越少。
第一步「调研」可能很多人都做过，本质就是一个收集信息的过程。
看似最简单的一个事情，只要手指点点。但恰恰是最大程度体现新手和高手差距的地方。
因为，虽然大家输入的信息一样，但是高手往往能看到更多的复杂性，识别出更多有价值的信息。
其实，做好「调研」工作的关键就是要先搞清楚你想了解哪些信息，带着目的去收集。
前面一节「考虑的维度要“广”」中讲的内容就是一些普适性的有价值信息。你可以先照着这些点去收集信息。
第二步「候选对比」。大多数情况下，解决一个问题的方案是存在多个的。所以这一步就是将你从外部收集到的信息，整理成一个方便对比的格式，比如下图这样。
我见过很多的准备工作做到这步就结束了，就开始决定用哪一个了。
毛主席说过，“实践是检验真理的唯一标准“。所以我们需要继续做第三步，「关键技术验证」。
通过亲自动手，验证每个选项中看上去最具优势的几个点是否属实，并且搞清楚它背后的原理以及同时存在的副作用。这才是知其然的同时，知其所以然。
另外，如果对性能很重视，那么亲自去压测一下是必不可少的。特地标红强调一下：D
如果是一个「长生命周期&核心」产品的技术选型，可以考虑进行第四步，「场景验证」。
找到该项目中的最重要的场景，将可预知的极端情况搭建成原型Demo，进行验证，并在多个方案之间进行比较。
比如，将它们放到真实的海量数据场景里，看看到底哪个对数据量的支撑做的更好。
至此，你终于得到了一个经过你质量认定的解决方案，离开始运用只剩最后一项准备工作了，「制定实施计划」。
实施计划会千差万别，但是一份好的实施计划肯定是满足以下两个要素的。
始终将“怎么降低风险”放在第一位。
接地气，循序渐进，而不是“一刀切”。
以上工作全部做完之后，我们会形成一份这样的《引入XX类新技术方案》的文档。
▲公众号后台回复「引入新技术SOP」可获取该模版
大功告成！
经济学视角的解读
如今，软件开发行业中的开源力量越来越强，在这个充满诱惑、充满选择的时代，保持理性、客观显得格外的重要。
最怕自己学会了这种新技术后，就会有种“拿着锤子找钉子”的感觉，将新技术滥用于各种项目。
鞋子好不好，只有脚知道。
但是当你脚感觉到不舒服的时候，已经晚了。你不得不忍着再走一段路。
新技术的引入其实也可以用经济学来解释。经济学中一个很重要的观点是：有选择就有成本，你放弃的最大价值就是你作出这个选择的成本。
例如，当你选择引入新技术的时候，其实你放弃的就是过去所积累的稳定性。能否将可能要承担的风险控制在放弃的价值之下呢？
当然了，过度的保守主义也是不提倡的。因为经济学中还有一个很重要的观点：沉没成本不是成本。
当你已经投入了很大的力气去优化老的解决方案，但还是无法达到你的要求的时候，不要舍不得，应该果断的选择更换。
因为老方案的未来价值很小了，为了坚持拿着今天的这个“芝麻”，你放弃的可能是后天的“西瓜”。
就像docker选择拥抱k8s，放弃了自己的“亲儿子”Swarm，也是为了避免未来丢了自己容器领域No.1的地位。
总结
好了，总结一下。
这篇呢，Z哥先帮你分析了一下，大家在引入一个新技术的时候常见的误区，以及应该如何科学的来看待这个事情。
其次，我建议从「业务」、「人」、「技术」三个维度来扩展你思考的“广”度，以及通过5个步骤，来让准备工作更加的深入一些。
最后，借助经济学视角的解读，让你有了一个更理性的认识。
以上，希望对你有所帮助。
推荐阅读：
原创不易，如果你觉得这篇文章还不错，就「在看」或者「分享」一下吧。鼓励我的创作 ：）
如果有希望我写一下什么主题的话，欢迎在后台给我留言哦～
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「阅读原文」