这两天在出 Klib 新版，其中改了一个较底层的数据结构。如果要详细地测试 Klib，至少要跑完 700 条测试用例。放在我目前的心态和时间，绝对要疯。

幸好当时写了充分的单元测试，跑一把，修复暴露的问题，基本我就有信心发布了。

单元测试真是好东西，可以自下而上保证每个模块的正确性。再加上其它的测试手段，基本就可以保证程序的可靠性。

可能很多人觉得写测试很烦。其实，在开发新功能时，写测试用例和单元测试，也是分析、完善思路的过程；可以从不同维度思考问题，避免遗漏。即使是花了些时间，也好过花很长时间调试问题，或者做重复的人工测试。

当小孩已经形成并发生不好的行为，当场教育、批评甚至打骂，其实收效甚微。

批评结果没有用，而是要知道他为什么这么做，这样的做法是从哪里学来的，他是情绪失控时的发泄、还是有意识地做坏事。多向前面想一想，才知道为什么，才知道怎么教育比较好。

打骂，只是发泄了自己当时的情绪，对教育无用。

为家人做选择时，在能力范围内，选择最好的。

不然，各种努力，又为了啥呢？把钱花在这个地方，不是最有价值的吗？

Klib 中有个「分享」功能，就是把自己某本书的标注分享成网页，比如 这篇

从开发的角度，这个功能很复杂，有单独维护一个服务器，接收来自 Klib 的分享、取消分享、更新分享内容、权限管理，还要考虑 CDN 分发、分发内容的及时更新，等等。

截止目前，从性价比来看，这个功能并不高。收益一般，维护成本很高；只要有 1 位用户在使用，就要保持这个服务 100% 在线。时间长了，当对服务端的代码不熟悉时，一旦有问题，就要花很多时间来修复。

当初，自己是为了学习 Python 后端开发，并尝试下分享，才上的这个功能。从学习的角度，这是好的。而从产品的角度，则很难说。

不过，反过来，如果总是做很简单的功能，且不说长期对自己的成长不利，即便从产品、从商业角度，也缺乏必要的护城河，很容易「被致敬」。而如果分享功能正巧很多人在用、带来很多收益，这个相对复杂的功能，就一定程度充当护城河，不那么容易被抄袭。

初期，可以「取巧」，用最小的代价，换取最大的收益。
而随着自己的成长，需要考虑壁垒，需要「守正」；用不断提高的门槛，保护自己的领地。

本来，今天挺好的：新版 iText 审核通过，Klib 的暗色模式也实现完毕。可，无意间发现之前填下的一个大坑，心情顿时跌入谷底。

之前的代码中，用哈希值作为 key 值…

哎，我怎么会写出这样的代码…

哈希，主要是确定不同，而不是确定唯一性。换句话说，哈希主要是为了毕竟 2 个值是否不同（当然，极低概率下，哈希相同的 2 个值，可能也是不同的）；而同一个原始值的哈希值，是很有可能变动的。比如，操作系统升级、Swift 运行环境升级等等因素，都有可能让基于 Swift 编写的哈希值变更。

主要的麻烦是，产品已经发出去了。要升级，必须保证已有用户的已有数据不受影响，这个挑战是非常大的。还好当时自己在数据库中冗余保留了原始数据，还有机会根据原始数据重新生成有唯一性的值，比如 MD5 值。

哎，再骂一次当年的自己，怎么那么年轻…