開源開發，就我的理解，有三種。

1、當作底層基礎，使用。例如大家使用mysql就算。有人會認為我說錯了。但我認為，開發不代表就是要同一個語言，甚至修改代碼。例如我們使用動態庫，原先的動態庫是什么寫的并不重要。重要的是作為自己的組成部分。你即便用mysql的接口甚至命令，去實現系統，也算是二次開發。

2、作為參考設計，這通常是在針對標準的實現上。這類代碼，本身最大的價值是作為一個對比版本，檢驗自身的代碼的正確性使用。如果都打算推倒重寫了，要么原先代碼很爛無法實用化，要么你的目標任務更明確，針對特定任務類型，你有更好的求解方式。

3、作為整體，局部修改，或引出新的分支。這類情況前者很常見，后者不常見。但通常更有意義的在于你的修改能符合規范并且納入版本中，因為一旦開源代碼的版本調整，而你只是修改而自行發布，這產生了統一和分裂的矛盾。主要功能希望統一，但代碼實現存在分裂。

針對上述三種不同的情況，對代碼的使用和學習分以下幾種方式：

1、代碼不看，或最多在實際應用中去局部理解，主要是為了更好的了解開源的底層是規模和情況，便于你的系統確定目標范圍。

2、代碼需要看，但以理解為主，主要是針對函數的目標進行理解，而不是針對函數內部實現進行理解。

3、這個比較痛苦，需要對函數內的代碼進行理解，特別是跨模塊（C文件作用域）的變量，函數的理解。

你要先搞清楚，你打算干什么才能針對目標進行不同模式的開源處理。

以上三種方式我都折騰過。但方法還是不太一樣。

?

對于第一種方式我就不說了，很簡單你去用就行了。如同你怎么學mysql就怎么來。下面說下后面兩種方法的不同。

舉例：

重寫代碼。我折騰過兩套系統（都是好幾年前的故事），1套是JM系列和X264系列，針對H264標準，而出的代碼，前者不算真正開源，后者算。另一套，是國家標準AVS，有個類JM的代碼。曾經罵JM的代碼有多爛，看了國家標準AVS的參考代碼，才知道什么叫學生水平（我甚至懷疑就是國內的普通沒有代碼設計能力的非專業程序員級別的研究生寫的）

這類開源的代碼理解，是通過輸入輸出數據，在運行態下，分析代碼。

另一類，是我目前在做的，對GIT的代碼的二次開發。但是這類，我暫且不會考慮對GIT的后續版本的統一問題。因為我的目標是多文件，多用戶權限的分布式版本管理系統的開發，而GIT對多權限貌似支持并不好。所以我也無法統一，這是沒有辦法的辦法。對這類的二次開發，確實比較痛苦，主要是針對獨立的行為的一一理解和分析 。

對代碼的理解，也是反復調整局部變量或結構，以判斷實際效果的方式來處理。理解代碼后，后續的工作是，逐步替換內部模塊，或者改變內部模塊的調用邏輯，來實現新的功能。

特別針對第三種的開發，個人建議不要重新列個工程，對已經識別和分析清楚的模塊整體轉入到新的工程中去。用我平時說的非常多的一句來形容，也就是說：

”不要嘗試用理想改變現實，盡可能的通過現實實現理想“