|0x00 从一次会议说起
笔者最近参加了一个线下的交流会议，不仅邀请了一些领导参加，也有很多一线的研发工程师，大家针对某些具体的问题，展开相互的讨论。讨论的过程很有意思，首先请领导发言，领导就公司的整体情况进行了表述，同时对于接下来的管理重点做了一个总结，等领导发言之后，会场里的一线研发工程师们面面相觑，自然也就顺着领导的发言思路，对公司一些具体战略的执行，进行了分组讨论。讨论结束后，有个同学提出了问题，咱们这个会议的初衷是为了解决具体问题，但会议搞完了，好像我们并没有讨论任何具体问题。
为什么把这件事情提了出来呢？因为这里面涉及到了一个很关键的问题：领导与一线员工之间的信息不对称。现在企业是一个岗位职责非常明确的组织，对于领导来说，考虑公司的发展战略，是本质工作，但当本质工作的内容层层传递到一线员工之后，尽管大家都能够领悟领导的意思，但好像落实到工作中，总是差了那么一点，因为传递下来的只是个指示，但并没有人告诉你该怎么做。
解决的关键，就在于中层管理的团队。但受制于互联网的发展模式，从一线晋升到管理岗的人，往往是业务或者技术能力比较突出的人，而整个晋升的过程几乎不会围绕管理的能力而展开，因此当这一批专业人士进入到中层之后，大多数人就很难适应身份的转变，对于团队的管理，要么摸鱼，要么就是装装样子，而管理能力比较不错的中层，往往在专业领域的投入时间就会减少。于是，专业能力好的中层，管的让人很烦躁，而管理能力好的中层，又往往不那么让人信服，做一个好的中层，很难。
但是既然现实存在了不合理，就会存在改变的机会，而这种机会，就要看现在的一线同学，能不能敏锐的抓住了。笔者之前写过一篇文章，里面提到过大家要有一号位的心态，来做最普通的事情。其实大多数工作场景下，能做好自己的工作，去多管闲事，真的大可不必。但如果要跨过“中层陷阱”，学会在管理能力、理解公司战略能力、专业能力、落地能力之间找到平衡，为自己迈向更高的职级奠定基础，这些“闲事”，就不是浪费时间的行为，而是锻炼自己情商的机会。
任何一个领域，投入1万小时，都会做出一番事业。
|0x01 为什么会提出模型重构
笔者是做数据出身，在数据仓库领域，常常有“建模”的需求，其实在软件工程领域，“模型”的设计也非常重要。但是除了“建模”，还有一个问题，会伴随而来，这就是“模型重构”。为什么会出现“模型重构”？大多数人就没有深入的探讨和研究了，大多数是作为一项工作，或者是排期的需求来做，而没有真正深入探索“模型重构”背后的原因。
在一号位心态的影响下，让我们看看“模型重构”通常面临的背景：
看不懂：很多人在接手新的业务之后，都会有一种“看不懂”的心态在里面，比如为什么注释文档这么少、这么设计的原因是什么、代码规范做的真差…… 除非是长期投入的业务，大多数业务在发展的初期，都会为了提升研发的效率，放弃一定的规范性和稳定性。尽管经验丰富的架构师或者建模师，会在业务开始的时候，制定好业务的框架大图，但随着时间的推移，一定会产生种种的意外情况，使得我们不得不对原有的架构打补丁，再持续一段时间，这个模型就看不懂了。
总出错：模型重构还有一个原因，就是业务总出问题，不论是数据算不准，还是软件总报错，总归是在架构发展的某个阶段，问题会集中的暴露出来。模型重构的初衷不一定是为了稳定性着想，但稳定性出了问题，就一定会重构模型。
跑的慢：这一条是针对数据业务来讨论的，因为不存在一种模型，能够在业务发展的初期，就能够设计的非常完善。一个好的模型，一定是在业务不断发展的过程中，用经验积累出来的。对数据模型而言，当原有模型不能继续高速支持业务发展时，它就有了重构的必要性。
没价值：这一点会被大多数一线工程师所忽略，但在汇报自己的工作成果时，又往往被拿出来“鞭尸”。是的，数据模型设计的怎么样，很多时候并不仅仅看它够不够稳定，或者是会不会出错，而是看这个模型能够为我们的业务带来怎样的价值，甚至是通过这个模型，能够驱动业务发展的怎么样。
简单讲，“模型重构”就是为过去的“技术债务”，做的补偿而已。但重构的过程，最核心的要素，在于“技术如何为业务增值”，而不仅仅是质量、稳定性和效率。
|0x02 模型重构要考虑什么
关于模型设计的好不好，可以参照之前的文章：。这个模块要讲一些更进阶的理论，即“结构思维”。
对于一名一线工程师来说，辛辛苦苦一整年，最怕的往往不是辛苦，而是自己努力的结果得不到老板的价值认可，或者是产出的结果对业务的意义不大。而既然要做模型重构这件事情了，就要学会反思自己过去在结构化思维上的缺陷，比如汇报自己的工作能不能系统性的论述出来、做的事情是不是成体系、学习的过程是不是有一个重点作为抓手，等等。如果用更接地气的方式来解释结构思维，就是做事情要有“套路”。别小看了套路，因为技术或者能力怎么样，无法直接带来产出成果，而套路是达成目标、产出价值的最快方法。
大多数人不会关心你做了什么，只会关心你产出了什么成果。
“套路”并非完全是过去经验的总结，有点像机器学习，是指能够在过去经验积累的基础上，通过对中心要素进行分解，预测未来的行动方针，即“行为方法论”。例如5W2H就是一个帮助我们分析问题的“方法论”。如果你能对自己正在做的事情，从Why、Who、When、Where、What、How、How much七个方面，毫不犹豫的说出来，相信你已经对业务有了非常深入的了解，也能用充分的实力去证明自己、做好汇报。
事实上，5W2H就是结构思维的一种，结构化是最简单清晰、最有效的经验总结手段。
接下来从理论的层面来叙述一下，首先就是建立中心思想。任何模型重构，都一定会围绕着解决某个业务方向展开的，通常会从两个方面来考虑：
这个业务方向的主要目标是什么？
为什么这个模型要我来设计？
如果业务方向是比较成熟稳定的模式，比如电商，那么它的第一诉求就必然是应用业界成熟的设计方案，并且尽可能的稳定产出时间和保障设计质量。而交给你来负责，大概率是因为你对于这方面的业务最为熟悉，或者是之前从事过相关领域的工作，能够把前人的经验迅速落地实现。
例如用SWOT分析法，我们就可以很快分析出目前的现状。
对很多小公司而言，能够用大公司成熟的模型，让业务飞快跑起来，就是一种技术增值。对于大公司而言，业务需要更多的创新探索，研发与业务的矛盾根源就在于供需平衡上，效率的提升就是技术的增值一种。当然，技术人员也可以直接提出有价值的想法，在互联网广告等领域，业务的增长也往往来自于技术同学自发的贡献，这个时候就要注意培养组织的文化，让不同领域的同学能够有坐在一起解决问题的机会，在思维碰撞中寻找技术增值的点。
当我们有了中心思想之后，就要拆解子类的结构，并且根据一定的顺序，对子类进行合理的分析或重组，以寻求最佳的计划。如果回到刚才的话题，大概就是这样的拆解顺序：这个时候，再跟老板和业务方汇报工作，就按照拆解好的顺序，进行结构化的叙述，原本半小时才能说清楚的事情，5分钟就可以汇报完成。
一直拆解到这里，我们才回到模型重构的本身。在传统的数仓分层结构中，ODS层是数据产出时间的保障，监控往往在这一层要做扎实了；CDM层是业务高速发展的基础，如果没有特殊情况，CDM层应该是高度稳定的，如果频繁对公共层进行修改，一定是模型设计哪里出了问题；ADS层是业务跑起来的保障，数据可以做任意维度的加工，支持下游的灵活使用。
再细分下去，就是高内聚、低耦合思想在SQL开发过程中的应用了。例如GRASP方法，参照之前的文章。
|0xFF 解决复杂性困局
但是结构思维并非是万能的，很多时候如果设计不当，会掉入“复杂性困局”之中。
由于SQL开发不像软件工程，可以灵活运用面向对象的设计思想，维度模型更像是面向过程思想在数据领域的应用，因此遇到一些非常复杂的业务场景中，就会出现大量的CASE WHEN语句。同时，很多写死的配置，也不能通过一个公共的Constant类进行配置，做一张可修改的维度表又显得违反规范，因此业务高速发展滞后，很多ADS层的数据就会陷入复杂性困局，不仅别人看不懂，出了问题自己都不容易定位，还要去翻看源码才能知道当初的设计详情。
所以，对于复杂业务的治理，就不是一个说得清、道的明的方法论了，比较考验工程师的经验积累。
但凡事都是有一些可借鉴的经验，比如面对复杂性困局，可以试着从以下的流程来逐步拆解，用结构思维来尝试治理：
业务理解 -> 领域建模 -> 流程分解 -> 多维分析。
业务理解是拆解复杂性困局的第一要义，比如电商发展这么多年，SKU、ORDER等单词的涵义大家都非常清楚。但一些比较新兴的领域，比如新制造、医药行业，搞清楚一件事情的本质，就不是那么容易了，这时候一定要去熟悉自己所做的业务，现状是什么、行业改进方向是什么、不同解决方案的利弊如何，这对于提前摸清楚未来可能遇到的坑，很有帮助。
领域建模部分，参考之前的文章：。
流程分解参照前文，但这里要强调一点，就是流程分解的过程中，一定要搞清楚哪些是稳定不变的部分，哪些是会经常变化的部分。很多时候为了开发的便捷，往往在公共层的表里夹杂了大量的业务逻辑，虽然下游用的爽了，但一旦碰到业务变更，或者是场景不合适，再回头修改，就会搞的非常难受。因此冗余虽然是有必要的，但一定要冗余不变的因素。
发表评论 取消回复