处理技术债务

本文写于 2015-08，同步于自己的51CTO博客

背景：最近一直在给研发团队强调一定要把产品平台关键的账号系统分离出来，而不是和业务产品线有瓜葛。但是因为涉及改动太大，业务线很忙迟迟得到不到执行。在这种情况下，我协调召开了研发的紧急会议，要求务必在近期解决这个问题，甚至不惜减慢业务线的进度。其实如果大家仅仅是因为时间紧、任务重无法改动我倒不担心，我最怕的就是大家认为这件事情并不严重，在我做技术的9年生涯中见证过太多次因为不重视这种情况、或者推迟修正造成的更大或者不可挽回的问题，那我们用2周或者更多时间来修正半年前犯下的错误是完全值得的。

---

为什么我强烈要求这么做，具体原因不做分析，只需要说明我们是平台级的产品，账户系统是公共组件，如果这些公共组件却附属在其中一个或某个业务产品线中，大家就知道我们后期的灵活性和可扩展性面临怎样的困境了。

上面谈的这种情况就属于技术债务，技术债务的形成往往有两个主要原因：

1. 没有架构能力，对未来可能面临的糟糕情况没有预知；
2. 知道可能后期会面临问题，但是为了追求进度，暂时放弃精细化的架构设计；

对于第一种情况，不多说，等你发现问题时估计就有些晚了，相应的付出的成本也会更大。所以对软件为什么我们常常强调高端的架构能力，而不是仅仅机械的代码能力。

第二种情况其实大家是知道后期可能会遇到的糟糕情况，但是为了求快并没有进行好的架构设计，在此之后，大多数人会因为心理上的拖延或者生理上的懒惰把重构任务推后，这时技术债务就会像高利贷一样越滚越多，你要么倾家荡产去还债（完全重写），还有可能 go to dead!（产品失败）。

听上去很危言耸听，但是这恰恰是我在工作生涯中屡屡看见的。当你因为技术债务积累了一年、两年、三年时，你基于此的产品实现也会越来越复杂。即使你招聘到了业界大牛，当得知这种改动是颠覆性的，需要消耗大量的时间和人力时，也往往使其无法下手。反过来我也经历过几次发现这种问题时，我们力排众议，投入阶段性的力量全力还债的场景，我记忆中的几次通宵就是在那个期间发生的。

所以谨以一个技术人劝大家：前期如果能预见到技术债务，而且时间又紧张的话，自己多努力再努力去解决，因为这是为你以后争取时间和精力；中期如果能及时发现技术债务，不管付出再大也要有勇气决然解决，因为这可能关系到产品和你的生存；后期发现了这些问题那你就吸取教训，开展下一个项目时去避免。

再以一个处女座的工程师劝大家：请把自己写代码、做产品当作是在打磨一件艺术品，质量好坏是可以迭代的，但是如果你没这个态度我想永远不会产出优秀的作品。