技术负债

周中偶尔的机会,让我思考技术负债(technical debt)。

在软件开发过程中,代码的产生或多或少总是附带着“技术负债”。这些负债一般对最终功能没什么影响,但却对代码未来的维护、扩展、性能、安全多少有些潜在影响。

技术负债产生的原因,有些是为了快速解决问题,而不得已的临时方案;有些则是随着产品迭代,从无到有产生出的需求。例如有时本来应该在数据库新建一个表,但为了省事,直接硬编码。又如项目伊始的单体应用,随着业务增长,又要转化为微服务应用,等等。

技术负债不能杜绝,写下一行代码的同时,就会潜在产生一行技术负债。甚至有些代码,在当下看似“完美”。随着时间流逝、业务更替,他们面临修改、重构时,也被迫变成了技术债。

如果我们把技术负债抽象一层,类比一下,则会发现其他的事情也有类似“技术负债”的东西。做饭就非常典型:目标是产出美食,技术负债是过程中弄脏的锅碗瓢盆、弄乱的冰箱和调味罐。

不论如何,做饭后这些“技术负债”总是要偿还,否则下次做饭质量就无法保证。写代码也是这样,技术负债一日不还,就多一日风险。

一般来说,人们在偿还技术负债时有两种策略,一种是尽量早的解决,一种是尽量拖着不解决。前者让代码看起来更“干净”,后者则能更多更快交付产品。

多数的工程师,都倾向于尽早解决这些负债,一如厨子不愿意在脏锅脏盘上继续做饭。而那些只关心功能和产出的非技术人员,则多希望能拖就拖,先把功能做出来,让客户满意再说。

有时产品开发就会陷入这两者的博弈。工程师开发的不爽,效率就会下降;功能做的太慢,产品销量就会下降。

You Might Also Like
发表评论