关于技术债务

有个朋友最近一直觉得自己有点胖，该减肥了。不过周一心情不太好，听说美食可以消除郁闷，所以先对自己好一点。周二难得食堂做的是自己一直喜欢吃的东西，不吃可惜了，干脆吃爽了再说。周三天气不好，反正不能出去锻炼，干脆再懒一天。周四……...





题图：100 views of tokyo by Shinji Tsuchimochi

有个朋友最近一直觉得自己有点胖，该减肥了。不过周一心情不太好，听说美食可以消除郁闷，所以先对自己好一点。周二难得食堂做的是自己一直喜欢吃的东西，不吃可惜了，干脆吃爽了再说。周三天气不好，反正不能出去锻炼，干脆再懒一天。周四太忙了，总得好好吃饭吧？周五……下周再说吧。直到有一天，逛街买衣服，发现衣服不知不觉已经大了一个号。赶紧健康饮食，每天尽可能的控制热量，这才慢慢瘦回来了。

有个朋友一直觉得房间里乱七八糟东西太多，院子里枯枝落叶也没收拾。可是一到周末，不是有聚会，就是要加班，再要么就是出远门，或者累了犯懒……一直到有一天家里要来客人，这才勤快起来，赶紧打扫。家里又整洁起来。

有个朋友喜欢一个人，却总觉得对方若即若离的。干脆断吧，今天也狠不下心，明天又舍不得……直到有一天，亲眼看见他对另一个女生好，才痛快的放手了。

有个朋友最近一直觉得太累了，该休息了，不能再熬夜、加班了。可是今天有急活，明天有重要的活，后天有自己想做的活……直到有一天真的生病了，还病的不轻，这才去留意一下自己的身体信号，好好歇一天。

鬼扯完了。

其实我们平时工作中有时候的技术债务也是类似的。知道一件事如果不做，早晚麻烦会找回来。但是因为总有一些更紧要的事情耽误了，就耽误下来了。

快到年底了，新产品要发布了，各个项目要收尾了，本来想总结一下哪些技术债务真的给我们带来了麻烦，却发现似乎没有很多。回想起来，得益于整个团队里几个很好的做法。

首先就是系统设计的框架是对的。什么叫对的呢？主要有两点：一是它可以有效处理所有的主流的、常见的、可预见的情况。二是对于未知的、可能出现的特殊情况，系统设计中一个很小的变动就能解决问题。这一点感触尤为明显。今年我们主要做的是 API，开始做不久的时候，我也写过一篇文章 API 杂谈。这个 API 最先支持两种产品。后来一边开发的过程中，我们又加入好几种产品的支持，每个产品在产品功能上都改过好几次需求。但是整体的 API 自始至终，并没有发现任何设计上的大缺陷，让整个系统需要大规模重构。当然确实也遇到一些之前没有想到的情况，但是都在一些适当的扩展和调整后就可以处理。

要做到这一点其实很难，没有在相关领域的丰富经验是做不到的。所幸我们组的老大在支付领域浸淫了近十年。最初 API 设计原型拿给他看，几乎每次立马他就能提出一个场景问你该怎么处理。这样来回讨论修改，很多细节的地方也能想得很远。虽然当初设计花的时间挺久，但是后来产品上的种种需求提出来的时候，我们的设计或是本身就可以很好地支持，或是很快能想出一个不需要大改动的解决方案。

不用去 Hack 自己的系统以完成某个产品需求，其实是降低技术债务最事半功倍的一步。

第二就是所有工程师的主人翁意识。每个公司都有一套任务管理系统，例如 Asana 或者 JIRA 之类的。因为我们是多个项目共用的 API，也就会有多个项目组协作开发。在整个产品的开发流程中，我们每个组员都有一个很明确的 Scope，也就有相应的 Ownership。开发中的每一次 Code Review，提出的建议，有些可以立马采纳并放到代码改动集里。有些很快就会做的，会加一个 TODO 和负责这个 TODO 的人的名字。这样保证每个工程师随时可以在代码库中快速找到自己需要完成的代码改动。如果是更复杂一些的任务，大家往往给自己 Create 一个 Asana Task 或者 JIRA ticket。这些任务每周都会 Review，保证不会丢失或者遗忘。

第三是一定要有健全的 Monitoring 和测试机制。这是保证一些性能等相关的 Metrics 在整个开发过程中能保持 Healthy。比如开发中所有 DB 的访问量和增长速度是不是正常。比如任何改动对一个 Request 响应时间会不会有影响等等。这样才能保证一些系统级的债务不会悄无声息地埋伏下来。

第四是可以定期做一些处理技术债务的活动。我们每年一到两次，产品开发没那么紧的时候，会安排 Fix it Week 或者 Clean up Week 等。说白了就是拿出一周时间，大家找个风景宜人的地方，一边建立感情，一边专门用来处理任务队列里优先级比较低，或是工作量比较大的代码清理或者 bug。有时候也会分组，给每个任务或者 bug 一个分值，这样做成竞赛模式，赢的小组还有奖励等。用愉快的方式解决实际的问题。

最后，年度计划或者季度计划，都会把一些大的技术债务和系统重构需求提上日程。确保在问题找到我们之前，我们先找到他们。例如重写某些 Service，大规模的重构等。这些只有在来年或下个季度里实实在在地有资源分配下去，才有可能执行。

当然，最重要的，其实还是把技术债务的重要性提到一个被认可的位置上。工程师们如果能预见一个债务可能导致的问题，自然就会愿意花时间去处理。在某些公司，如何与产品经理沟通，以达成共识，也是关键的一个环节。

    关注 嘀嗒嘀嗒