团队编程思考：组合优于继承、依赖管理、注释习惯、缓存过期

起源

在修改自己几个月前写的一些脚本时，感觉看不懂自己写的一坨类继承，函数包装不到位，一堆if else，不敢乱动，直接重构。

组合优于继承：Rust

rust有提过“组合优于继承”的观点，在看了几圈评论区，总结出：对内组合，对外继承。 将继承控制在2层以内：父类与子类。

继承最糟的情况是，继承链过长，你根本不敢乱动中间的类方法。

组合就像并联，继承就像串联，串联一个坏，全部都坏。

例子：ECS游戏

Composition is usually meant to be used to make a collection of things come together in one package, while inheritance is more useful to prevent duplicating lots of code.
组合通常用于将事物的集合组合在一个包中，而继承对于防止重复大量代码更有用。

Seems like you're trying to do is reduce the amount of code duplication, which can be done with components as well as inheritance.
似乎您正在尝试减少代码重复量，这可以通过组件和继承来完成。

依赖管理，化繁为简:Pixi

用了2年linux，感觉linux的包管理对于个人主机很不友好。我既可以在用户目录安装java，也可以在系统目录安装java。这种情况我更喜欢装在个人空间。用久linux后，系统的包都不太想去维护与清理了。目前我用pixi来管理其他包管理器的更新(bun, pnpm, uv...)

pixi似乎专门在包依赖上下足了功夫，能很快计算出依赖链很深的安装方案。

我自己也在构想一个依赖管理方案：尽量共享最新的依赖，否则就单独下载旧版本的依赖，调用单个软件包时，组合出一个临时环境以供运行。

1. 维护勤快的软件包，共享最新最稳定的共同依赖，减少安装空间。
2. 过时的软件包(obsolete)，则与其他的软件包共享过时的依赖环境。

新编程语言

如rust与zig，我发现以后要想发明新的编程语言，你得：

• 语法不能乱改，乱改大家都不敢用最新版，如c++
• 语法可退化：宏条件（如类型、生命周期等约束）可写可不写。详见 类型体操(Type challanges)
• 编译期与静态代码共享同一套语法，如zig comptime，c++头疼的宏定义
• llvm编译器、打包
• 包/依赖管理器
• IDE语言服务器
• 测试框架
• 文档生成

写注释vs不写注释

As I say often: code should tell you what, comments should tell you why.
正如我经常说的那样：代码应该告诉你是什么，注释应该告诉你为什么。

一定要写为什么的注释，写这段代码的目的。

class vs dict

之前的脚本有个坏习惯，用基础类型dict而非class来访问变量。dict类型未知，静态提示不起作用。

只有在跨语言、跨进程、跨框架，才需要将class转为基础类型（serialize）来传递，否则用类能更好去约束自己写代码。

UI更新，广度优先

• 深度优先：在使用 baobab 分析磁盘空间时，它总要全部扫完才出结果。我想让它先浅浅扫描第一级目录，先显示出有哪些一级父目录，再逐层深入，总体慢一点无所谓。
  但凡涉及搜索类的功能，最好都是广度优先，先把父结果呈现出来。