脉穗成长计划
做开发时间久了，最容易产生的一种错觉是：技术债只要暂时不影响业务，就可以一直往后放。以前我也这么想，觉得先把功能上线，后面有时间再重构。可真正的问题往往不是技术债本身，而是它会慢慢改变团队做决定的方式。 一开始只是一个临时方案，后来因为没人愿意动，新的功能只能继续绕着它设计。再往后，大家开始习惯于“这里不能改”“那个模块别碰”，最后连新人都不知道当初为什么这样写，只知道改动会带来风险。 但从管理角度看，技术债也不是说还就能还。业务有明确的收入目标，团队有发布压力，重构又很难立刻带来结果。站在项目负责人位置上，他们选择先交付，并不一定就是不懂技术。 所以我现在不太喜欢简单批评“管理层不重视技术债”。很多时候，技术团队需要做的不是反复强调代码很乱，而是把风险翻译成业务听得懂的语言：它会拖慢什么、影响谁、继续拖半年要付出什么代价。 技术债最难处理的地方，不是没有人知道它存在，而是所有人都知道，却没有人愿意为它承担当下的成本。真正值得讨论的，也许不是要不要重构，而是谁应该在什么时候为不重构负责。
发布于 广东
分享
评论
赞
未登录
友善发言
评论
加载中
