正文
于是，你和公司商务部决定在两天内给产品强行植入一个主题。这种简单粗暴的方式，将会使你们的代码变得混乱且丑陋不堪。可是因为该客户实在太过重要，即使是CSS写得不太妥当，也只能暂且从权。 这就是我所说的技术债。
其后，你们交付包含主题的产品，客户签订合同，双方皆大欢喜。而此时的你（以及商务部）则需要做出决策：
-
回去把主题作为一项核心功能，增加到公司的CSS代码架构中。同时将先前临时添加的主题纳入正式的代码框架。
-
或者什么都不用管。因为到目前为止一切相安无事，客户已经完成付款，而且双方也已各取所需。看起来已经没有再投入时间和精力来收拾残局的必要了。
选1，偿还技术债；选2，无视之。
选择1：限于当时的情况和条件，你已经尽己所能。你知道如果不是形势所迫，本可以有更好的办法。此刻的你，就是要把更优的方案付诸实施。
选择2：你就是在逃避偿还债务的责任。而且这样做，会使还债的代价随着日积月累而不断增加。之后你还会遇到更多麻烦：
-
你的SaaS产品为你的一个客户提供了主题功能；
-
之后，另一个潜在客户可能也会要求给他们的产品同样增加主题。
-
面对这样的要求，你既无法拒绝，也无法立即满足；
-
于是你强行植入另一个主题，从而又增加了一笔技术债；
-
后面还有一连串的主题等着你继续添加，债务将会越积越深。
你令
软件熵
不断攀升，却丝毫没有要解决现有问题的打算。
然后，类似的需求接踵而至，你不得不一而再再而三地植入新的主题。债务越积越深，而你却无力偿还。经历了相当长一段时间之后，代码会变得臃肿不堪且难以维护。最后你不得不把所有东西推倒重来。然而最痛苦的地方在于，此时你所付出的代价，比你在最开始就选择还债所付出的代价还要多。2天时间的应急方案，再加上5天时间做重构，也依然要比之后花好几周时间重写CSS代码耗时更少。你的技术债策略最终变成了一次大败亏输的经历。
其实不良代码原本可以避免。当初摆在你面前有两条路：正途亦或捷径。在明知道可以走正途的情况下，当初选择走捷径的你绝非一时糊涂。偿还债务的过程是一条艰难的自我救赎之路。
优良债vs不良债
迫于形势而欠下的技术债本无可厚非，前提是你要心思偿还。技术债也可以成为解决商业问题的一种有效手段，当然，事后补救的过程是必不可少的。不过这并不意味着所有形式的债务都是可以被等同看待。现实世界的债务也要分三六九等。
优良的债务可以是：
有好多种形式的债务，它们可以采取有效的手段来确保债务人具备偿还债务的能力。这些债务的选择，是你经过深思熟虑后的结果，因为它能鞭策你去赚更多的钱，是能为你带来切实利益的。
