《Code Complete》 Ch2
软件开发的隐喻。为什么选择读这章，一是顺序上本身排在最前（除了 Ch1 greeting 之外），二是我内心也有着很大的问号，尤其是在平时对自己所写程序的优雅、可靠度成者开发效率感到不满足时，会想，是否存在 一些概念或原则能让我对软件开发这件事有更好的理解，进而写出更棒的程序？解答此问题，便是阅读这一章，乃至于这本书的朴素期待。
章节内容本身就是以比喻（或类比）方式书写的，本体是软件构建 (software construction), 喻体是自然科学发展史。通过后者的若干经典事例，表明隐喻 (metaphore) 在科学界探索自然规律中的巨大作用。例子有，凯库勒梦见首尾相接的蛇从而发现苯环结构；气体分子（？？？），人们也曾借助已经掌握的声学探索未知的光学（以至于一度尝试寻找一种叫以太的物质，因为声的传播需要介质，光如果也类似，就会存在介质使其传播）；还有在物体运动理论上，亚里士多德派和伽利略的不同观点；从托勒密地心说到哥白尼日心说，人们对天体物理认识的变革……作者认为，不同隐喻之间未必是对与错的关系，更多是好与坏的分别。甚至提出，“How well … determines how well …”.
论到软件开发，作者既指出了不够好的隐喻如写作 (writing)，种田 (farming), 也讨论了更好的隐喻如牡蛎孕育珍珠，修造建筑，还有对工具的掌握与合理选用、组合。好的隐喻提供更多相关性、联想、启发，坏的隐喻则相反，而且可能导致误导性的联想。书中关于 building ？？？ 和构建软件的相似性 (parallelism) 说了很多，如：
+ 大体都遵循同一套流程，即问题定义、设计、准备资源、实施、完善（装修 v.s 程序优化）、审核验收。
+ 搭一间狗窝，修一所住房，盖一栋高楼，需要完全不同的设计思路。糟糕设计带来的后果也不可比拟。
+ 建材家具、工具通常由购买获得，很少自己生造；同样，软件开发也大量依赖轮子，不会轻易选择自己造。
+ 材料、资源固然有开销，但更大的开销是人力、时间。
+ 都不可避免面临改动。好的设计时修改更易进行，坏的设计反之。不同性质的修改意味着不同的成本。比如动一堵承重墙与动一面隔断，修改软件中一处关键模块与简单增添一个功能。
+ 软件开发使用的大量术语正是取自建筑工程领域。像 architecture, scaffolding, construction, 等等。共享词语的背后也便是更多的相似性。
那么，这些问题有解答我的问题吗？应该说有一半了。首先问题存在解，这一点至关重要。其次确实给出了许多阐释、启发性的观点。最后能否真正“增进对软件工程的理解，进而写出更棒的程序”，还不是立刻能知晓的，过些时候再看。
设计模式之visitor
k8s 源码解读中有介绍，《左耳听风》专栏也有一第专门过论，结合结诚浩的《图解设计模式》，简单例子可以理解了，稍复杂的，还是有点懵，特别是跟装饰器叠加在一起的例子。 目前的理解是这样：visitor 模式涉及两个角色，访问者、和被访问者。前者通常是执行一些操作/行为，后者通常是数据/资源。Visitor 模式目的是吧两者尽量解耦，使它们的改动可以各自进行，互不影响。不过总要有地方让二者发生接触，
？？？
之所以感到绕，是因为“接触点”从一目了然的直接访问，变成了你中有我、我中有你的方式，看上去好像纠缠不清。也可以当成是为了获得解耦的好处而承担了额外的复杂性吧。
其他
- To Complete
公司微服务框架封装好了 http/grpc, 使用时运行命令就自动生成 dto, api scaffold, 还没有直接体验过怎么用 grpc 实现 client/ server 通信。跟着 demo 写了一个。
- SuperSet
体验，入门。
- Presto SQL
TRANSFORM lambda 处理把 json 内容拼成一个串，和 MySQL JSON_EXTRACT(myfield, ‘$[*].my_json_array_element_property’). Presto SQL 不支持像 MySQL 那样的 $[*] 语法，只好曲线解决。
- Git sparse-checkout
折腾一个 git repo, 曲曲折折，接触到了 sparse-checkout 功能，在面对大的 monorepo 时很有用。可以只 checkout 特定目录或文件，好处主要是 clone、pull 更快， IDE 阅读代码的体验也更清爽，屏蔽了大量不关心的内容。
- 周末跑了个半马。
Appended