Bright LGM's Blog

2023-08-27: 积木与故事

家里小孩有一个积木桌，搭配有很多积木小方块。小孩年纪还十分小，这些小方块也都是随意的搭配，没有成套。

这正好给人充分发挥创造力的空间。

那我们就来设计一个理想中的院子吧。将高度相同的小方块连续排列，围成一个方形，就是院子的围墙。围墙上面留一个小口子，口子两边凸出一块，就变成门。院子里面再围一圈高一点的小方块，就是院子里面的房间。房间紧挨着再来一圈相同高度的方块，就构成了另一个房间。房间里面平铺几块低一些的小方块，这是床。类似的还可以做出厨房和卫生间以及院子里的茶座。

在院子搭建完毕之后，拿着成型的院子给家里人讲一个故事：这是妈妈，妈妈早上起床了，到卫生间洗漱，顺便上了一个厕所，然后到厨房找了早餐吃了，然后泡茶并在茶座上和家里人愉快地聊天。。。

《人类简史》中说，人类和黑猩猩之间真正不同的地方就在于那些虚构的故事，它像胶水一样把千千万万的个人、家庭和群体结合在一起。这种胶水，让我们成了万物的主宰。

比如小小的积木就可以让我们虚构一个故事，如果这个虚构的故事能被大家所接受，那它就可以把大家紧密地结合在一起。

2023-08-26: 从拥堵中寻找顺畅

上班路上有一个左转路口，之前一直非常拥堵，一般需要超过10分钟才能过去。最近这个路口却突然变得通畅起来，常常只用一个红绿灯就过去了。

观察发现是由于红绿灯设置更合理了。

这个路口是进出城市环线的路口，工作日的时候进环线和出环线的车都非常多。之前出环路后的直线路段第一个红绿灯的直行绿灯时间设置比较长，左转时间则非常短。为什么左转时间短呢？是为了支持更多的对向直行上环路的车。这就导致一个问题，下环路后直行左转和上环路的车都堵得厉害。

在车流并没有变少的情况下，现在的红绿灯设置为什么可以改善执行左转的拥堵呢？

很简单，只需要增加左转时间即可。因为原来对向直行本来就堵，在一定范围内，无论增加或减少时间都不会有任何改善。既然如此，最优解就是找到对向直行的最短绿灯的时间即可。这时，上环路的拥堵依然存在，下环路的拥堵却显著减少了。

很多事情虽然看起来已经最优，但在全局视角下，往往还有提升的空间。如果你找到了这样的方法，那就是从拥堵中寻找到了顺畅。

2023-08-25: 滴滴打车意外打到了一辆model 3

滴滴打车意外打到了一辆model 3，我靠近车门，准备拉开门上车，发现门把手嵌入到车门里面，不知道如何打开。我敲一敲车窗，司机师傅告诉我说要按一下门把手一边，另一边就会翘起，然后就可以开门了。上车之后，座位怎么坐都不太舒服，仔细感受之后发现坐垫太短且地台太高，腿一大截没有被支撑到。而且后面座位也显得有点紧张，活动空间有限。车辆行驶过程中，周边环境及车辆会跟随显示，非常清晰和准确，司机可以清楚的看到周围的情况。

更多能打到的车是比亚迪汉，靠近车门，门把手自动弹出来，我拉开门上车，一气呵成。进入车内，座位坐起来相当舒服，不管是地台高度还是坐垫长度都非常适当，活动空间也非常宽敞。座位皮质显得很高档，不管是触感还是观感都有一种高级和精致的感觉。当然这辆车虽然有大屏幕，但看起来只像是摆设，司机师傅只是用来显示空调信息。

2023-08-24: spark同时读写某一张表

spark无疑是一个优秀的计算引擎，但却在支持同时读写某一张表时略显不足。

一个简单的示例为：insert overwrite a select * from a

事实上，如果我们碰到了这样的场景，spark直接报错：cannot overwrite a path that is also being read from.

如何解决？一个很简单的方案是，先写入一个临时目录，然后再修改一下目录名。

用sql表达，即：

1. insert overwrite a_tmp select * from a

2. drop table a

3. alter table a_tmp rename to a

2023-08-23: 分解复杂数据问题

数据开发常常碰到数千行的sql代码，如何看待和优化这些代码呢？

可以将问题按照业务和技术复杂性进行分解。

1. 识别复杂代码中涉及的大表连接场景，这通常很慢而且难以优化。

2. 针对大表连接场景，识别是否可以将更多数据筛选条件下推到连接之前；识别是否可以在连接条件中利用分区键；识别是否可以优化为小表连接大表等。这些场景下有很多成熟的优化方案。

3. 将大表连接代码隔离出来，单独处理。即拆分为简单代码大数据量代码段及复杂代码小数据量代码段两部分。第一部分主要进行技术优化，第二部分主要进行业务逻辑优化。此即为关注点分离的模式。

2023-08-22: 困局

地上一滩水，小蚂蚁在水边爬，恶作剧的人用手划过这滩水，圈出一个水圈，将小蚂蚁困在圈子里面。

小蚂蚁在水圈里面来回爬，想要找到一个出路，它一直尝试一直尝试，把能尝试的路径都试过了，始终都没有找到出路。

随着这滩水越积越多，水圈慢慢变小，慢慢变小。。。

2023-08-21: 推荐反被推荐误

下火车了，赶紧用滴滴订一个车，滴滴推荐了几个上车点，随意选一个，然后开始往上车点赶。到了上车点，是一个停车场，人真多，嘈杂的打电话声音夹杂着汽车的哄哄声，在夏天的潮湿而又闷热的空气中乱作一团。汽车排着长队一个车位一个车位往前挪，刺耳的喇叭声不绝于耳。等了20分钟终于上车。

这是很多人在火车站打滴滴车的日常。

这次到站了，由于我实在无法忍受在热浪中等待20分钟之久，就选择了一个自己定位的上车点。没想到一切竟出奇的顺利，快速的叫到了车，师傅快速到了上车点，我也快速的上了车。由于上车点在马路旁，人流量不大，车也没有排长队。体验一下子提升n个档次。

为什么滴滴推荐的上车点体验如此差，而自己选择的却还不错？

本来是一个不错的地点，但正是由于将少量资源推荐给了大多数人，这个不错的地点就变成了很差的地点。推荐反被推荐误！

2023-08-13: 会计准则与领域词典

财务是一个很有意思的部门，它的职责是记录和管理企业内部的各类经济事务。由于企业内部几乎所有活动都要和钱相关，因此也都需要和财务相关。故而，企业几乎所有业务活动所涉及的（高层次）知识都将流入财务系统，财务系统事实上成了企业内部的知识中心。

这对于软件开发有什么启示？

领域驱动设计建议我们逐步构建一个领域词典，以便于让大家对于系统的理解达成一致。如何构建这个词典？

企业财务管理需要符合国家会计准则，而国家会计准则则对于社会上的各类企业业务做了较为明确的高层次划分及规范制定。比如，会计科目中关于原材料采购业务定义了这几类相关科目：银行存款/应付账款/应交税费用于钱款流转事务，在途物资/原材料用于物品运输与仓储事务，生产成本/制造费用/管理费用则用于和原材料相关的各类生产消耗事务。从这里所涉及到的一些术语可以了解到会计准则中的知识几乎覆盖了企业所有核心业务过程。

基于以上分析，领域词典是不是可以基于标准的会计准则中的知识来定义？

会计准则作为一个国家颁布的企业经济行为标准，经过了社会广泛调研，可以覆盖绝大多数的关键场景，并且相关的解释和研究非常丰富，实在是不可多得的材料。

虽如此，会计准则之于领域词典也有局限。因为会计准则中的知识是仅停留在高层次，其应用范围也将限于高层次（比如架构、系统对接接口等），细节或较低层次的内容则还是应该根据具体系统相关的业务确定。

2023-08-12: on中的条件和where中的条件

sql语言的表达能力非常强，但在某些场景下看起来功能相同的代码却有着非常细微的差别，稍不留神可能就被坑了几个小时的调试时间。

比如，某一个条件写在表的连接条件中和写在连接后的where条件中有什么区别？

示例如下：

• 写在on：select * from a left join b on a.id=b.id and a.cond=1

• 写在where：select * from a left join b on a.id=b.id where a.cond=1

思考一下，第一个的结果集里面会出现a.cond!=1的数据吗？

2023-08-11: 用编程语言的性能提升你的效率

最近项目中需要搜集一个公开产品的文档，以便快速为团队补充相关知识。通过实现一个简单的爬虫，解析网页，获取信息就可以支持。

第一个版本，我采用了最近用得最多的python实现。代码很快写完，但是一运行就发现了一个较大的问题，网页解析太慢了！一个20MB的网页需要解析十分钟，而这样的网页总共有好几百个。没想到，本来以为可以快速完成的任务，结果输在了程序性能上！在Python这条路上折腾好长时间，无果。

由于nodejs天生就对网页解析和元素查找很擅长，所以，考虑改为nodejs实现。于是，花了一小时左右，程序搞定。上真实网页一测，性能简直不要太好，20MB的网页解析只用了不到5秒。于是这个任务在采用nodejs重新实现之后，顺利地在两小时内完成了。

我们在开发程序的时候，一般都先入为主采用自己最擅长的开发语言，希望通过熟练度来提升效率。但是每一种开发语言都有其擅长和不擅长的领域。了解这些，就可能可以通过编程语言的性能带来颠覆式的效率提升。

2023-08-09: 基于代码复用的数据工程

业界普遍采用以sql为主的数据开发语言进行数据开发，依靠数仓分层来避免重复计算，这一复用方式可以称之为数据复用。但数据复用的灵活性较差，可能会形成一个非常复杂的数据任务流水线，并且，当我们想独立运行某一个etl的时候，我们不得不执行所有依赖的任务。

基于代码复用的数据工程是指采用复用代码的方式进行数据工程中的复用。它采用以计算资源换取维护成本的方式帮我们节省开支。在大量数据量没那么大的场景下更适用。

目前很多框架可以支持这一使用方式，比如dbt，easysql都有相应的支持。

2023-08-08: 终点却是过程

人们常常奔着一个目标往前冲，甚至能不分昼夜，不顾身体。

但是等目标按照预期实现了之后，却觉得心里一下子空虚起来，不知道该干什么了。

有多少软件功能在实现之后就成了它的坟墓？无人问津的程度甚至不如当初开发阶段的测试使用频率。

也许有时候终点恰恰是过程，是奋力向上的有着充实感受的过程。而目的的意义在于为我们提供一个参与这个过程的机会。

2023-08-06: 弄清需求背后的原因

家里孩子到了1岁半的年纪，开始喜欢抓人和咬人。经常没来由的给人脸上身上来一爪或者来一口，弄得家里人满身伤痕。家里人为此苦恼不已。

一开始我也不理解他的行为，采取打回去或者抓回去的办法，并且表现出很凶的样子试图进行教育。然而，教育的时候他总是表现出听不懂的样子，重复数次也没有效果。

在网上搜索一番之后，开始弄清楚了背后的原因：

• 身体发育到特定阶段，用嘴和手来感知这个世界

• 以此寻求关注

• 以此发泄情绪

• 以此表达喜欢

在理解这些之后，终于释然，现在会更注意用手护住自己，并且根据尝试平和地把他的想表达的东西说出来，引导他进行正常表达。

了解一开始不理解的事物的原因可以帮助我们更好的应对。

在软件开发过程中也是一样。很多开发人员总是只遵循需求描述进行开发，而极少思考背后的原因，即业务价值。所以，他们常常觉得很多需求实现起来很别扭，最终形成了我们在代码里面看到的很奇怪的注释或者条件判断。这样的软件常常满是bug，维护起来非常痛苦。这就像直接针对小孩抓人这件事用表现得很凶的样子教育孩子一样，自己很痛苦，效果也很差。长期下来，软件就渐渐腐坏掉。

如果我们可以尝试去弄清楚需求背后的原因（业务价值），就可以了解到可能有更符合设计的实现，也可以了解到将来可能的演进方向，那就更可能达到简单的架构和优雅的实现。

2023-08-05: 人类的本质差异

地球上有很多动物，为什么人类可以站在食物链最顶端？

是因为人类会语言？很多动物其实也会，猫狗的不同叫声代表不同意思，鸟类可以模仿人讲话，其音域甚至更广。

是因为人可以直立行走，操作工具？很多猴子、猩猩，甚至乌鸦也可以。

《人类简史》中提到人与其他动物的本质差异可能在于人类可以创造一些原本不存在的概念，并通过交流让大家广泛相信，从而聚集起大规模的群体，比如国家与军队。这个群体由于数量上可以大大超过其他动物形成的群体，而具有极强的优势。正是这个优势让肌肉并不发达，体格并不高大的人类站在了食物链最顶端。

2023-08-04: sql代码的重构

随着大数据越来越广泛的应用，基于sql的etl代码也越来越长。当代码达到数百行规模时，就急需要引入整洁代码（clean code）这类高质量编码实践，否则很容易变得不可维护。

重构是实现高质量代码的重要手段，如何针对etl进行代码重构呢？最重要的是需要有一款强大的sql代码重构工具。它应该具备这样一些功能：

• 能将中间子查询抽取为cte格式的临时视图

• 能修改子查询或cte视图的别名

• 能修改子查询或cte视图中的字段名

• 能自动进行代码格式化

目前似乎还没有特别匹配这些需求的工具，期待它的出现…

2023-08-03: 理性限制的建立与破除

康德认为这世界有很多二律背反问题，比如，正题：世界上的一切都是由单纯的部分复合而成；反题：世界上的一切都是复合的，没有单纯的东西。这两个论断都可以用理性来证明，却又是相互矛盾的结论。所以，理性是有限制的，不应该用于超验的自在之物上。

到了谢林和黑格尔，理性的限制被认为是理性的怯弱。矛盾不是不可调和的，而是所有事物发展过程的中必然出现的阶段。但是，随着认识的深入，矛盾和对立终将达到同一。这世界本质是发展和运动的，总是将一轮一轮的经历从同一到差别到对立，再到矛盾最后回到同一的过程，这也是黑格尔的肯定、否定和否定之否定。否定之否定是最初的肯定的升华。

到这里，终于能理解为什么马克思主义哲学的第一句话是：世界是物质的，物质是运动的。

2023-08-02: 早上六点钟

早上六点钟的世界是什么样子？机械化的工作时间可能已经将我们和这个时段划清了界限，但最近的生活节奏让我有机会出去看一看。

马路上的汽车要少一些，但还是络绎不绝，在红绿灯前面排着队。

公路清理工作已经开始，洒水车、扫地车、环卫工人已经就位，赶在天还不热的时候为大家创造一个更干净的环境。

住所旁边有一个运动公园，公园里已经有很多健身的人，有的开着节奏舒缓的音乐打着太极，有人沿着跑道散步，更多的是身着运动装跑步的。

我是去公园跑步的，跟着同跑的人流向前。大家节奏不一，脚步声噼里啪啦的，偶尔超过几个速度慢一点的，偶尔被几个速度快的超过。

唯物主义哲学认为世界是物质的，物质决定精神。但不管物质如何变化，精神却是自由的，如果没有早起的精神意识，那也看不到早上六点钟的世界。

2023-08-01: 没有测试代码的自动化测试

数据测试一直是一个难题，需要建表，构造数据，运行etl，对比结果等繁琐的步骤。手工构造测试场景不仅耗时巨大，而且难以维护。

有没有一种轻量级的自动化测试方式？

可以这样来做：

• 根据etl代码生成数据血缘图

• 从图里面提取表和字段

• 自动根据输入表和字段创建空表

• 针对空表运行etl

• 以输出空表为标准，对比结果

这种测试无法验证逻辑的正确性，但可以验证语法、udf、相互引用关系等基础正确性。

胜在无需编写任何一行测试代码即可运行程序，非常轻量，适合往大数据平台提交任务之前先在本地验证。

这种方法通过极低成本在早期提供反馈来提高开发效率，值得尝试。

2023-07-31: 突破时空的染色

康德在描述我们认识事物的过程时，认为我们认识任何自然事物都会带着主观的色彩。最基础的主观色彩就是时间和空间。时间、空间是自我与生俱来的先天直观形式，只要我们对事物进行感知，我们就必须把它放在空间和时间中。

当我们带着主观的色彩去认识事物的时候，事物就不是完全自由实在的了。至于完全自在的事物，那是不可知的。

结合弗洛伊德的意识和潜意识理论，这种先天直观形式其实是一种潜意识，它确实会给我们认识事物带来障碍，但通过训练我们也是可以认识并突破这种障碍的。所以，完全自在的事物依然是有可能可知的。

那么，我们等等看黑格尔是怎么说的。

2023-07-30: 技术卡上的方案

数据开发项目很多故事卡偏技术，比如数据接人，它并不直接产出用户价值（数据计算结果），而是用于支持其他直接产生价值的卡。

这类故事卡，一般称为技术卡。要如何描述其内容？

一般敏捷开发故事卡中会用“作为…我想要…以便…”这样的描述来阐明故事卡的背景、场景、目的及价值。对于实现方式的描述通常是模糊的，以便可以在团队中发生更多讨论，从而促进更好的技术建模。

但在技术卡中，是否要进行更清晰的实现方式（方案）描述？

技术上有很多要求来自团队技术规范，相比故事卡这类纵向需求，技术规范可以理解为横向需求，即每个故事卡都需要遵循的需求。比如整体架构、数据分层、关键命名等等。

已有的规范应该是每一个开发人员都需要熟悉的，没有的规范则应该通过每张故事卡去建立或完善。

因此，技术卡的描述应该涉及一部分实现方式，主要关于规范的部分，也可分为两类：

• 来自通用技术规范的需求，可链接到技术规范文档对应章节

• 通用技术规范未提及部分，视团队成员能力情况确定是否由经验更丰富的成员事先调研梳理并描述

第二部分中，前期调研程度应该适当，并快速完成，否则调研完就开发完，那开发就没有意义了。

2023-07-29: 看起来复杂的问题往往原因很简单

这两天团队碰到一个看起来非常棘手的问题。问题表现是：在一个分布式环境中，某些数据操作只有一部分成功，另一部分则总是失败。

在花费了大量精力观察和调试问题之后，团队总结出规律：某两个节点的数据操作总是失败，其他节点正常；针对这两个节点，如果手动发起操作可以成功，自动发起则总是超时。

虽然发现了规律，但还是令人很疑惑。

最后团队集思广益，终于找到原因，简单到不能再简单：这两个节点没有配置主机名解析，一直连接不上。

启发：

• 需要在技术上理解分布式组件工作原理

• 分布式组件设计上应该在出错时输出更有效的日志

• 锲而不舍的精神，相信复杂问题背后的原因往往很简单

2023-07-28: 重新思考标记问题

在继续读《西方哲学史讲演录》的同时，我意识到每个哲学家的观点具有很强的推理性质。如果只看到一个结论，而没有推理过程，那结论就不可理解。

比如，英国经验论的基本原则是：凡在理智之中的无不先在感觉之中。这有什么问题？应该如何看待？逻辑上讲，至少存在一个反例，对于第一个睁开眼看世界的人来说，世界的存在可以在理智之中，但却没有先在感觉之中。因为他无法凭借经验（还没有）证明这个世界在他睁眼以前就已经客观存在了。

回到笔记上，如果只标记结论，而没有标记推理，那标记就是无用的，而要标记推理，那就将标记整本书，也是无用的。

这大概就是为什么我之前有不想做标记的想法。

2023-07-27: 规则

这世界有很多奇怪的规则，它存在着，即便奇怪也是合理。

规则限定了游戏参与者的范围，你要是没法适应，那就没有资格入局。

自命清高者，多数饿死于沙滩上。在这个内卷的时代，拼的不只是能力。或者，在无法改变规则时，适应它也是一种能力。

2023-07-26: 少即是多

最近在一次团队活动中，有人分享关于写作的问题，提到一个如何让文字更简洁的办法，很有启发。

如何做？那就是在写完之后，问自己一个问题，如果删一个字给你100块，你会删哪个？当你通过这个办法把内容删到无法再删的时候，就足够精简了。

从读者的视角看，内容简洁已经成为当今这个知识爆炸的快节奏时代的必需品。但是从写作者的视角来看，很多时候都是越写越多。很多作者都恨不能把自己知道的都写进去，生怕遗漏某个细节。

然而内容的用户是读者，从用户体验的角度讲，作者在写作时应该要保持克制，时刻提醒自己，少即是多。

2023-07-25: 工作的节奏

在专业软件服务公司工作很容易形成一种节奏感。

我们都是以项目制为单位进行团队组织的。项目一般会定期更替，这是较长期的节奏。项目内部我们以敏捷迭代的方式展开，这是短期的节奏。

节奏就像持续不断的音乐节拍，有起有伏，井井有条，让人乐在其中。

有的时候，节奏却也像是时钟的滴答，背后的齿轮机械而固定地转动，一成不变，永无止境，让人感觉枯燥无聊。

人生也许就是需要有略显枯燥的大的节奏，以便可以在一个框架中前进，而不至于偏离方向。同时，大的节奏并不意味着无聊，因为在大的节奏期间我们可以尽情发挥。这就像音乐，高低不同的音符伴随着规律的节奏形成了打动人心的篇章。

2023-07-24: 有时读书不想做标记

最近在读赵林老师的《西方哲学史讲演录》，这是一本哲学通识类的书籍。内容清晰而精彩，作为一个没什么哲学背景的普通人，也能轻松读下来并抓住哲学思想发展过程中的重点。

全书内容非常精彩，随处都洋溢着老师对于当时那个时代哲学思想的深刻理解和剖析。读书过程中我在很多精彩处都通过标记做了一下笔记，希望能通过这些标记记住这些精彩的部分。但过一段时间之后再回过来看这些标记，发现之前认为精彩的部分竟然不那么精彩了，甚至看不懂了。只看一个片段时，已是失去了当时看到对应章节的理解和心情。

然而，当我重新开始全文读下标记部分对应的那一章节之后，我发现之前的感觉又都回来了。哲学思想发展的脉络，其历史背景，优势和局限性又清晰的呈现在了眼前。

也许有时候没有必要做标记，因为到处都是精彩的内容。如果认为通过标记可以把书读薄，那很可能将错过那些精彩的内容。

2023-07-23: 天真与成长

以前我们家小孩每次出电梯到时候都要给一起乘电梯的人表达再见，扬起手挥一挥，然后嘴巴里面不停的说着拜拜拜拜。碰到热心的邻居，也会笑着回复他跟他拜拜。他因此收获了无数人的喜欢。我们都说他是小社牛。

最近出差回来慢慢发现他已经越来越少表现出这样的行为了。

为什么会这样？可能是因为成长。这几个月是他智力高速发展的几个月，慢慢地他开始与我们能有更多的互动了。他学会了走路，能认识身边的人，还能说几句简单的话，还会自己吃葡萄并把葡萄皮吐出来丢到垃圾桶。他似乎已经开始以一个自主的主体参与世界的活动了。

随着快速的成长，原来天真的小社牛真的要慢慢变成理性的社会人？当我们成长之后，还有多少儿时的天真可以保留下来？

2023-07-22: 看代码没有信心的时候，就去搞懂业务

遗留代码的维护是件令人头疼的事。我们常常要面对多年以前的杂乱无章的代码，它们可能非常长，各类名称可能毫无意义，可能几乎没有文档。

如果直接从代码入手，妄图从代码中发现真理，那可能要落入一个爬不出去的陷阱。满是细节的代码就像是一片迷雾森林，你在其中绕来绕去也找不到一条清晰的出路。

换个思路出发会更容易，那就是从业务出发。事先可以完全抛离代码，只是从业务角度去理解当时的需求和目的。业务角度的需求和目的就像是一个个灯塔，可以为我们指引方向，而有了方向，在就不至于迷失在满是细节的迷雾森林。

2023-07-21: 依赖干系人管理

项目里面的干系人可以按照利益相关性和权利大小分为四个象限，对于利益相关度高权利低的人，通常采取的策略是随时告知。

但如果这些人是你的依赖方，就需要谨慎，因为有可能他们不依赖你，你依赖他们，你的成败需要他们支持，而他们的成败不需要你的支持。

此时，由于他们可能不关心你的项目，所以告知的意义未必大。你找他们协助，他们有可能善意的提供帮助，但绝没有直接的义务。

如何处理？一是以各种方式表达感谢搞好关系，二就是上升到利益相关度高权利高的干系人协助处理。

2023-07-20: 食不知味的感觉

酒店的早餐算是十分丰盛了，超过二十种食材随意挑选。然而，最近越来越发现面对这么多丰盛的食物却不知道选哪种。常常随意拿几个，狼吞虎咽下肚，事后竟然连这些美味的味道都回忆不起来了。

是什么原因？大概是因为早餐太急，想一想，好像很久很久没有一个早上能什么事都不想，什么安排也不做，就仅仅是吃早餐。完全放松下来，认认真真做这件事，细嚼慢咽品味每一粒米饭和每一片蔬菜的味道。

2023-07-18: 从业务入手讲方案

当需要为一个复杂系统提供方案时，需要从业务角度理解问题，不要陷入具体细节。抽象的上层业务模型通常是简单而一致的，这就是主线，基于这个主线就可以给出技术上合理的方案。

财务系统可能涉及几千个科目，每个科目的取数逻辑就是细节，非常多。但是财务统计本身是很简单的，就是简单的求和、取余额等。设计系统时，需要抓住这个主线，避免陷入细节。

2023-07-17: 应对数据开发复杂性有没有更好的方案？

DataMesh数据网格的思路是让业务系统开发团队来提供数据产品供下游消费。这些数据产品往往是聚合了很多数据表得到的一个可以隐藏底层复杂性的数据宽表。

由于这些中间数据产品来自于该系统的开发团队，而他们天然具备对该系统业务和数据的深刻认知，所以维护起来天然是得心应手的。

对于数据开发团队，他们基于这些中间数据产品去构建集成的数据分析报表。在报表开发过程中可以将知识限定于构建集成报表的范围，不至于扩大到各个复杂的底层系统中。

经过这样的职责划分，不至于让数据开发团队知识过载，各团队可以各司其职将最终的数据产品构建出来。

2023-07-15: 新时代的家族关系如何维系？

城市化让更多人搬进了封闭的钢筋混凝土小区，以前亲密的家族成员也分散到了全国各地。

在以前家族成员聚集到一起的时候，总能经常有些活动，比如谁谁过生日，大家就一起聚个餐，谁谁要办个什么事，大家就一起棒棒忙。亲密的亲戚关系于是得以维系。

现在离得远了，很多亲戚经常几年也没联系。如何继续这样的关系？

我们有一个家族微信群，每当有人过生日，大家就在里面发红包，十块八块大家有个心意就是了，过生日的人也会回一个随机红包，让大家一起热闹热闹。借此机会，大家也聊聊近况。由于大家过生日都这样做，一个十多个人的群里面，竟然每个月都至少能有一次这样的活动。

新时代下家族关系的维持可能需要我们去寻找这样的一些仪式。

2023-07-14: 基于ChatGPT进行ETL代码重构

复杂的数据分析场景背后常常使用复杂的ETL进行支撑。然而，由于工程化的缺失，基于SQL的ETL代码很容易变得难以理解。在经历团队人员流动之后，这一问题变得更为显著。如何优化已有的复杂ETL？ChatGPT也许可以帮到我们。以下场景中ChatGPT可以发挥作用。

代码格式化。ChatGPT可以很好的完成代码格式化，相比于学习和配置特定的代码格式化工具，ChatGPT可以用自然语言给出格式化的规范，并在无规范的地方使用行业通用的做法。

代码注释。ChatGPT可以帮我们理解代码并添加注释。当碰到难以理解的逻辑时，ChatGPT可以结合元数据，告诉我们代码的行为及背后的原因。

基于CTE的代码优化。ChatGPT还可以将子查询转化为CTE格式，我们可以基于此功能把多级嵌套的子查询分离出来，并给它一个名字辅助理解。

基于谓词下推的优化。将筛选条件尽可能放在查数据的源头可以有效提升性能，在提示ChatGPT去进行代码性能优化时，它可以帮助实现这一优化。

2023-07-13: 架构设计

最近读了一本书《重塑心灵》，讲的是身心语法程序学（NLP）的知识。NLP里有十二条前提假设，其中之一是：在任何一个系统里，最灵活的部分便是最能影响大局的部分。

最初读到这里的时候有一些诧异。联想到软件架构设计，在我们通常的认知里，架构就是那个最能影响大局的部分，那么架构到底是最稳定还是最灵活的部分？

如果架构是稳定的，它限定了一个框架，那么灵活性就在于填入框架中的细节，那么细节便会成为最能影响大局的部分。所以，细节比架构更重要。

如果架构是最灵活的，那么它就可以被经常调整，那么架构设计就应该在每一天的日常开发过程中进行。

总结起来，我们要么获得了一个不重要的架构，要么把架构变成日常开发中的每一张故事卡。

2023-07-12: 当面沟通的力量

在我还青春年少的时候，大家经常调侃失追女孩的情景说：屌丝有三废，在吗，忙不，早点睡；女神有三宝，干嘛，呵呵，去洗澡。

仔细分析一下为什么屌丝追女孩很失败，我发现这其中有一个重要的原因，屌丝是用短消息和女神交流的。屌丝没法从女神的“干嘛”中捕获到女神今天的心情，也没法知道女神当前的状态。

试想，即便还是用这样的开场白，但是屌丝直接一个电话或者视频打过去，会是什么场景？只要女神真的不是直接拒绝你，你就可以从她的话语、表情或者手势中感知到非常多的信息。她烦躁就听听她的吐槽，她无聊时就跟她讲讲网上查到的笑话，她在娱乐时就远程加入，交流于是如丝般顺滑的进行了下去。

为什么当面交流比起短消息更有效？佛洛依德的潜意识理论认为意识和潜意识就像冰山，意识是水上面的很小一部分，潜意识是水下面的大部分。当面交流时，潜意识帮助我们捕捉了大部分的信息，因而可以帮助我们更有效的交流。

回想起昨晚因为客户的一句拒绝性的短消息回复而失眠，今天见面交流时又能谈的很投机。谁说不是呢？

2023-07-09:

今天陪小孩玩耍时，偶然发现了之前抓周时购买的三字经书。想想我们小时候竟然没有要求阅读和背诵这样的国学启蒙经典，于是翻开读起来。时间比较充裕，竟然读完了整个三字经。

看完之后，心里升起一种深深的相见恨晚的感觉。整部经书不仅仅是我们所熟知的三字一句朗朗上口，更是在内容上包罗万象，从前到后包括了学习方法、行为道德准则、生活中的名物常识、应该读的书目及次序、历史朝代更替，以及最后对读者学习的勉励。三字经就像是古人为后来求学者铺设的一条通往知识殿堂的道路，简明而具体，应该说是一本不可多得的启蒙经典。

2023-07-08:

财务报表中的各项指标计算涉及很复杂的计算过程，很多科目的计算规则并不是简单的统计，比如“固定资产”“投资性房地产”“无形资产”等项目的统计需要应用该项目期末余额扣除相应的减值准备科目及累计折旧（摊销）等的净额。另一个挑战是财务统计科目非常多（《企业会计准则》设置了85个常用一级科目，以及部分金融保险等领域专用会计科目；而《小企业会计准则》设置了58个一级科目），并且这些科目按照父子关系形成了多棵树形的结构。

如果每一个科目都去实现一套特定的统计方法，那一定是非常浩大的工程量。

如何设计一个合理的数据计算系统来应对这一问题呢？以下是一些初步的想法，看起来可以较好的解决这个问题：

将各科目（最细粒度）按照月度周期分别统计期初/期末值，存入一个中间表A

设计一个表格，以便业务人员可以针对每一个父级填入统计计算公式（如：固定资产统计 ＝ 固定资产.期末余额 － 固定资产减值准备.净额 － 固定资产累计折旧.净额）

设计一个程序，读取表格中的计算公式，生成一个数据计算的ETL

这样一来，业务人员只需要按需将所有计算公式填入表格，开发人员使用一个ETL生成程序就能应对所有的计算了。这一设计可以认为为财务指标计算定义了一套DSL（计算公式），看起来可以让整个系统变得一致而简单。

2023-07-06:

前不久我给团队里面一位刚毕业不久的一个同学分配了一个颇具探索性的任务。这个任务对于已经工作十年以上的我来说不算太复杂，但是对于他还是挺有挑战性。于是我尝试给他分享了这个任务要通过几个步骤如何如何完成，并期望他可以顺利地按照我提到的步骤去完成。然而等了一周之后，他没有给我任何反馈。我很奇怪，于是去问他进度。在沟通之后，我不禁大跌眼镜，没想到过了这么长时间他竟还处于完全不知道怎么做的状态！

今天恰好有另一位同学想找我做一些指导，无意中想起了这件事。

反思之前的事，我意识到很可能是因为我没有仔细分析被分配任务的同学能力在哪里，是不是胜任，而是更多站在自己的角度安排了难度太大的任务，而且过程中也没有及时的跟踪和指导。设身处地想一想，当我还在他们那个年纪的时候，刚刚毕业，对于职场几乎还是一片空白，不仅专业知识有很多缺漏，而且沟通也没有技巧和信心，如何能完成这样高难度的任务？

2023-07-06:

前两天刚去看了电影《消失的她》，由于电影结束已经是很晚了，于是刚播放片尾曲的时候我们就快速起身离开了电影院。后来发现竟然还有彩蛋，彩蛋里面是男主做了一个梦，醒来之后幡然醒悟，然后一家人重新过上了幸福生活。两者结局天壤之别，剧情中的男主也走向了两个极端。真实世界的人其实充满着不确定性！回想每天我们做过的决定，有多少次是因为我们头脑一热，灵机一动？这竟然与我最近正在研究的ChatGPT很像。ChatGPT能力很强，大部分时候都能给到正确的答案，但是由于随机性的存在，我们却很难确定它可以在每一个场景都能百分之百给出正确的答案。也许正是那百分之零点零一的概率让人走向了不同的极端。

2023-07-05:

老王特别擅长长跑，每次长跑，他都感觉浑身是劲，越跑越感觉得心应手，信心十足。但是最近一段时间队里面的比赛都是短跑，而队里面确实缺少了跑短跑的，没办法，老王硬着头皮顶了上去。由于这不是老王擅长和喜欢的，虽然顶了上去，老王也老是提不起兴趣，因此短跑也没什么成绩。长期下来，老王感觉越来越没信心，眼看着逐渐逝去的青春，慢慢地开始怀疑自己适不适合再继续做一个运动员。

2023-07-03:

OpenAI的创始人Sam Altman曾在描述大家如何看待ChatGPT时提到，很多人把ChatGPT当作一个数据库使用。刚听到这种描述的时候，我不禁一怔，在大家都在惊叹于ChatGPT强大的语言理解和推理能力的时候，它却只是一种传统得不能再传统的数据库？然而仔细一想，这似乎也没问题，当前大家使用ChatGPT的方式主要是提问，而ChatGPT只是负责给出答案，这不就跟数据库执行查询返回结果是一样的么？这样来看，ChatGPT最多可以称为一个存储知识的数据库，而查询语言是自然语言而已！那么我们期望的能力到底是什么？可能是真正能帮助我们处理日常事务，可以洗碗擦地上楼取东西的智能机器！而这离我们似乎还比较远。

2023-07-02:

去过成都环球中心海洋乐园的人一定会惊叹于这片人造海滩的宏伟，400多米的海岸线竟然硬生生的在一个商场里面给造了出来。海洋乐园前几年是封闭运营，必须买票才能进场到海滩边，我去过几次，发现都是门可罗雀的景象，大概是它的高冷向世人阻挡了它的宏伟。今天带上小孩一起来环球中心闲逛，发现海洋乐园竟然开放了，不用买票就可以走到海滩边。作为一个在环球中心闲逛的游客，看到一层一层卷起的巨浪，听着浪花冲向海滩的哗哗声及沙滩上人们的欢呼声，竟也想买张票下水体验一番了。封闭还是开放？到底要如何选择？