我越来越少去追逐那种看起来很“高级”的架构图了。真正决定项目后期是否痛苦的， 往往不是你用了多少层抽象，而是你有没有在一开始就把状态、边界和命名理清楚。
第一条：状态一定要有明确归属
Compose 写起来很顺手，所以更容易让人随手把状态塞进某个组件里。 但一旦页面继续长，这种方便很快就会变成麻烦。我的原则是： 局部交互状态留在局部，跨页面和跨流程的状态一定上提，而且上提到清楚可解释的位置。
这样做的好处不是“更学院派”，而是你之后再回来改代码时，不会花很多时间重新猜某个值到底是谁在负责。
第二条：组件要负责清楚的视觉职责
Compose 太容易把一个页面写成几百行。早期这么做没有什么， 但到了第二轮迭代，你会发现自己已经很难定位“这块 UI 为什么会这样”。 所以我会比较早地把页面拆成职责明确的部分，而且是围绕视觉和交互职责拆，不是为了凑层级而拆。
第三条：让命名尽量带上上下文
Kotlin 很适合写得干净，但干净不等于抽象到没人能看懂。 我现在会更愿意在名字里保留上下文，比如明确这是 dashboard 用的状态、learning flow 用的 action， 而不是全项目都共享一些过度宽泛的名字。
可维护的代码不是最短的代码，而是几周后你还能一眼认出它在干什么的代码。
第四条：先把页面跑顺，再谈复用
很多复用其实来得太早。你以为自己在提前设计，实际上是在提前锁死。 我的习惯是先把真实页面跑顺，等我看见第二个、第三个相似场景之后，再去决定哪些东西值得提出来。
这种做法会让前期稍微“没那么优雅”，但从长期看更稳，因为你提取的是已经被验证过的模式，而不是预想中的模式。
最后一条：体验判断永远高于代码洁癖
我喜欢干净代码，但如果一份“更漂亮”的代码会让交互节奏变慢、页面结构变绕， 我会优先保体验。毕竟用户看到的是产品，不是你的项目结构图。
这也是我写 Android 时越来越坚定的一点：代码组织是为了支持体验，而不是让开发者自我感动。 如果一个项目最后真的好用，大概率是因为代码和体验都在为同一件事服务。