0%

2023-09-24: 感染力

她双手分别拿起一块鹅卵石,快速碰在一起,“铿”,声音不大,但在偌大的掉一根针都能听到的大厅里,这清脆的声音可以清晰地传入耳中。

紧跟着这一声“铿”,后排的三位伴奏者也同时敲下手里面的鹅卵石,三声“铿”分秒不差地重叠在一起,合并为更沉闷的一声“铿”传入耳中。

随着节奏往前推进,她一边敲击鹅卵石,一边轻声走向后面摆好的鼓阵。“铿铿”声瞬间切换为“咚咚咚咚”密集的鼓点,时而大时而小,时而密集时而稀疏,有时候是敲在鼓边的更清脆的“咚”,有时候是敲在鼓心的大声的沉闷的“咚”。这声音快起来的时候,她挥舞的鼓锤变成了看不清的残影;这声音慢起来的时候,她舞动的手臂像是在跳优雅而浪漫的古典舞。

谁说鼓只能拿来敲?只见她双手在鼓面上面划着圆圈摩挲,顿时响起一阵阵沙沙声,伴奏的三人也随之摩挲起来,一阵阵“沙沙沙沙”声此起彼伏。一会儿呼呼的风声响起,一会儿滔滔的水声响起,一会儿又“啪啪”的海水拍击礁石声响起,这声音哪里是来自她们手里的乐器?这声音分明是来自大自然!

一曲终了,她移步另一处鼓阵,这鼓锤再次与她手臂融为一体,一阵密集的鼓声之间,竟然出现了一声清脆的木棒碰到金属的声音。哦,这是旁边的金属架。开始是一声,后面越来越多,鼓声则越来越少。再后来,竟然全部是鼓锤敲击金属架的声音。随着她缓慢移步,旁边的鼓架、放乐器的桌面、桌子的桌角、地面全都变成了她的乐器。“铿铿”、“锵锵”、“砰砰”、“哐哐”、“啪啪”这不同质地的敲击声和谐地有节奏地发出,组成了一曲错落有致的壮丽乐章。

2023-09-23: 语言的能指和所指

著名的语言学家索绪尔在分析了语言的结构之后,发现我们所说的每一个语词都存在能指和所指两个概念。

能指是指一个语词的符号,而所指是指该符号所表达的概念和意义。能指是人们想要表达其所指时赋予的一个符号。

所指优先于能指而出现。比如,苹果作为一种球形的红色水果,在没有人类语言之前也是一直都存在的,人们为了表达这种水果,于是设计了一个符号“苹果”。

区分了能指和所指之后,就能理解,当我们想要表达某一个意思(所指)时,我们通过说出来一系列符号(能指)来实现。但是,听众却只能通过这些能指来理解我们的所指。于是,误解便经常产生。

如何消除误解?结合语音和表情,我们就能更多的获得对方的所指,这即是我们所推崇的当面沟通。

在软件开发领域,我们用变量名、函数名、类名、包名等编程语言元素来表达我们的所指。由于这些名字同样是自然语言,只是一种能指符号,其背后的所指常常因人而异。这就不难理解为什么我们读他人的代码会比较困难。

如何缓解?这可能需要我们每一个人在编写代码时都需要尽可能用清晰易懂的、没有歧义的语词。

2023-09-22: 理解就是视域融合

人是历史的人,每个人都身处不同的历史阶段下。人同时也是社会的人,每个人都在他的社会圈子中的活动。所以,人的认知范围受限于这个历史阶段和社会圈子,这个有限的范围就是人的视域。

一个人与另一个人沟通,需要彼此相互理解,理解的过程就是视域融合的过程。如果两者的视域完全没有交集,则无法相互理解。如果两者视域接近,则很容易相互理解。

视域的融合就如同可乐和雪碧的融合。当你作为可乐与另一个作为雪碧的人交流时,他的雪碧就会融入你的可乐,从而改变你的颜色和味道。同时,你的可乐也会融入他的雪碧,他的颜色与味道也因你而改变。

理解是两个人的双向奔赴,相互找到可融合的点,求同存异。理解也是无法相融的视域发生碰撞的点,碰撞激起的火花带来创新。

2023-09-21: 交往理性

在物质生活高度发达的今天,普世的教育是对科技的崇尚,认为脱胎于科技的工具就是人类之光。但是过于崇尚科技和工具,就容易忽略一个问题:科技的最终目的是服务于人并提升人类整体的幸福感。

在资本主义社会里,企业执着于创造利润,人不仅没有得到应有的服务,反而不得不面对越来越长的工作时间,越来越大的工作强度以及越来越低下的生活品质。如此一来,我们发展科技的作用是什么?

德国当代哲学家哈贝马斯提出的交往理性正是针对当今社会的工具理性中的问题而提出。工具理性的社会里,人由于使用工具产生了莫名的优越感,人与人之间的情感变得冰冷。交往理性呼吁人们关注和回归人与人之间的交往过程,提醒人们保持谦逊,用相互可以理解的方式沟通,求同存异,从而营造一个和谐共处的环境。

敏捷宣言中有一句话是个体和互动高于流程和工具。可以发现,敏捷宣言与交往理性所推崇的价值观是一致的。在软件开发活动中,我们只有把人的位置放在工具之上才能帮助我们构建更高质量、更人性化的软件工具。

2023-09-20: 知觉

我们很熟悉感觉,即用身体器官去感受世界而觉察到一些东西。它包括视觉、听觉、触觉、嗅觉等等。

知觉是什么?在梅洛庞蒂看来,从身体到心灵之间的桥梁就是知觉,知觉是基于心灵的认知的感觉,它把身体和心灵给紧密联系起来。

试想,如果我们在感觉之前,没有任何的感受经验,对将要感受的外物也没有任何的认知,那我们会如何对待接下来的感受?大概就如同婴儿,只剩下一些模糊不清的本能反应。

如果我们没有感受,而只有心灵,如同笛卡尔所说“我思故我在”,那我们可能根本无法成长起来,因为婴儿最开始的成长就是不断感受世界。即便成长起来了,没有身体的心灵也将如果植物人一样没有任何依附。

所以,心灵和身体是和谐的,不可分割的,知觉就是建立它们之间联系的桥梁。我们依靠心灵的思考,结合从感觉中获取的信息,而与世界进行交互。

2023-09-19: 匠艺与匠人

我们常常听说软件匠艺,字面意思是指把软件做成艺术品,这应该是每一个做软件开发的人的追求。

我对此的理解是,要做软件匠艺先做软件匠人。

什么是匠人,最初的匠人是指精益求精的手工艺人。在软件开发领域同样需要精益求精的精神。

如果你舍得多花五分钟把代码格式调整好,那你就在精益求精的路上往前走了一步。

如果你舍得在写代码之前仔细思考如何用一个更好的模型来抽象当前的问题,那你就在精益求精的路上又往前走了一步。

如果你不惜多花费一点时间从软件的用户、代码(api)的用户角度思考如何设计一个易用且好理解的接口,那你再次往前走了一步。

如果你对做好的功能建立了良好的易维护的测试,那你离匠人就更近了,你的软件就离匠艺更近了。

好的软件的背后是好的软件开发人员,是对好的极致追求。

2023-09-18: 逛超市

周末,午饭后,躺在沙发上休息了一阵子。我叫上她一起出去走走,消消食。去超市吧,顺便买点东西回来。

下楼,穿过地铁通道,往超市方向走去。她走得很快,我不得不叫住她,“你走太快了,能慢一点吗?” 她也突然意识到这一点,才放慢脚步。但是,走了几步,竟然又开始恢复到之前的速度。

到超市了。如何逛?我说,“我们要走一走每一个货架,看看以前都遗漏了什么”。于是我拉着她沿着货架左拐右拐,像是寻宝一般。超市的东西还真是多种多样,想得到的想不到的东西都有,包括各类睡衣、婴儿车、鞋子、毯子、玩具等等。食品区东西更是丰富,诱人的果脯,新鲜的水果和牛奶,各类糕点,各类干粮,卤的炸的,不管是颜色还是香气都肆无忌惮地诱惑着你。逛完之后,不禁感叹,人类的物质竟然丰富到这样的程度了吗?

我还在寻宝,但是她对此似乎没什么兴趣,望着一处搭建好到帐篷发呆。我叫她,这才反应过来,继续一同往前走去。

你越慢,时间越慢,你越快,时间越快。然而,生命的时间是有限的,究竟是要快一点还是慢一点?

2023-09-16: 没有成行的钓鱼

有一个漂亮的湖,湖水里经常有会飞的野鸭子出没,你明明看到在某一处有一只野鸭子,一转眼它已不见了身影。你开始睁大眼睛四处找寻,过来好一会儿,终于在几十米开外的地方突然发现有一个鸭子头从水里钻出来。

湖边是绿油油的草坪,这里几乎没有人,你可以肆意的进去踩一踩松软的草坪,甚至坐一坐,或者打个滚,丝毫不会影响小草的生长。

湖边的树木也是经过精心设计的艺术,一大株一小株相间排列,品种各样。小鸟禁不住诱惑,高兴地在树丛间飞来飞去,叽叽喳喳似乎在向同伴述说自己的意外发现。

有一次,我和家里人在湖边散步,看到有几个年长的人在钓鱼。他们不紧不慢,悠闲的坐在湖边,水里面的线很长时间也没有动一下。但是他们不在乎,好像只是在等着那些愿意上钩的鱼儿。这让我想起了儿时钓鱼的场景,那会儿钓鱼可是我们几个小朋友最大的爱好。

我说,我也要找个机会来钓鱼。

第二次,看到类似这样的场景,我说,一定要找个机会来钓鱼。

第三次,我也这么说过。

现在,时间已经过去了一年有余,钓鱼终也没有成行。也许再也不愿意花几个小时安安静静坐在湖边了。

2023-09-15: 一个管理命令行工具的工具

开发人员在开发阶段常常需要执行很多自动化的shell命令,以帮助完成测试和调试工作。

虽然执行命令已经很快了,但还是免不了需要手动输入命令名称以及命令参数。特别是在命令和参数非常多的时候,记忆负担变得更重了。

我们实现的开发工作台(data-workbench.com)引入了这样一些方法来解决这个问题:

  • 提供一种方式将这些常用的命令分组并添加描述

  • 提供多种访问和执行这些命令的入口,如网页版搜索、ide插件版快捷键等功能

  • 在上述这些入口中,提供自动参数校验,参数历史记录等便于使用的功能

有了这些功能,不仅记忆负担大大降低,而且方便了团队里面大家共享这些命令行工具。团队效率得到极大提升。

2023-09-14: 一个开发者工具的出现

为了能及时获得开发反馈,我们开发了一个工具,将easysql编写的etl转换为impala可执行的sql代码。它给我们带来了极大的便利,定位olap引擎的impala可以非常及时的告诉我们代码是否有问题。

但是,改进似乎是没有尽头的。工具虽然好用,但是是以命令行的形式调用的。于是,为了能获得这样的开发反馈,总是需要手动的执行命令,拷贝代码,然后粘贴到impala的sql执行工具中执行一下。每改一行代码都需要重复这个工作。总是感觉很繁琐。

然后,我们又在酝酿下一次工具的迭代升级。思路非常简单,把之前需要手动完成的操作进一步自动化,使得开发者可以一键获取反馈,或者更进一步,自动在后台给我们提供开发反馈。

道家说,道生一,一生二,二生三,三生万物。回过头来看这样的工具演进路线,一个之前完全不存在的工具,似乎正在变得越来越丰富和完善。这可能是软件的发展之道。

2023-09-13: etl代码静态检查

作为数据开发的专用dsl–sql,它与其他编程语言存在着一个显著差异:其正确性严重依赖于外部环境。这带来了一些问题:

  • 无法在编码时静态检查字段有没有写错。一个字段在当前没有,不代表后续建表的时候不会重新加上;一个当前已存在的字段也可能在运行时被删除了。

  • 无法检查潜在的类型转换问题。比如,当你在按照数字类型处理数据时,如果实际上该类型为字符串,就可能由于类型隐式转换导致大量空置。

这些基本的错误常常在代码执行时才暴露出来,反馈循环太长,开发人员因此效率低下。

因此,数据开发迫切需要一个能实时连接元数据库进行静态代码检查的集成开发环境。目前有很多数据库专用开发工具可以给到这样的开发体验,比如Oracle提供的sql developer。但支持spark或hive这类大数据引擎的目前还比较少。

一个简单的实现思路是:

  1. 将sql代码转换为基于cte的一条查询语句

  2. 在最后添加一个用于输出结果的占位语句,如select 1

  3. 在查询引擎上面执行这个查询,并分析报错结果,然后映射回对应的代码行

2023-09-12: 想念

一位很久没有打电话问候的奶奶,突然入梦,慈祥的脸上还是洋溢着那般笑容。

她不愿意到城市里面和我们一起生活,一个人在农村老家待得自在。

上次回去,家里显得空空的,大大的堂屋里面只有一张陈旧的小桌子和两张长条凳。但是,她一个人在家,也要收拾得干干净净,桌凳上、地上、墙壁上没有一点灰尘。

上次回家带上一岁儿子一起,一开始,小孙子还认生,不愿意跟太奶奶亲近。太奶奶很想和小孙子抱一抱,张开双臂,嘴里温和的念叨着要抱一抱,还比着手势。小孩子纠结了好一会儿,最后笑着投入太奶奶的怀抱。

在老家,有人气的家里就会受燕子的青睐,上次回去,墙壁上又筑好了两个燕子巢。

2023-09-11: 影响

跑步,总是能碰到跑在我前面的。遇到实力差不多的,总是忍不住想要跟上去,从而不自觉地加快脚步。

图书馆,看到满座都是捧起书津津有味吸取知识精华的人,总是忍不住也伸手拿起一本,沉下心来,享受阅读的乐趣。

景区,附近一个停车的地方,一位当地的老乡说,这是他们自己家修的,不收费。附近的几处停车的地方也没有收费。

景区,你随手捡起地上的塑料垃圾,准备收集起来处理掉,避免污染环境。旁边也有人效仿你开始捡起其他的垃圾。

泰戈尔说:把自己活成一道光,因为你不知道,谁会借着你的光,走出了黑暗;请保持心中的善良,因为你不知道,谁会借着你的善良,走出了绝望。

这就是影响的力量!

2023-09-10: 这味道,停不下来

一锅香气四溢的辣子红油汤上桌,每人一个浅腹平底碗,装满调料。

服务员过来打汤,将一半敞口,一半过滤网的汤匙浸入辣子红油汤锅,旋转勺子底部撇开部分红油,舀起一大勺汤,过滤,倒入调料碗。

夹起一只美蛙,放入调料碗中,来回旋转几次,彻底浸入调料汁。拆下一块肉,送入口中。一辣一麻一香,以肉的位置为中心,瞬间四溢到周围的味蕾。活动牙齿,咀嚼一下,鲜嫩的蛙肉一下子散开。散开的每一小块都味道十足,带着劲道的汤汁无情地席卷整个口腔。

辣,刺激着口腔发痛;麻,让每一个口腔细胞都开始跳舞;香,带着令人幸福爽快的小分子穿越口腔和鼻腔直达脑门。

十足的辣让人想赶紧把食物咽下去,十足的麻和香又让人想把食物一直留在口中。于是,在辣味还未来得及传递到大脑时,赶紧咀嚼几次,得到美味的享受之后,辣味也快速到来,赶紧吞咽下肚。然而,大脑哪里能抵抗这种美味,立即指挥手开始拆下一块肉送入口中。

哪管他会不会长肉!哪管他是不是健康!这味道,停不下来!

2023-09-09: 宗教与诗

在很多西方人看来,每个人都应该信仰一种宗教。但是中国却很特别,一个具有数千年历史的文明古国竟然没有一个广泛信仰的宗教。

中国人如何处世?引导中国人一直向前的可能是诗。从最早的六经,到唐朝的绝句,到宋朝的词,到元朝的曲,再到现代的白话诗。

诗中的故事和情感,感动着一代又一代的人。诗中的哲学和世界观,引导着一代又一代的人。在彷徨时,诗给人以一束穿透迷雾的光;在失意时,诗给人以一种从容向前的动力;在成功时,诗警醒人前路依然不平坦。

宗教,虽然充满理性和逻辑,但总少不了神秘主义色彩。相比起来,诗是作者的想象,是脱离现实而高于现实的,这是读者在读诗之前就知道的。同时,诗中有大量的留白,需要读者去填补和想象;诗中有很多道理,需要读者结合自己的经历去体悟。

这可能就是为什么中国人的哲学既是出世的也是入世的,既追求内圣也追求外王。

2023-09-08: 负能量

小a上项目半天,说,我感觉很懵,别的团队上新人会有技术的业务的各类onboarding,这边都没有。

公司人员缩减,小a说,这两天上班心都悬着,别什么时候被约谈了。

小a遇到了一种新的语法规则,说,这个怎么这么奇怪,完全反人类,我是怎么都理解不了。

小a碰到一个不熟悉的工具,说,这个怎么这么难用,感觉很难理解,看不懂。

2023-09-07: 道德的本源

道德是一个非常抽象的概念。根据当今时代的理解,道德是社会意识形态之一,是人们共同生活及其行为的准则和规范,通过社会的或一定阶级舆论对社会生活起约束作用。(百度百科)

为什么道德是规则和意识形态?要追寻其最初的本义,需要回归老子的道德经。

经上说,“道生一,一生二,二生三,三生万物”。从这里来看,道是万物之源,并且,万物在生成过程之中,也都有“道”在其中。但是初始的“道”不同于万物之“道”,因此,“道可道,非常道”。

什么是德?在万物之中的“道”就是“德”, “德”的含义是“能力”或“品德”,它可以解释为万物本有的品质。“万物莫不尊道而贵德”, “道”是万物的由来,“德”则是万物本性的依据。

当今我们所指的道德更近似道家的“德”,即人的本性,本性具象化就是一些规律,延伸出来就是规则。

2023-09-06: 他乡遇故知

想象一下,你在一个陌生的城市,正在为生计做着事,突然一抬头,发现一个多年未见的朋友,恰好,他也看见你。

“xxx”!“xxx”!你们兴奋而又惊讶地相互叫出名字。

相约去大餐一顿。饭间,以前一起经历的往事,搞笑的尴尬的,变成现在的笑谈…

人类的情感就是这么奇妙,一次偶然的遇见,一段尘封的往事,就足以令人潸然泪下。

2023-09-05: 稳妥的技术路线

今天被一个hive分区问题给坑了。

问题表现非常奇怪,使用create table as select *…创建的表居然与原表数据量不一致!

调查了很久,发现了一些端倪:

  1. 原表为分区表,采用insert overwrite以动态分区的形式创建

  2. 查看底层文件系统发现,原表有一些分区列值为空的分区,以及分区列值为 hive__default 的分区

  3. 直接查询原表按照分区统计数量,不会出现上述不合法的分区

  4. 对新表(未分区表)按照原表的分区字段统计数量,出现了值为空及 hive__default 的数据

通过这些现象,可以了解到,可能由于之前某一次运行etl产生了一些脏数据。由于insert overwrite在动态分区场景下不会覆盖没有出现过数据的分区,所以之前的脏数据也一直被保留了下来。

在技术选择上,我一直推荐采用保守而稳妥的策略。事实上由于软件已经过于复杂了,如果再引入没必要的复杂度,那就很容易导致问题。比如,避免上述问题的一种稳妥的策略是,先truncate或drop table清除所有数据,然后再写入新数据。

一些其他常见的稳妥技术选择包括:

  1. 采用最简单和通用的语法,避免采用过于风格化的编程语言语法(如Scala过于复杂的类型推导)

  2. 采用最成熟的api,比如写在库或工具的上手文档中的那些api

  3. 保持实现的幂等性(类似纯函数),尽量隔离副作用

2023-09-04: 成就自己与成就他人

儒家之仁有两层意义。

  • 一是忠,即:己欲立而立人,己欲达而达人(《论语 雍也》)。

  • 二是恕,即:己所不欲,勿施于人。

第一点的忠,并不是愚忠(别人叫你干什么就干什么)。而是指,自己想要成功,就需要真心实意帮助别人成功。

当今社会很多人为了自己的成功不择手段,损害他人利益,这显然不是一种可持久的方式。对己难以保持平和,对人难以受到信任。

事实恰好在于,如果帮助他人成功了,自己往往也会成功。这就是:成就他人即成就自己。

2023-09-03: 生命不能承受之重

汽车突然刹停,“嘭”,一个响亮的声音传入车厢里的几人耳中。

“哇!”接着传来小孩的哭声。“遭了,这下遭了!”后排的人嘴里说着话,赶紧抱起摔倒的小孩。

大家开始检查小孩的伤势,鼻子旁边有擦伤,在流血,另一只鼻子也隐隐流出血来。

事发之前,小孩站在后排中间座椅上,刹车时,被惯性带着往前倾倒。由于正对着空调出风口,直直的撞了上去。

这是多幸运?只是一点擦伤!如果没有这么幸运,那可能就是生命不能承受之重!

2023-09-02: 代码行数的错觉

最近进行的是一个数据开发重构项目,最重要任务之一是改善先前代码的质量。

经过几周时间的分析和实践,我们发现核心问题是代码重复。

团队随处能看到一大段一大段的重复代码,一个800行的sql代码消除重复之后可能只有不到200行。

消除重复带来的益处非常明显:

  1. 原来的数据计算逻辑清晰地呈现了出来,代码更容易理解,调查问题更快了

  2. 不少隐藏的bug被发现并修复

  3. 取数逻辑的一致性得到更好的保证

代码行数一直是程序员工作量的一个参考指标,不少企业甚至为每个员工设定一个代码行数的目标。因此,很多开发人员为了达成这个所谓的目标胡乱复制粘贴代码,最终导致了低下的项目质量。

这其实是关于代码行数的错觉。

事实上,在代码量指标上,不仅不应该求多,反而应该求少。能完成同样功能的代码,当然是越少越容易维护。

2023-09-01: 数据流水线自动生成

在很多数据项目中,数据流水线的配置都是靠团队手工完成。这带来了很大的工作量(特别是在开发阶段),而且容易出错。

事实上,数据流水线完全可根据etl血缘关系自动生成出来。

我们在团队中这样做:

  1. 采用airflow这样的可通过代码定义流水线的调度工具

  2. 自动解析etl文件中的依赖表,并找到对应的etl文件

  3. 根据以上依赖关系自动生成etl依赖图

  4. 将此依赖图转化为流水线代码

自动化数据流水线的生成和管理给我们带来了极大的便利,节省了团队大量的时间。团队变得更高效和敏捷了。

2023-08-31: 核污染水的数据与逻辑

日本核污染水排海事件正在成为国际关注的焦点。关于这件事有很多说法,比如日本自私论,美国阴谋论,中国过分反应论等等。

日本举出了很多数据说明核污染水无害。然而中国的逻辑很简单,如果无害就没必要排海,如果有害就更不应该排海。

在这件事上,我们的态度应该是保守的,因为它关乎全人类的健康。同时,在这件事上,过分相信数据那是极危险的,因为数据极容易作假,特别是这样复杂的专业领域,漏报一项数据就可能让性质完全不一样。

这件事上更应该相信的是简单的逻辑,中国的逻辑就是简单而显然的。

在关乎健康的重大问题上,中国是偏保守的,这让我们很放心,感觉更安全。为什么要拿安全去冒险?钱是可以赚的,安全问题发生了,就无法回头了。

2023-08-30: 无处藏身的bug

业务应用开发中大家常常遇到bug,有些bug隐藏很深,甚至连专业的qa都没法发现。比如某些并发场景下出现的bug,某些极少出现的边界场景、需求未定义的场景下的bug等等。

但是在数据开发中,这些bug往往无处遁形。究其原因,有:

  1. 数据开发通常要并行处理大量数据,并发问题极易在开发阶段就暴露出来

  2. 数据开发通常要处理生产系统积累的全部数据,其背后覆盖了几乎所有业务场景

  3. 数据开发以专用的sql语言为主要开发语言,如果代码本身有问题,从结果上很容易发现(比如结果集数据量不对,统计上不符合业务直觉等等)

因此,数据开发人员在编写代码时应当极为谨慎,因为bug很容易暴露出来,而出现bug后也得由自己处理,总也跑不掉。

2023-08-29: 自动化一切

如何让团队变得更敏捷,也许应该从自动化一切开始。

自动化大部分工作之后,团队的各类开发规范就不至于只停留在纸面上,而是通过工具自动化得到保证。团队也不会因为一些低级错误而耗费大量的时间。有了自动化加持,团队可以集中精力解决重要问题,从而实现效率更高、质量更好。

就像先进机器是工业化时代的生产力一样,自动化工具就是敏捷团队的生产力。

如何推进团队工作自动化?要点在于在团队内部建立这样的意识,当每个团队成员在完成开发任务的时候都想着是不是可以把一些工作自动化的时候,团队的自动化水平就会越来越高。

自动化一切要求团队成员具备很强的技术基础,不过,这正好是技术人员努力前进的方向。

2023-08-28: 诱惑

小孩到了一岁半的年纪,吃饭慢慢变成一件令人头疼的事情。

勺子自己拿不太稳,同时专注力也不够,吃两口之后就动来动去,上蹿下跳。

家里人没办法只能喂饭,喂一口,又跑了,得跟着追。有时候喂快了没吃完,或者他只是单纯抗拒食物,到嘴里面了,也直接吐出来,吐一地。

最近发现一个特别有效 …

2023-08-20: 在紧张中创造

反思一下个人的内容产出频率,我注意到一个很有意思的现象:往往工作最紧张、压力最大的那一个阶段,产出却是最多的。

为何?紧张的时期,大脑一直处于思考的状态,所以新的想法就很多;当渐渐进入到一个平稳的时期,创造力似乎就渐渐离我远去。

为什么春秋战国时期有百家争鸣,各类新思潮层出不穷?大概是因为那个时代是一个局势紧张的时代,各诸侯国之间战事不断,不仅要求发展还求如何得人心。

古希腊半岛位于各个文明圈的中央,也正是由于和周围的城邦不断的进行交流和碰撞才产生了西方哲学的萌芽。

所以,站在人类的历史长河看,有竞争的乱世也并不是一件坏事,因为它常常是破旧立新产生突破的时代。

2023-08-19: 记忆里的人

在记忆里她一直是一位很慈祥的母亲。

她很会做饭,曾经在一个山清水秀的煤矿厂里给厂子里面的人做饭;数次春节到她们家,也总是能有一大桌子菜等着大饱口福。

她也很慷慨,每次春节到她们家总少不了一个大红包;平时去也是各类零食水果从不间断。

她勤劳且持家,每次去她们家总是能看到干净整洁的房间;只要她在,总是在忙里忙外收拾这准备那。

很多年没常见面了,以后回去也见不到了。

2023-08-18: 半梦半醒

我左手抱着小孩,有一种沉甸甸的感觉。他今天很安静,没有吵闹。客厅的墙、过道、地板看起来都非常的清晰。我没有戴眼镜。家里人都正常在家休息,有的在沙发上半躺着,有的在房间其他角落走动。

我能清晰的知道这不是现实。但眼前的事物是那么的清晰和真实,即便在我的身体自然移动时,这些事物也可以正常地跟随切换。

我想挑战一下这自动在脑海里出现的场景,看看它的能力极限在哪里。

走进房间的过道,进入一间卧室。没错,是我们家的卧室!床和柜子的摆放都是没问题的。甚至连门上面的贴画上面的字都清晰映入眼帘。

穿出过道,进入了一个黑黢黢的拐角处,朝房间里面望去。这好像是好几年前的住过的房间。床和家具是深色木质的,被子铺在床上。看起来是被人直接在床上面躺过而没有将被子展平,有很多褶皱。衣柜的一边柜门贴着一张四方形的福字贴,里面有老婆很久以前写的八个字,字非常清晰。和我有关,读后感觉很感动。这个场景渐渐勾起了我更多的回忆。。。

2023-08-17: 程序员终极提效工具

最近的数据开发项目中,我们引入了一个etl代码编译解析工具,它可以自动分析代码为语法树,并从中提取代码相关信息。

然后,我发现有很多日常开发需要手工完成的事情都可以用它来自动完成,比如:

  • 自动生成建表语句

  • 自动生成数据血缘分析图

  • 自动提取输入表、输出表,辅助生成输入输出处理代码

  • 自动代码格式化

  • 自动重构

  • 自动提示待重构的代码

-…

有了语言级的信息支持,有一种思路一下子被打开的感觉。随着一个一个工具的实现,工作效率也是蹭蹭蹭往上涨。

程序员的终极提效工具是什么?除却GPT这种自动写代码的黑科技之外,那可能就是编程语言级的自动分析优化和代码生成了。

回想很多语言提出的元编程思想(比如rust),其实与这里的解法一致,不过它们大多由官方提供了支持。

2023-08-16: 当学习成为负担

最近团队在专业业务领域知识积累不太够,于是我们组织大家一起学习。

由于学习通常在工作时间之外,这势必会占用一些工作之外的其他时间。

这就导致了一个矛盾,团队成员可能不得不放弃一些个人安排,投入更多时间到学习中。

看起来学习成为了团队的一种负担。

但是,学习真的是负担吗?

回顾一下之前的学习过程就可以知道,学习常常能给人一种充实感。学到新知识了,我们会感觉获得更多能力了,变得更强大了。所以,学习常常是获得快乐的一种方式,而不是负担。

为什么会有人觉得是负担?可能是当代学以致用的观念胜过了学以致知。当我们将自己定位为一个学习的人,成长的人,坚持终身学习,把学习作为人生的一种状态,它也就不是负担了。

所以,是不是负担,关键在于个人的心态。

2023-08-15: 二级混沌系统

准确的预测可以帮我们更好的计划。比如,预测明天的天气,可以帮助我们计划旅游目的地;预测将来的行业趋势,可以帮助我们更好的选择职业。

随着科技的进步,越来越多的系统的原理被揭示出来,变得可以被准确预测。

然而有一类系统不可被准确预测,那就是二级混沌系统。

比如股市的预测,如果有一个方法宣称它可以准确预测股票的走势,那大家就可以完全根据它的预测结果进行股票交易。其结果反而将推翻之前的预测。

在这类系统中,预测会受到本身预测结果的影响,因而不可能准确预测。这就是二级混沌系统。

类似的系统还有很多,比如物理学中的测不准原理,政治预测,地图上的拥堵预测等等。

当下流行一句话,我预判了你的预判,这是指人思维也具有这样的特性。

在这样的系统中,一个科学的做法是什么?可能是要有多种完全不同的预测方法,然后不同的人选择不同的方法来做预测。这样一来,就有可能大家共赢。

2023-08-14: 动态的制度

在一个组织中,一项制度的确定一定是为了解决某一类问题,其初衷通常是好的。其操作过程也常常是因为得到大多数人的支持而形成。但制度常常解决某些问题却引出来另一些问题,这就是上面的政策引出来的下面的对策。

所以,制度的出台应该着眼于解决现实问题。但制度却不应该是死的制度,应该根据情况随时调整。对待调整的制度的态度应不亚于最初制定制度的态度,否则制度往往流于形式或导致更严重的问题。

钱穆在《中国历代政治得失》中说,应该用制度迁就现实,而不是现实迁就制度。直接生搬硬套拿来的制度不一定是好的制度,因为它没有着眼于具体的现实问题。而从汉唐一成不变的制度最终导致没落,又可说明制度需常改常新。

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

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

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

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