《領域驅動設計：軟體核心複雜性應對之道（修訂版）》—第1章 1.3節持續學習

本節書摘來自異步社群《領域驅動設計：軟體核心複雜性應對之道（修訂版）》一書中的第1章，第1.3節持續學習，作者【美】埃裡克•埃文斯（eric evans）, 馬利偉 , 萬龍，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

1.3　持續學習

當開始編寫軟體時，其實我們所知甚少。項目知識零散地分散在很多人和文檔中，其中夾雜着其他一些無關資訊，是以我們甚至不知道哪些知識是真正需要的知識。看起來沒什麼技術難度的領域很可能是一種錯覺——我們并沒意識到不知道的東西究竟有多少。這種無知往往會導緻我們做出錯誤的假設。

同時，所有項目都會丢失知識。已經學到了一些知識的人可能幹别的事去了。團隊可能由于重組而被拆散，這導緻知識又重新分散開。被外包出去的關鍵子系統可能隻交回了代碼，而不會将知識傳遞回來。而且當使用典型的設計方法時，代碼和文檔不會以一種有用的形式表示出這些來之不易的知識，是以一旦由于某種原因人們沒有口頭傳遞知識，那麼知識就丢失了。

15

高效率的團隊需要有意識地積累知識，并持續學習[kerievsky 2003]。對于開發人員來說，這意味着既要完善技術知識，也要培養一般的領域模組化技巧（如本書中所講的那些技巧）。但這也包括認真學習他們正在從事的特定領域的知識。

那些善于自學的團隊成員會成為團隊的中堅力量，涉及最關鍵領域的開發任務要靠他們來攻克（有關這方面的更多内容，參見第15章）。這個核心團隊頭腦中積累的知識使他們成為更高效的知識消化者。

讀到這裡，請先停一下來問自己一個問題。你是否學到了一些pcb設計知識？雖然這個示例隻對該領域作了些表面處理，但當讨論領域模型時，仍會學到一些知識。我學習了大量知識，但并沒有學習如何成為一名pcb工程師，因為這不是我的目的。我的目的是學會與pcb專家溝通，了解與應用有關的主要概念，并學會檢查所建構的内容是否合理。

事實上，我們的團隊最終發現探針仿真并不是一項重要的開發任務，是以最後徹底放棄了這個功能。連同它一起删除的還有模型中的一些部分，這些部分隻是幫助我們了解如何通過元件推動信号以及如何計算跳數。這樣，應用程式的核心就轉移到了别處，而且模型也随之改變，将新的重點作為核心。在這個過程中，領域專家們也學到了很多東西，而且更加清楚地了解了應用程式的目标（第15章會更深入地讨論這些問題）。

盡管如此，那些早期工作還是非常重要的。關鍵的模型元素被保留下來，而更重要的是，早期工作啟動了知識消化的過程，這使得所有後續工作更加高效：團隊成員、開發人員和領域專家等都學到了知識，他們開始使用一種公共的語言，而且形成了貫穿整個實作過程的回報閉環。這樣，一個發現之旅悄然開始了。