接手过一个别人写了三年的订货系统，后端系统开发的分层在那项目里完全不存在，一个控制器文件足足六千行，改个运费计算规则，得在里头翻半天，还牵连着三处复制粘贴的同款逻辑。客户抱怨后期改动报价越来越高，根源就在这：分层乱了，代码就成了一团毛线，谁碰谁扎手。
三层各管各的事
正规的后端系统开发，代码至少分三层走。控制器只干一件事：收参数、调业务、返结果，它应该薄到一眼看完；业务逻辑全部放进服务层，运费怎么算、订单状态怎么流转，规则都集中在这；数据访问归数据层，SQL和数据库打交道的事别让它漏出去。分完之后你会发现，改运费规则只需要动服务层一个文件，测试也只测这一块。
分层失守的典型症状
- SQL语句直接写在控制器里，换个页面同样的查询又抄一遍；
- 一个函数三四百行，注释只有一句处理订单；
- 两个模块需要同一个功能，答案是复制一份代码改改；
- 新人接手两周还说不清一个请求从哪进来、到哪出去。
这些毛病单看每一处都能跑，攒上两年就是技术债滚雪球：改一处崩三处，开发报价跟着翻倍。有位客户的老系统报价单上写着同规模新项目1.8倍的工时，问原因，对方就发了那个六千行的文件过来，他当场明白了。
分层还有一个容易被低估的好处：换人不慌。层次清楚的代码，新人照着目录结构就能猜到功能在哪，接手成本差出一个量级。企业经营里人员流动是常态，代码组织方式决定了流动的代价，这一点在做系统规划时就该想清楚，而不是出了问题再补救。
怎么让外包按规矩写
别指望团队自觉。签约时把分层规范写进技术方案附件：控制器不做业务、SQL不进控制器、公共逻辑必须抽服务。开发中段要求远程演示一次代码结构，随机抽两个功能看调用链走没走对路。验收时留一条：代码结构不符合规范的整改后再付尾款。
分层这件事，最好的启动时机是第一个接口写出来之前。等系统跑起来了再补分层，等于给住满人的房子重新走管线，每一步都束手束脚，报价还翻倍。后端系统开发的代码组织方式，本质上是在为未来的改动买保险，保费便宜的时候别省。
两条实在建议：新项目立项就让开发方给出代码分层说明，讲不清的直接减分；存量系统如果改动越来越贵，先花小钱请比格网络这类团队做一次代码结构体检，理清病灶再决定补还是治，比蒙头改省得多。
