關於軟體設計的文章，透過一個故事來探討了軟體設計中的一些核心理念，特別是關於知識構建和軟體維護的問題。以下是文章的主要內容概述：
背景
ORG公司依賴於一個整合服務SaaS來解耦其業務邏輯和供應商軟體。
ORG公司從無限預算模式轉變為需要在明年實現收支平衡的模式。
分析師注意到ORG在SaaS上的花費異常高。
一位高管認為，既然公司已經在軟體工程師上投入了大量資金，他們應該能夠用內部開發的系統SVC來替代SaaS。
工程師X10被指派去構建SVC，並且按時完成了任務。
SVC投入使用後，工程師X10離開了ORG公司，工程隊TEAM接管了SVC。
隨著需求變化和未知問題的暴露，TEAM在交付上表現糟糕，無法有效地進行更改。
TEAM被重組為TEAM++，但問題依舊。
分析
David Parnas的《Software Aging》論文警告說不應該讓沒有參與設計的開發者去修改軟體，因為這會導致軟體結構退化。
Peter Naur在《Programming as Theory Building》中提出，程式設計應該被視為一種理論構建活動，程式設計師需要對程式有一個理論模型。
Naur定義了軟體設計為一種智力活動，包括構建和擁有理論，理論是一個人必須擁有的知識，以便不僅智慧地執行某些事情，而且能夠解釋它們、回答有關它們的問題、爭論它們等。
原因
- TEAM無法接管SVC，因為工程師X10離開時帶走了開發背景（上下文）和心智模型，系統隨之退化。
- Naur認為，程式的死亡發生在擁有其理論的程式設計師團隊解散時。一個死亡的程式可能繼續在計算機上執行併產生有用的結果，但當對程式的修改需求無法得到智慧回答時，死亡狀態變得明顯。
- 我們應該以一種方式進行軟體開發，以便未來的維護者能夠從昏迷中喚醒專案。
因此，下次您選擇一個名稱，或構建一個專案，或思考是否要寫或省略某條評論時，不要從未來維護者的負擔的角度來思考，而是想想：這個決定會對他們建立系統、業務和世界的心理模型有多大影響——有多大幫助或阻礙。
軟體開發不僅僅是編寫程式碼，而是構建和維護一個關於系統、業務和世界的知識體系。這對於未來的維護者來說至關重要，因為他們需要構建對系統的心智模型。因此我們在命名、專案結構、註釋等方面考慮這些因素，以幫助未來的維護者更好地理解系統。
重寫：
- 開發人員可能傾向於重寫程式碼，因為新的程式碼可以從頭開始設計，沒有歷史包袱，看起來更“乾淨”。
- 然而，重寫程式碼是一個高風險的決策，因為它需要大量的時間和資源，而且成功率並不總是有保證。
- 有時候，開發人員可能高估了原始程式碼的複雜性，而低估了重寫過程中可能引入的新複雜性。
- 原始程式碼可能包含了許多未文件化的業務邏輯和領域知識，這些在重寫過程中可能會丟失。
重構：
- 維護和改進現有系統確實可能比從頭開始編寫新程式碼更具挑戰性，因為它需要深入理解現有程式碼和業務邏輯。
- 但是，如果維護得當，現有系統可以透過漸進式的改進來適應新的需求，而不必完全重寫。
重寫好於重構：
- 重寫能重新培訓新團隊的知識構建，本文提出新團隊接手一個遺留專案失敗，關鍵是新團隊不瞭解老團隊的知識模型，那麼就讓新團隊把這個遺留專案作為學習訓練專案，同時引入更大的業務知識背景，因為新情況出現了。
- 重寫雖然會引入新風險因素，但是修改一個bug還會引入更多bug，不能畏懼不前行，世界上不存在沒有bug的軟體
- 新複雜性引入也是不用畏懼的，編寫軟體本身就是與複雜性鬥爭的過程。