技術債務是對業務功能缺乏真正的理解 -daverupert.com

banq發表於2020-11-07

技術負債概念提出者Ward Cunningham認為：長期開發一個應用程式時，我們是透過不斷新增功能進行的，但是卻從未對其進行重新組織以反映我們對這些功能的理解，那麼最終該程式將根本不包含任何理解，因而在其上繼續工作程式設計所付出的努力將花費越來越長的時間。
知識管理在組織中是如此重要，但是他們很少經過關鍵的重構來反映當前的理解。
必要時需要進行大規模重構。如果組織的營業額足夠大或產品中的功能不斷增加，那麼進行重寫是最好的選擇，這樣您的團隊對程式碼有個整體的瞭解。不能指望人們在繁忙的程式設計中會實現難以理解的需求，或者在已經離職人的遺留程式碼中提高工作效率。
 
使用一個通俗解釋：如果吃完飯不洗碗不打掃廚房，那麼慢慢地就吃不到下一頓飯，重構就是洗碗。
 
技術債務不是寫得不好的程式碼：您編寫程式碼是為了反映您對問題的*當前*理解。如果這種理解是“部分的”，那麼您將承擔債務，即使如此，您仍會交付軟體（以瞭解更多資訊）。但是，您必須償還債務：您必須將新的知識納入軟體。
這就催生了兩個階段，第一個階段是你部分理解業務的程式碼，第二個階段是你償還債務納入新理解的程式碼，您必須滿足第一個緊迫的階段以後（先交付原型獲得客戶認可），才能獲得後續第二個階段所需的經濟資源（客戶肯定你沒有走錯方向，提供資源讓你繼續按照這個思路走下去）。因此，您需要做出戰略決策，為第一階段編寫次優設計。之後，您可以償還債務並在第二個階段之前改進設計。
關鍵是必須*償還債務。您支付的能力取決於程式碼的乾淨程度（因為您需要重構）。
  • 乾淨的程式碼是技術債務的前提。
  • 過度耦合的無法維護的程式碼庫不是技術上的負擔。只是一團糟。

但是，根據精益起步創業（Lean Startup）的方法，這種債務對於創業起步公司幾乎是強制性的。但是正如您所說，對於科技創業公司來說，有必要編寫簡潔的程式碼以償還債務。 
 
對於開發人員無法消除的詛咒是：您只瞭解程式碼，但您卻很少是領域專家，因此當按期限要求時，您會假設有關領域的知識，但是這種第一性假設後來被證明是錯誤的...
 
獲得領域的經驗確實是一個挑戰，並且可以說是構建高質量軟體的關鍵之一。這就是為什麼人們喜歡強調領域域驅動設計（DDD）原因。

經驗分享：乾淨整潔程式碼(clean code)的特點

相關文章