幾個月前的東西，終於有時間整理了。
新系統都是每個人喜歡的，而維護乙個已有系統，對任何人都是挑戰。
完成新系統的過程只有兩件事情需要做：就是分析需求，完成需求。
而維護乙個已有系統，則還需要完成一件事情：明白如何使用手邊的工具完成需求。
應該可以武斷地說，不會有人去喜歡擴充套件乙個不是自己寫的已有的系統的——除非他是為了學習。
但是，世界就是這個樣子的：
1 需求總是推陳出新。
2 市場總是喜歡新的需求。
3 不可能有解決一切的解決方案，解決一切一般也就是什麼都沒解決。
4 作為乙個員工，一般你都會使用別人交給你的工具。
所以，擴充套件就成了幾乎是必修課樣的東西。
擴充套件也有多種辦法，最為徹底的無非就是重寫，或者另乙個徹底的無非就是不做，乙個累死，乙個炒魷魚，都是誘人而又無法選擇的方案。
不開玩笑，那麼擴充套件的首要任務是必須明白自己的工具，這個引擎，究竟哪些地方可以擴充套件，哪些地方不能，擴充套件的代價。
擴充套件一般基於我們的需求，以及對於系統的兩種認知：
對於需求而言，封閉原有的功能（即讓原本的功能無效化）、ui修飾（不改變核心功能的前提下，修飾ui）、以及對原功能的bug進行修正，都是很容易的。這幾個方面都是外在的方面，並不是太嚴重，也容易完成。
相對來說，單一系統的修飾更加容易完成一些。在確定的輸入和輸出上，修改演算法，這也不是太複雜，只要你明白輸入域和輸出域。函式在確定的輸入和輸出域上，只可能獲取到你不希望的結果，而不可能獲取到錯誤的結果。例如，你要修改光照計算的公式，將原有的一張高光圖，使用halflife2的方法，做成法線空間內的多張高光圖。這個相對就容易一些，因為輸入域（light map）和輸出域（顏色空間），沒有質的變化。
然而，仍然需要注意的是：必須確認希望修改的這個系統，其輸出是如何用於其他系統的輸入的。不管三七二十一，一看注釋，ok輸出是這個意思，那麼就對輸出按照自己的意願進行更改——這樣的結果就是看人品了。只有明白了乙個輸出確定對於其他系統有什麼影響，才能明確自己應該在怎樣程度上利用這個輸出。輸入也是一樣，只有明白了它能夠接收其他系統怎樣程度上的輸入，才能夠明白這些輸入是該如何進行修飾。
如果牽扯到對原有系統功能的修改，那麼就複雜了，人家好端端的系統放在那裡，很可能是要跟各種系統發生關係的。就正如現在的mm們對那種從不出軌的男人不抱希望一樣，作為程式設計師，我們很難相信這個世界上所有的引擎是絕對的、完整的、毫無保留的符合設計模式的封裝性原則的。或多或少，設計總會出軌，這就是現實，尤其是遊戲系統，作為一種特殊的系統、中小型的軟體專案型別，它並沒有經受過高強度的考驗，它的設計就更加隨意而符合個人意願，探索占有的比重經常大於理性的分析，需求的把握。
在這種情況下，我們首先需要做的可能就是需要將需要擴充套件的功能分攤到若干個系統中，對於這些系統，確認每個系統所佔的具體工作，以及這些具體工作需要修改，以及帶來或者取消哪些輸入和輸出。之後的問題就恢復到了對於每個系統，在確定的輸入和輸出下，完成新的這些功能。
例如，我們如何使乙個不支援動態載入的系統支援這個特性呢？道理大家都清楚：接管資源的建立（資源模組），以及資源使用時通知資源的排程（使用模組）。然後，剩下的問題就可以在這兩個模組裡面解決掉了。
說了半天，像是廢話一樣，其實就想表達乙個意思：擴充套件其實並不是太複雜的工作，或者說，起碼，求證乙個系統是否便於擴充套件，並不是太複雜的東西，沒必要害怕。
與其求著人給你什麼什麼，不如自己去幫助人家完成這些工作。
當然，如果別人都說自己要做了，那你也就別搶了，呵呵。
django擴充套件已有模型的字段
有時，我們需要擴充套件model的filed，比如想為每條記錄都附加乙個字段。我們可以使用模型自定義方法及python的內建函式property來實現。1.定義模型如下 其中自定義的 get section方法返回confitem的外來鍵的外來鍵。2.修改檢視admin.py中以顯示這個新字段 3....
Go基礎之物件導向（擴充套件已有型別篇）
方法一 定義別名 使用別名對已有型別進行擴充套件 用別名 queue 擴充套件原型別int，為其增加push pop isempty 方法 type queue int func q queue pop int func q queue isempty bool 驗證 func main q.pus...
記一次 已有nginx擴充套件 https功能
背景 在用的nginx 僅支援http 功能，需要擴充套件 https 功能。openssl 是乙個強大的安全套接字層密碼庫，囊括主要的密碼演算法 常用的金鑰和證書封裝管理功能及ssl協議，並提供豐富的應用程式供測試或其它目的使用。nginx不僅支援http協議，還支援https 即在ssl協議上傳...