AI 编程时代，代码审美还重要吗？
从 Docker 部署开始，以及已经流行多年的微服务架构，难道不就早告诉你代码的发展趋势了吗？
只要实现功能，满足预期性能指标，不出错，能运行。谁管你代码怎么写。你全是机器码硬造都成。
要换就是直接把一个模块拆了另造。只要架构文档和功能指引文档和验收标准还在就完事。
根本就不是「现在」才出现的。
在很多年以前就是这样的运作模式了。
大部分时候所谓的「代码审美」，除了极少部分小团队必须多人维护同一套不可分割的代码库之外，大部分时候都是程序员自己幻想的「通用」「复用」梦想而已——实践中从没发生过——翻译：无用功。
高内聚、低耦合，这句话你猜隐藏的目的是什么？（当然是直接换模块啊 = =~）
阮一峰最新周刊里引用的一段话
实话实说，现实中，大多数程序员的代码其实都很糟糕。
但是，糟糕的垃圾也分等级。一种情况是代码就像意大利面条（Spaghetti code），乱成一团，根本理不清。
好一点的情况是「糊状千层面」（slop lasagna）。这种代码也是糊在一起，但分成了很多层，至少可以按着层把它分开。
即使无法写出优秀出众的代码，你也要尽量避免意大利面式代码，争取写出千层面式代码。
一个实例就是 React 框架，它把代码拆分成组件，这样的好处就是，哪怕每个组件都是垃圾代码，至少可以单独替换某个组件。
删除组件、复制组件、内联组件、重写组件都是很容易的操作。因为组件之间是分离的，它让你只需关注单个组件的内部代码。
只要你的组件树的设计是合理的，那么单个组件内部的具体代码就无关紧要。某人写了一个 10000 行的垃圾组件，哪有什么关系呢，最终有人会重写它，它影响不到代码库的其他部分。
只要代码是千层面结构，那么单独一层很糟糕，并不影响全局。
真正重要的是下面的事情。
- 数据如何在系统中流动，当前的数据从哪里输入，又输出了什么，以及你存储了哪些数据。
- 用户体验如何，有没有明显的漏洞、糟糕的性能、前后不一致的行为。
- 基本的抽象概念是否正确，有没有误用。
只要上面三点 OK，代码又是组件式的可抽换结构，那么程序就没有大的问题。 这时，某个组件是否冗长、写得好不好、是否简洁合理，有没有小 Bug，其实无关大局。
