这周在看 《Clean Architeture》。
读这本书，我是想获得什么？我应该怎么读？
Top to Down: 我先过一边目录，有了大概的了解。
关于 clean Architecture, 我在很多场景都看过，但是一直没 get 到他的核心。
我能理解 mvxx，redux，但是无法理解 clean。这是一个困扰了我很多年的问题。
最近在写 redux for android。已经在项目上用了。在写的过程中，我又重新审视了几年前写的 mvvm 架构。
那是入职 YY 第一年，写的一个 MVVM。大概是一个 魔改版的 android live data，view model。
我写的时候预想的很多设计，后来都废弃了，或者没被好好使用起来。从现在使用的情况来看，是一个失败的设计。
但是从给项目带来的价值看，也还算不多。能够在 10M 级代码里的项目大量使用，支持了5年的项目开发，也不算太烂。
至于有一些经常被大家吐槽的问题，例如 3000 行的类，看不懂的面条代码。
这不是架构的问题，架构提供了解决多人协同合作的方法，提供了方便的分模块功能，
但是很多人偷懒，把所有功能写到一个类里，导致代码职责不明，callback 漫天飞。耶稣都救不了。
我已经看到多很多 3000 的类了，不管换什么架构，永远解决不了有些代码变成屎山的趋势。这不是编程问题，而是社会问题。你永远管不了有人喜欢到处拉屎。
软件架构是必须按使用者来量身设计。我以前不知道这个定律的专业术语，后来看到 Conway’s law:
1 | [O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. |
这是最贴近我做设计的想法。组织的规模，交互，决定了软件架构的设计整体框架。为5人小团队设计的架构，跟为20人团队设计的架构，考虑的就不是同一回事。
很久以前我在荔枝FM做架构设计，我想的达到的目标是 简单，快速交付。我把 mvp 简化到只有2-3个分层。因为这是只有5-6人的团队，创业公司需要的是低成本，快速迭代，验证，试错，复盘。
我在唯品会摸鱼的时候用的是不同的架构。但是我没有拿到荔枝FM，因为规模不同，目标不同。大公司要的是稳定，统一，不要出错，所有人按相同的模板写代码，甚至到处都是冗余的模板代码，
看起来写了很多代码，其实是在 copy parse，会打螺丝就行，最重要是不要犯错。这跟创业公司是完全不同的目标。
创业公司不怕大家犯错，甚至鼓励大家尝试各种可以提效的方案，尝试，然后找到更好的。在荔枝FM，不断尝试各种项目管理工具，团队协作工具，代码管理工具，敢在高速上边开边换轮胎。
YY 的团队规模，其实是比唯品会更大，但却是一个原始的状态。用着是乱来的MVC。Controller 是世界的中心，全部的功能在一个类，没写5000行都不好意思拿出来。很多人都不知道有 UI session data，UI session logic。
当我要在YY做架构，第一个要解决的就是分工，协作，但是不能像荔枝那样分。现在第一个目标要的不是快速交付，而是易于维护，扩展。（易于维护，扩展的代码，通常也意味着后续更快的交付）。所以需要解耦，分层，分模块，模块交互，协作，同时需要更多约束。但是又不能用起来太麻烦。
人多了，花在维护的成本远比开发的成本更高。这就是需要根据使用者来设计架构。这样我想起我们的后台设计，我们只有一个App的业务，10人的后台开发，却照着阿里搞大中台。而在两年后，阿里自己去中台了。
5 年后，我再次考虑客户端的这个架构。有些过度的设计，有些很好，却没推广的设计。我设想的，每个业务都分 核心功能core，分离的边界功能，context 共享状态。这些设计都在多次的App改版后被遗忘了。
后来推广的单例 service 架构，同时也继承了单例的缺点，需要多实例就很头疼，大部分场景确实简单易用。但是丢掉了我设想的 核心-边界-context 共享的模式。
当我再次写 Redux for android 的时候，我又想起这个 context 的模式。这是给5人小团队使用的架构。
我想保留模块交互，管理，共享，也想有单例的简单，我还没写出来。应该综合两者的优点。
我上周看 hilt 的 module，context 这个的定位有些像 Hilt 的 module，但是我不熟悉 hilt，没法深入对比。
我还不知道业界怎么称呼这个。可能看完 Clean Architecture 后我会找到答案。
2025-3-31
读了 clean architecture 的1/3。相对 redux，mvvm，clean 是更抽象的 pattern，例如 可以在 redux 里使用 clean 的分层，DIP，用于局部优化。
clean 更接近是 设计思想，redux 是编码实现。看 clean architecture 这本书就发现，clean 是从很多简单实用的 pattern 发展而来，而这些 patter，例如 SOLID,
是 coding 中的基础，在 redux，mvxx 也大量使用。clean 对这些基础 pattern 做了 更高的抽象，使其更贴近实际的开发流程，但是又不至于像 redux，mvvm 那么具体。
clean 很注重 依赖规则，DIP 是其很核心的一个 pattern。理解 依赖，DIP 是理解 clean 的关键。但是我想，这也是 clean 难以理解，被人诟病的地方。
过于注重抽象层级，抽象依赖，DIP，导致 曾经非常多。Redux，MVVM 可能 3-4 个层级，到了 clean，核心层级都分 interface，DIP 两部分，层级翻倍。导致常常觉得 是 过度设计。
过度设计 是个需要时间才能证伪的命题。因为是否过度，这个跟时间相关，今天的过度设计，到了明天，变更来了，刚好用上这个过度设计。
2025-4-14
读完了 clean architecture. 作者也意识到了 层级过多，可能存在过度设计的问题。后面的章节 给出了一些，简化或者渐进clean 的方式，不完全边界。
确实如我之前所想，clean 是一种思想，比 solid 更具体，但是比 redux 更抽象。在 clean 的很多原则，可以拿到 redux 使用。redux 可以是其中一种实现方式。