一周技术学习笔记(第73期)-技术债可能并不是一件坏事

第一个话题：

”天下武功，唯快不破“，这一点被互联网企业应用的炉火纯青，你常常可以听到MVP，小步迭代，快速试错等等。确实有时候快，不顾一切地快，发挥了很大的作用。

不快，可能就会被淘汰。

互联网的历史上，也发生过很多类似的故事。

比如早先MongoDB和RethinkDB在nosql市场上竞争的时候，RethinkDB一直追求更完美的体验，开发人员也比较喜欢。但是MongoDB发布稳定版比RethinkDB早了三年，尽管MongoDB因为个别的体验问题被使用者微词，但是这种“负债前行”，快速抢占市场的”快“动作却赢得了NoSQL时代的黄金时机，最终RethinkDB不敌MongoDB，在2017年1月宣布破产。

从这个故事中我们看到尽管MongoDB早期推出的时候有一些这样那样的被用户”说道“的体验性问题，同时呢，在MongoDB内部，他们的研发人员为了快速发布版本，也积累下来不少我们研发人员可以称之为的”技术债“。但也正是MongoDB的”举债前行“使得它们及时得抢占了市场先机。

技术债也可能是一件好事情。

但是，有债务你就要偿还，如果不偿还，你的产品和系统一样会被用户抛弃，比如上面这个故事里，如果MongoDB在市场占有率提升之后，不去修复原先“开疆扩土”留下来的“伤痕”，那么它一样不会持久。

在《高效研发：硅谷研发效能方法与实践》这本书中，提到一个案例，有三家公司。

A公司：只关注业务，不偿还技术债。

B公司：持续关注技术债，但对业务时机不敏感。

C公司：持续关注业务和技术债，对业务机会很敏感，敢放手一搏大量借贷，也知道什么时候必须偿还技术债。

图自《高效研发：硅谷研发效能方法与实践》

从上图我们可以看到，如下结果：

开始时，C的业务产出介于A和B之间，但和A的差距不大。随后，在抢占到一定的市场份额之后，C公司开始投入精力去处理技术债，于是逐步超过A。另外，虽然C公司此时的生产效率低于B公司，但因为市场份额的优势，所以总业绩仍然超过B。在高优先级技术债任务处理好之后，C公司的生产效率也得到了提升，最终将B公司也甩在了身后。

因此，我们可以利用技术债，但更要解决技术债。

那到了这里，我们就不得不思考，技术债是怎么引入到我们的系统中去的呢。

仔细想来，莫非两种可能性。

一种是我们主动引入的，迫于需求的交付压力，明知道有不良代码结构产生，但也不得不牺牲质量来完成既定时间的交付。

第二种是被动引入的，我们的产品不断的进行演化，原先的架构代码设计和实现都跟不上”时代的步伐“了，还有可能是我们的团队人员的能力跟不上”时代的步伐“了。

技术债务是不可避免的，关键是我们要有一套偿还债务的方法和节奏，无论”等额本息“也好，”等额本金“也罢，总之，你得换，早还早超脱，越晚还，后面的代价越大，”利息“越多啊。

有什么建议的偿还技术债的方法吗。

一般也是有两种方法。

第一种方法是把跟业务相关的技术债任务找出来，这样的优先级设置的要高。在每一个迭代中都尝试去修改解决1-2个。这样的技术债解决了之后，业务侧也是非常有感知的，更能体现出业务价值。我有时候把这种方法称为“运动式”偿还。

第二种方法是采用突击的方式，固定一个时间段，一群人来解决。比如某一个迭代就来解决技术债务问题，暂时不处理业务需求。这样的好处是研发人员可以集中精力去解决代码上的问题，可以更专注高效，没有了业务侧需求的打断。当然这种方式有一定的局限性，比如业务侧是否会同意他们的需求一个迭代都没有处理。我有时候把这种方法称为“阵地式”偿还。

无论哪种方法去解决技术债务问题，作为一个技术管理者，不仅要做业务需求的完成目标规划，还需要做技术升级的规划。

研发效能的三要素：准确、速度、可持续。

准确有了，速度高了，因技术债务缠身，不可持续，也是枉然。

|第二个话题：

作为打工者的我们，想让自己过得幸福，其实只有两件事。冯唐在他的一本书里面提到过，一位研究人类组织行为学的诺贝尔奖获得者说，人类幸福的根源，只有两件事：

第一件，跟人有关系，就是和自己喜欢同时也喜欢自己的人，在一起工作。

第二件，跟事有关系，做自己擅长又喜欢的事。

虽然只是有两件事，但其实条件很苛刻。

比如第一件事里面，在不是恋人的情况下，就只能寻求志同道合者。如果互相喜欢不可得，那就退而求次选择和喜欢自己的人在一起工作。第二件事也同样不好兼得，如果也还是只能其一，那就是选自己擅长的事情，慢慢的，你周围的同事会给你一个正向的鼓励，慢慢的自己擅长的也会变成自己喜欢的事情了。

参考资料：

《高效研发：硅谷研发效能方法与实践》

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。