为什么你总是无法做出正确的判断

时间：2022年08月10日

作者：小蒋聊技术

邮箱：wei_wei10@163.com

微信：wei_wei10

【20220810】为什么你总是无法做出正确的判断.mp3https://www.ximalaya.com/keji/51588599/559914772

大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

最近小蒋带的技术团队在技术选型的过程中可谓四处碰壁，腹背受敌。为什么你总是无法做出正确的判断呢？今天小蒋邀请大家，咱们一起来共同分析，共同学习一下在技术选型的过程中，我们该如何做出正确的判断。

背景

先和大家同步一下背景，事情是这样的，我们的客户对正在使用的一个调研系统，提出问题。目前调研系统采用单机架构，如果未来客户那边的数据量大了，目前的系统架构会不会容量不足？算力不足？是否需要调整方案，优化架构？引入大数据解决方案？

我们自己团队提出的方案是引入clickhouse，客户那面建议我们使用StarRocks。

过程

在这样的背景下，技术团队开了个技术选型会，在开会讨论的过程中，小蒋问了两个问题：

1.    “客户目前系统，在多大数据量下会开始算力不足？”

2.    “哪个模块会最先算力不足？”

结果是，坐满的会议室里，每个技术同学都有自己的见解，各抒己见，那可谓人声鼎沸啊！

面对这种局面小蒋心里在思考，“这可如何是好！”

为什么你总是无法做出正确的判断

我记得达尼尔卡尼曼教授曾经写过一个本书叫《噪声》，这本书中讨论过人类判断的缺陷，也就是说，到底是什么东西在影响我们的判断力。

作者上来举了个例子，说ABCD四个队去射击，A队全部命中红心，而B队则全部命中了左下角，相对来说B队应该是偏差队，什么意思？就是说B队可能水平没问题，而是他们的枪有问题，否则怎么会那么巧，全部都集中在了左下角？而C队的子弹落点很分散，这就是噪声，没有明显的偏差，所以能得出结论，C队很可能他们不太擅长射击。D队是噪声与偏差共存，明显偏离了靶心，但是都朝着一个方向偏离。但又偏离的很发散。所以判断，D队，既不擅长射击，枪也有问题。射击只是一种隐喻，靶心就是我们生活中的各种目标，也就是说，我们会经常受到各种偏差和噪声的干扰。从而造成了脱靶的现象。

从开会讨论的这个过程来看，小蒋个人认为我们属于C队，也就是子弹落点很分散，每个人都有自己的观点和看法。

这在技术团队中，问题就严重了。每个人对同一个事情，都有自己不同的看法，观点甚至截然相反，1000个人眼中有1000个哈姆雷特。同一个问题，给不同的技术人员评估，结果得到的结果大相径庭。如果管理者不懂技术，拿到这些结论之后，你反而没有主意了。跟没评估过一样。在充满噪声的系统中，错误并不会相互抵消，反而只会累加。

有时候过程比结果更重要

有判断就一定会有分歧，因为判断的依据就是经验，不同的经验，你自然就会对一个事情，有完全不同的判断。而评判判断的方法就是结果和过程，有时候过程比结果更重要。比如一个孩子通过作弊的方式，考了满分，这就是结果正确，但过程错误，如果要只看结果不看过程，那么他以后就会反复作弊，最终走上不归路。

技术选型这件事，小蒋个人认为在技术团队中可以称为重大决策，比如你高考考上哪个大学，毕业之后选择哪个单位，这都属于单一决策，这些决策，往往构成了人生的岔路口。如果这些选择做不好，那么人生再努力可能也是徒劳，我们的技术架构的发展也是如此。

在软件开发领域，几乎每天都有新的技术框架诞生、更新，一些新的概念更是层出不穷，技术选型时，难免让人无从抉择。所以想靠着判断去做好技术，这几乎就是痴人说梦。

我们技术团队需要持续学习，积累，沉淀。这个时候，过程比结果更重要。小蒋要帮着技术团队共同成长。

技术并不是越新越好

这次技术方案的选型是clickhouse 和 StarRocks。

ClickHouse是由俄罗斯的第一大搜索引擎Yandex公司开源的列存数据库。

StarRocks 是开源的新一代极速全场景MPP数据库。它采用新一代的弹性MPP架构，可以高效支持大数据量级的多维分析、实时分析、高并发分析等多种数据分析场景。StarRocks 性能出色，它采用了全面向量化技术，比同类产品平均快3-5倍

很多研发同事都曾经跟小蒋聊过这个问题：“新技术是不是比旧技术好”？

小蒋归纳起来，大致有几个原因：

1. 旧的技术已经被淘汰了，学了等于白学；
2. 找工作的时候，怕人家单位用的全是新技术，还要再学一遍；
3. 新技术更“高级”一些，学新技术才能学到更多的东西；

这是站在研发工程师的视角，我完全可以理解。如果站在架构师的视角，小蒋认为这些想法是错误的，至少是值得商榷的。

小蒋来分享一下自己的观点：

1. 绝大多数的公司，正在使用的，都是“旧”技术；
2. 而且公司越大，技术越旧，例如“京东“；
3. 越是核心的功能，越是使用的“旧”技术。

为什么呢？小蒋认为有两个主要原因：

1. 历史代码。代码不是一天就写完的，越是大公司，历史代码越多，写这些代码的时候，根本就没有现在这些新技术，只能是“旧”技术啊。生产环境的代码，也不是说想改就能改的，改出问题来了咋办？牵一发而动全身，很多历史代码，后面的人碰都不敢碰——尤其是核心代码，出问题了咋办？深水炸弹啊！这锅谁敢背？
2. 新技术风险。即使是我们从头开始一个项目，也不宜立马就上新技术。这方面，越是大公司越谨慎。通常都是等别人先雷区踩一遍了再说，即使采用新技术，也是从最外围最不核心的功能模块开始，逐步逐步的迭代展开。

相反是一些创业型公司，或者一些小公司，没有任何历史包袱和风险意识（当然，新技术风险对他们这种项目的伤害也不大），才会风风火火的上马新技术。

当然，任何事情都有例外，比如google这种大牛，连开发语言都是他自己捣鼓出来的，小蒋我也只有膜拜的份！

另外，现在很多新技术和老技术都是并存的，在不同场景，哪个技术有优势就用哪个技术，在容器化部署的今天，资源早就不是什么难题了。

咱们来看京东物流的大数据平台Udata，改造前的数据流程架构：

再来看，改造后的数据流程架构：

这次架构升级，根本不是clickhouse 和 StarRocks选谁的问题，而是在京东原有的ClickHouse 和 ElasticSearch 基础上引入 StarRocks，实现了极速的单表和多表查询能力。在成熟的公司里，架构升级很多情况都是引入新技术，问题的难点通常都是如何兼容上。

总结

小蒋个人认为，技术并不是越新越好，而是越精越好。架构也不是越全越好，而是越合适越好。因为越是高级的架构越是复杂，越是要求技术团队技术精湛，越是投入成本高。

核心技术团队需要与公司业务情况和规模相匹配，核心技术团队是用来支撑公司底层技术架构的，需要一个点一个点解决基础问题。业务的整个“面”，是需要技术核心团队一个“点”一个“点”来突破的。

如果公司在初创阶段，小蒋建议先从小团队开始，老实说管人可是一个体力活，而且也是一个技术活，人多了未必就是等效的增加，有的时候人员增加一倍，反而团队的效率还不如不增加。大部分企业都是在快速装人的过程之中，出现的巨大问题。

初期阶段，核心技术团队建议：

     人员规划：3人

• 持久化方向：1人
• 缓存方向：1人
• 运维方向：1人

年龄的增长不可怕，可怕的是从未成长！

感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。