过了那个村,就没了那个店--谈技术负债

技术负债,指的是为了实现客户的某个需求,而做出的一种短期见效快,长期有伤害的,在技术层面的决定。更通俗的讲,就是坐在代码面前,只顾现在,不管将来。代码满足了客户的需求,却写的很糟很乱,为以后进一步开发新功能,做了一个坑人的铺垫。

上面讲的是技术负债的大概意思,下面讲以一个亲身经历的故事,想说明的是,技术负债,如果你当时不还的话,一旦错过了那个村,以后就很难再找到那个店,想还就难了。

出于不能透露公司秘密的目的,我就只笼统的说一下,(其实和模拟金融产品的收益与亏损有关,;p)。那是一个规模挺大的开发,引入了不少新功能,用了基本一年的时间。出于模块复用的原则,也就是不再造车轮的原则,我们最大限度的重用了原有的模块。由于原有模块的使用情景和新功能的情景大有差别,在重用之前,我们先改了原有的,使它从不可以被重用改善到可以用。说实话,改的有点牵强。

新功能实现了之后,客户很开心。可我们,总感觉有些地方不太对,略加分析,发现,两个不同情景下的模块有不少共同之处,其实当初应该再往前走一步,把共同的部分隔离出来,写一个更加抽象的模块。把确实存在差异的部分放在不同的模块里。

我现在说的听起来容易,其实做抽象没那么显而易见。这要求你,从更深次的角度去分析两个不同的问题,融会贯通,找到它们的共同点。抽象,在编程的各种能力中,处于一个很靠前的地位。

问题发现了,可我们却作难了。为什么?因为新功能已经交付了,客户也很满意。你现在非得给客户说,能不能再给我两万块钱,让我好好抽象一下。哈哈,你不是在搞笑吧?给你钱让你抽象?!你抽不抽的好是一方面,万一把原有的东西也破坏了,你这不是让人家客户抽搐吗。

其实我们的客户不是那种不懂开发油盐不进的客户,他们也知道,现如今不抽,以后再开发新功能的时候可能就会更难。可是既然新功能好用,他们又有很多其他方面还没实现的想法要做,他们更倾向于立即着手于其他的项目,等以后有时间了,也有闲钱了,再让我们搞那些很抽象的工作。

可你仔细想想,谁会有时间,谁会有闲钱?所以技术负债,就像打尖住店一样,过了那个村,就没那个店了。

真的就没有解决方法了吗?我思来想去,结论是没有什么神奇的方法可以解决所有的问题。

你可能会说,留在那个村,别走,解决完问题,再走不就行了吗。我同意这个观点,留在那里不走可以,前提是你给客户预先说好,你需要多少时间,多少预算,才能把问题解决的好。可实际情况呢,很多潜在的问题,在项目初期很难被发现,很多问题都是在实践的过程中发现的。敏捷开发,有利于解决类似的问题。但是越是到后期,和技术负债相关的请求,就会越难被接受,因为的他们的投入产出比小,风险大。更糟糕的情况是,有一些东西,是需要事后的消化,后知后觉的,就像我上面遇到的情况一样。

设计重要,前期周全的设计更是重中之重。小的负债一定要在它的萌芽阶段就消灭掉,越早越容易说服别人。

谢谢您逗留阅读,我是热情洋溢的程序员,王辉。