技术债务不仅仅是技术问题

我要坦白一件有点尴尬的事。回顾我的职业生涯，我认为在职业生涯早期，我可能比较难相处。但我相信我已经从那些错误中吸取了教训。让我解释一下。

技术债务

开发者经常会提到“技术债务”这个概念。本质上，技术债务是指由于最初构建应用程序时的一些糟糕决策而遗留在应用程序中的“冗余代码”。这些决策有时是故意的，有时则是无意的。技术债务的特点在于它往往会自我累积——最初糟糕的决策会限制后续的选择，最终导致修复起来极其痛苦、困难，而且成本高昂。

“这个技术债务可以等等。我还有功能要交付！” pic.twitter.com/OrUZgGUbwV

— 更新日志 (@changelog) 2019年3月7日

关于技术债务，还有一点需要注意的是，当你刚加入一家公司或一个项目时，往往更容易发现技术债务——尤其是无意造成的技术债务。

误诊

大概在2005年左右，我积累了几年开发经验，信心满满。由于当时我对公司比较陌生（没错，那段时间我跳槽比较频繁），所以识别技术债务相对容易。从技术角度来说，我具备足够的知识来诊断问题。

但关于技术债务，我只有通过多年的痛苦经历才明白一点——尽管名为技术债务，但它并非仅仅是技术性的。它还涉及组织、制度、政治，而且，是的，往往也与个人有关。

每一项技术债务背后都有一段故事。有时，故事很简单，比如“糟糕！我之前没意识到应该这么做”。但更多时候，故事要复杂得多，牵涉到那些可能面临自尊心受损的人，以及那些出于非技术原因（例如“内部试用”或高管从朋友那里购买的软件）而强行推行解决方案的组织。有时，技术选择会与错综复杂的历史交织在一起，以至于很难厘清当初做出选择的具体原因。

关键在于，2005年的我掌握了足够的技术知识，能够诊断甚至解决我加入的公司中存在的各种问题。我带着这些技术知识一头扎进去，却发现背后隐藏着许多强大的障碍，而这些障碍并非技术性的。我的失败在于无法看到并诊断出技术债务中非技术性的方面，而这种失败常常让我感到沮丧。

学习倾听

基本上，我以前秉持着“先写代码，后提问”的心态，但其实答案很简单——花时间提问并认真倾听。弄清楚某些选择背后的原因。这样做能让我掌握诊断技术问题所需的知识（令我惊讶的是，有时更好地理解非技术原因反而让我意识到，我之前误诊为技术债务的问题其实是有原因的）。但更重要的是，这让我能够提供不仅代码本身有效，而且对我的同事和公司都适用的解决方案。

记住，提问和倾听需要时间和耐心。你不能像我一样，一开始就觉得自己什么都知道。我能想到的最好的比喻就是去看医生治病。医生可以迅速缓解症状，疼痛也会减轻，但却可能让问题恶化而未被发现。然而，一位好医生会花时间了解你，了解你的问题，探究疼痛的根本原因，并进行整体治疗。努力成为像2005年左右的我那样的好医生吧。