架构腐化的一个因素是向开发代价妥协
腐化的架构特征有: 大量的特殊处理, 兼容处理, 耦合严重, 积重难返. 架构都会慢慢腐化.腐化后的架构难以开发新特性, bug 难修, 牵一发动全身, 导致测试和 QA 也很难做. 我曾看到有跨行开发爱好者发帖说, 限制模型写代码时的抽象行为, 这样代码更容易看得懂.人更容易看得懂的代码, LLM 也会更容易看得懂, 因此可以快速开发且减少错误.我想跨行开发者大概工程量较小, 习惯流水线式逻辑, 如果有规模扩大的预期, 思维方式不能局限于流水线, 而是使用建筑工思维.预期盖30层楼房子, 即要打10米地基, 预期通水通电, 即要预留水井电井.这是目标明确的设计, 此外还有目标不明确的设计, 如房屋内某处将来要放电器, 但不确定放什么, 预留插座即可. 软件工程已有SOLID原则用于指导设计, 很多时候表象上来看, 遵循solid原则时实现相同的功能会跨更多的文件, 写更多的代码, 就短期结果来看, 设计和不设计在老板/测试和用户看来几乎没分别, 设计带来的好处只有在长期才能体现.一个好的架构容易加特性, 改特性, 修bug, 且更少引入问题. 设计需要的思考常常比直接上手开发特性要多, 设计需要考虑颗粒度, 直接把插座面板当瓷砖贴满全屋, 是另一种荒谬做法.以往我在开发时考虑开发周期, 会做取舍, 时间紧时连设计都不做, 加几个函数完事, 将来的事将来说.现在借助AI, 我们可以将设计的颗粒度做更小, 生成的代码人看着会更难懂, 但工程会更容易维护.增多抽象后, 差一点的模型的确有可能处理不好, 最好用当前最好的模型.如果只是写脚本, 那么模型间的能力差异可能不会太明显. 关于AI是否降低了开发者的准入门槛?我对此存疑, 毕竟新人开发者的学习路径和过往已截然不同, 讨论门槛高低可能没有意义, 因为我们不知道门槛被搬到哪去了.
