前言
19年，在一些技术思维上形成了几点套路，不过目前还没有成体系，所以想到啥就写啥了，算是一个记录，避免自己以后忘了。
技术调研不要交给新手
技术调研是个技术上很有【挑战】，同时也是一个比较【艰苦】，也考验一个人的技术【品味】的任务。所以让一个新手去调研，这明显属于为难新手，并且大概率会得到一个不甚“真实”的调研结果。当然了，让新手调研也有其背后的“隐情”，因为新手毕竟能干的事比较少，而对于调研是一件重要不紧急，长期重要短期还好的任务，老手必须得拼命干活，所以对于领导而言，让新手调研也就变得顺理成章了。但是，为了一个大概率会有偏差的结果，同时还浪费了一个新手时间，是不是真的划算那就另外说了。有的时候错过一个技术，或者选型了一个错误的技术，都会给团队带来比较大的技术债务。
比如我调研Ray,为了获得一个较为全面的认知，我翻看了它多篇论文（它也在发展），看了大部分文档，同时结合我已有的知识，然后经过多次总结，最后才获得了一定的认知，而且即使如此，可能依然肤浅。所以，对技术调研保持一颗敬畏的心。
不要觉得中台是骗你的，白猫黑猫能卖萌才是好猫
无论别人心中的数据中台是怎么样的，我心中的数据中台核心就是掩盖复杂性，提供极简的交互手段，降低用户门槛，提升用户人效，让数据触手可及。 所以我之前解释说，中台的思想很简单，就是冰山模式，水面上漏出来的就几个API，一个Web控制台。但是底下可能是成千上万的机器，各种流，批跑在特定的分布式引擎上，权限，调度，预警监控，元数据体系进行配套，是一个非常复杂的体系。那和以前的数据平台的区别是什么呢？数据平台是让你可以DIY，降低业务侵入性，而中台则是包含了数据平台，同时带有业务，让业务放拎包入住，提升效益。
从我个人的实践来看，我们19年其实是按云的思路去发展我们的数据中台的。那为什么我们以前不提中台呢？因为以前技术上不允许，需要大量人力物力，而随着技术的发展，中台的冰山模式其实已经可行了，甚至小公司也能做到。可惜的是，还有很多企业在大数据和AI领域还处于刀耕火种的阶段，他们以为他们获得了稳定，其实是稳定和效率都没有得到提升，唯一带来的好处可能是996吧。 中台极大的降低了大数据/AI的使用门槛，可以囊括基本上公司的各个工种，让他们都能够在中台上玩，各取所取。算法，研发，分析师，搜索，推荐，运维，运营，产品经理，设计，商业，销售，包括老板。
多组合已有特性，而不是去开发新的特性
使用MLSQL的同学，经常会问到的一个问题是，有没有if/else,或者while循环的语法。我会说有基于现有的语法，有很多变相的实现。一听到这话，大家都会心里没底，会说出自己的疑惑：
有一些可以 有些可能变相实现比较麻烦或者很难做到，后续我有这块需求解决不了的时候看来是要找你给方案了
我通常会怼回去：
你都不知道我说的变相实现方案是啥 你就觉得变相的方案会麻烦了？
之后我会详解引入if/else和while循环的坏处，毕竟即使写程序，我们也是很努力的避免去使用他们：
祝威廉：如何优雅的消解[If/Else森林]
现在如果加上了他，面对千行的脚本，阅读和维护就会变成巨大的灾难，而用户往往会因为引入了特性，又会引入新特性去解决新引入特性的不足，最后结果就是：
这个系统太重了，我们需要去找一个轻量一点的
我们似乎会在这个循环中进入永生。
所以我们应该通过加深对一个系统的了解，从而通过组合已有的特性来完成需求而不是要求新特性去解决一个需求。当然了，我们不是说不进步，而是多尝试阻止自己，能用已有的特性解决这个问题么？确实解决不了，我们是不是能够重构已有的特性？最后确实不行，我们才考虑增加新的特性。保持身材，控制摄入卡路里是需要的。
痛点驱动结合效率驱动
在我们的内心世界，我们认为痛点驱动是一个理所当然的事情。只有有了痛，我们才有动力去解决它。奈何能感受到痛点的是人，而人基因里就包含了一件事，就是会忍受，会适应。比如你一开始觉得房间有异味，但是随着时间推移，也就会忘却异味的存在。所以，人们可能痛着，却意识不到痛的存在。大部分人害怕的意见事情就是“改变”，改变现有的模式。所以当用户已经感知不到痛，而你看到了，并且要去改变这个痛，人们就会抵触，因为他们已经感觉不到，但是你却要尽心改变，改变已有的工作模式。所以，从人性角度来看，光有“痛点”，是难以持续推动一个团队或者公司前行的。
这个时候，我们需要有一个新的“高阶”驱动，就是效率驱动，效率源于老板或者资本家对利润的追求。效率提升意味着成本降低，同时产量提升的空间也会变得更大，卖出更多的产品。这意味着这个驱动才是和老板的终极目标是一致的，并且效率也确实应该是我们“工人阶级”需要追求的东西，有限的人生不应该浪费在重复的事情上。所以，无论团队有没有痛点，我们核心看效率，这包括人效，团队总体效率。如果低了，我们就要思考，能通过新的技术手段提升么？能通过新的管理手段提升么？能通过新的流程提升么？
这两年，尤其是今年，我核心的工作之一，就是“巡视”，查看每个人的效率，每个环节的效率，如果发现不满意，我会整合各方面资源去解决这个问题。可以参考我18年的一篇文章
为什么需要效率督查团队
关心技术趋势
很多对技术持有保守心态人，总是希望某项技术烂大街以后再买入，但是技术本身并不是凭空而来的，而是实际的需求驱动的。这意味着，当它烂大街的时候，其实可能已经不能支撑现阶段公司业务的诉求了。比如现在已经进入数据湖阶段了，意味着业界对数据的需求也只有数据湖才能更好的支撑了，因为人们对于实时，增量，更新等等，对于AI有了更多的需求。你这个时候还在守着传统的数仓，意味着你严重的限制了公司的业务需求，使得公司的业务是落后于其他公司的。当其他的公司能够实时跟踪某个宣传活动的效果时，你还停留在一天以后才能知道，当其他公司的运营查看一个数据只需要一分钟，你们公司还需要研发配合，一周才能交付一个数据结果，公司还能和其他公司竞争么？但求无错，但无错可能最后导致了公司积重难返。及时看清技术发展方向，少走弯路，尽快引入明显是未来趋势的技术，在跟进的过程中让团队慢慢掌握这些技术，等它烂大街的时候，我们也已经吃透，并且让其产生了最大的价值，这个时候我们才有精力进一步引进新的技术。及时引入，也能让我们从容不迫小步迭代使用，现在不重要的业务线尝试，慢慢积累经验，然后渐渐引入更多的业务。
关心技术趋势，拥抱新的技术。只要用正确的方式和态度去做，并不会给“稳”带来隐患。
插件化也是中台的必要特征
MLSQL不断在的拥抱新的技术，包括数据湖，Ray, Apache Arrow，同时也在产生一些新的创新，包括增量同步相关的项目
祝威廉：是时候改变你数仓的增量同步方案了
这必然会导致项目异乎寻常的庞大，加上MLSQL本身也能作为数据中台，必然带有大量业务开箱即用的功能，这又会进一步庞大项目。所以插件的引入是非常必要的。所以数据中台还具有一个很重要的特点，就是有优秀的插件体系，插件可以是针对进程的，也是可以进程的。比如我提供了一个符合中台标准的API，这我们也可以看做插件。从而使得中台可以快速的迭代。所以我们不要把插件就看成率属于某个进程，而是要把它作为一个大体系的一环去设计。所以中台本质是一个大的架构体系，他以某一个平台为中心，衍生了一大批周边辅助系统，最后完成中台。
研究技术 千万别只顾自己兴趣 一定要和公司的需求保持一致
双赢毕竟是最好的。只顾自己或者只顾公司，都不太好。只顾自己，弄了一堆东西，但是没办法落地，得不到检验，这些东西顶天也只能算是个知识，不牢靠，价值也不大。如果占用时间比较多，难以有产出，在公司也会处境艰难，很容易被其他人替代。只顾公司，则很难完全激发个人的潜力，容易碌碌无为，公司也无法从从你身上得到最大化收益，你自己也无法为自己产生最大化收益。在其位，谋其政，是本分。努力将自己的兴趣和工作有效的结合，则能最大化双方收益。
总结
暂时就想到这些，下次还想到别的，到时再补充到文章里。
