如今 Vibe Coding 盛行,然而就算是用 AI 写代码,也少不了要考虑如何划分好模块、保障低模块之间耦合以及系统的拓展性。
如何划分好模块这些事是传统软件工程和架构设计范畴,但你做好了的话,AI 生成的代码质量更高系统也更稳定。
很多新手对于如何划分模块并没有什么概念,甚至很多编程老手也只是直觉知道怎么分,但也讲不出个所以然。
一句话:模块按“什么会变”来分,不是按“先做什么后做什么”来分
新手容易犯的一个错误是按照流程来划分模块。
拿电商网站来说,购物流程是:用户下单,先收到请求,再算钱,再扣款,再存库,再发邮件。
如果你把每个步骤拆成一个模块,当然可以,但是这其实并不利于后续的维护。
顺着步骤分,改动会顺着步骤一路扩散。举个例子,你想给订单加一个“预计送达时间”,收到请求要处理这个字段、算运费要用到它、存库要存下来、发邮件要显示它,四个步骤都会受影响,如果不小心漏掉一个地方还会出问题。
好的做法是:先列出将来最可能变的东西,然后把每一个会变的东西放到一个模块里,外面的人看不到它是怎么实现的,把信息隐藏起来。
比如说前面那个购物的例子,电商网站里会变的东西有:
- 支付渠道(今天支付宝,明天加微信,后天做海外要接 Stripe)
- 优惠规则(运营隔三差五改一次)
- 通知方式(邮件、短信、App 推送)
- 数据存哪里(MySQL 换 PostgreSQL)。
这么分下来,支付、优惠、通知这些都可以单独做成模块,各自的变化都只影响自己的模块,不会影响其他地方。比如说你要给数据库加一层缓存,只要改数据存储模块就好了,其他模块都不受影响。
要是你觉得太复杂,也可以简单的按业务功能分,因为会一起变的东西通常就属于同一个功能,所以按功能分一般不算错。
但不要按步骤分模块,这样会把本来应该放在一起的生生按照顺序拆开了。
判断标准很简单:一个需求改动来了,你需要动几个模块?理想情况是一个。
要是运营改个优惠规则要同时动好几个文件,说明模块分错了。
按照这种“什么会变”的方式拆分模块对 AI 来说也是最友好的,因为 AI 本来就受限于上下文窗口长度,如果一个变更只要在一个模块内部就能解决,那么需要的上下文会少很多。