程序员与新技术之间的「爱」与「恨」

若是第二次看到个人文章，欢迎 「文末」扫码订阅我我的的公众号（跨界架构师）哟~
每周五早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个层次（顺序由初级到高级）：

1. Stranger（陌生人）：据说过没实践过，只是知道一点术语、人名等。
2. Tourist（旅行者）：实现过一个完整功能。
3. Resident（居住者）：了解这项技术能作什么，不能作什么。
4. Architect（架构者）：有改进这项技术的能力。

Z哥我我的认为，负责运用这个新技术的人至少要达到「旅行者」水平，才是一个比较稳妥的状况。

若是你的团队中有一个「居住者」能够随时去咨询，那就更棒了。

关于「人」，还有一点多是不少没作过leader的小伙伴不太会有感受的，就是人员流动性致使的「单点风险」。

若是一项新技术引入后，将它引入的人员没过多久撂摊子走了。按照劳动法，这我的能够只停留最多1个月。若是再遇到那种职业操守差一些的就更麻烦了……

想象一下假如你是leader，这事发生在你头上，是否是很头疼？虽然额外多花点精力也能搞定，但这中间的风险和成本实际上是整个组织在承担。

最后，第三个维度——「技术」。

Z哥认为对「技术」的关注点主要看三个方面。

第一，关注技术的优缺点，取其长避其短。能够问本身如下几个问题：

1. 基于当前的技术栈是否有解决方案？与之相比，新技术的优点在哪，是否显著？
2. 是否将全部潜在的解决方案和新技术都归入考虑范围了？
3. 全部的解决方案中，当前这项新技术的优点体如今哪儿？
4. 使用新技术，会带来哪些新问题，严重么，咱们可否解决掉？（如运维、培训学习、潜在风险等）

关于第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个步骤，来让准备工做更加的深刻一些。

最后，借助经济学视角的解读，让你有了一个更理性的认识。

以上，但愿对你有所帮助。

推荐阅读：

我珍藏5年的10倍速阅读法

8个月打磨，一份送给程序员的「分布式系统」合集

做者：Zachary

出处：https://www.cnblogs.com/Zacha...

---

若是你喜欢这篇文章，能够点一下文末的「赞」。

这样能够给我一点反馈。: )

谢谢你的举手之劳。

▶关于做者：张帆（Zachary，我的微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描下方的二维码~。

若是你是初级程序员，想提高但不知道如何下手。又或者作程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注个人公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思惟导图。

若是你是运营，面对不断变化的市场一筹莫展。又或者想了解主流的运营策略，以丰富本身的“仓库”。欢迎关注个人公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思惟导图。

按期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些深度思考。