現在有很多開放原始碼的軟體專案。

很多使用者眾多，有巨大商業利益的軟體，都是開放原始碼的。

真的可以在網路上找到原始碼，實際上編譯後也真的能運行，也真的是有很多人共同開發維護的。

所以，對想學習軟體開發人員來說，這是個很好的時代，很多偉大的專案的原始碼可以直接看，不用花錢，只要努力就可以，是嗎？

真的啊，如果不是從某個開源專案早期就一起參與討論的協作者，一個單純只有語言工具基本知識經驗的工程師，要看懂一個系統，那是很困難的。

就好比比特幣的程式碼，看起來是用C語言寫的。

那個源代碼有好多檔案，很龐大的目錄結構。

隨便打開一個檔案，裡面的宣告和函式，傻蛋大致是勉強能看懂。

但整個專案是怎麼運作的，這個專案的程式功能如何組合起來協同運作的，傻蛋還真的是完全看不懂。

呼叫函式，要跳出去看，東跳跳西跳跳，繞都繞暈了，並不是堅持從第一個檔案一路讀到最後一個檔案每一行代碼與註解都仔細閱讀就能學會這個系統是怎麼設計出來的。

就有點像，每個字都看得懂，但一個句子或整段文章是什麼意思卻完全不能理解的那種感覺吧。

其實這是很正常的。

別說是大型開源專案。

就算是企業內部的舊系統維護也差不多。

沒人教沒人可以問，直接看程式碼，要能快速掌握的難度也是很大。

類似的原因吧。

要不，就是程式碼很長很長看得很噁心，要不，就是程式檔案數量很多，跳來跳去的，眼花撩亂。

想理解一個系統，直接去看原始碼，往往不是好主意。

傻蛋的經驗是，先當成使用者，去從各方面去使用這個系統。

先具體的了解這個系統的用途。

然後，再看看有沒有數據庫或資料檔案。

進一步看系統的最終結果紀錄的格式。

先把上述兩者摸熟後再來嘗試閱讀程式碼。

程式的入口在哪裡，主流程是在哪裡，各項功能如何被整合進去，就需要一步一步慢慢地解謎。

運氣好，碰到思考習慣比較直接的系統設計師做的設計，會比較好猜。

運氣不好，碰到思考習慣比較扭曲奇怪的人做的設計，就會發現用各種匪夷所思的方式達成明明很簡單的目的。

假如對系統的外在行為與實際狀態結果沒有預先的熟悉掌握，要直接看程式碼就看懂這個系統怎麼設計，與應該怎麼修改維護，通常都很困難。

當然也有例外。

那就是很簡單的系統。

功能很少很簡單的系統，如果又套用了那個什麼MVC的設計模式，那麼系統的設計會比較好猜。

不過那種設計只能做做簡單網站，把細緻的業務需求加進去就面目全非了。

不是改到坑坑洞洞難以理解，就是維持簡單，但用很多個簡單的系統來實現實務的需要，可以簡稱微服務架構啦，但實際上，就是那些獨立簡單的系統之間的關聯會變得很複雜，複雜到不知道從哪裡看起哪裡查起那樣。

當然，程式設計得難以理解也是有作用的。

那就是程式碼外洩的時候，駭客大概也不會想去研究，這還是有意義的。

如果把系統的架構設計得條理分明，層次清楚，把意圖展現得很直接，與系統程式的結構直接做良好的配對，那樣程式碼外流時要破解與侵入的難度就會大幅降低了。

這種玉石俱焚的策略，是給自己找麻煩吧。

所以？

軟體工程這門專業學問，其核心就是如何讓系統規模增長的時候，複雜度不要失控而已。

最關鍵的就是不要讓複雜度失控。

所以最重要的就是，保持簡單，用良好的分類組織結構來實現實務的複雜需求，代碼最好很容易就能理解，頂多是需要對外曝光時需要醜化一下那樣而已，內部的程式碼，一定是可讀性，易理解性最重要的。

只要程式碼能夠隱藏意圖，就會很難懂，如果讓意圖變得很明顯，就會相對容易理解了。

那麼，開源的程式碼，普遍是怎樣？

難懂的是正常的。

作者沒有義務教其他人學習程式設計，作者只是需要完成任務得到成就感而已吧？

刻意複雜的設計反而會讓人不明覺厲。

當然，經驗也是很重要。

如果你曾經參與過類似的系統開發設計，那對其他人來說是天書的程式碼結構，對你來說就增加很多線索，會比較容易掌握其設計理念，畢竟，臭味相投吧。

理解一個系統，必須能從頭到尾的理解，一開始可能很難上手，有時候那個入口真的藏得很神奇，就是找不到。

通常只能設中斷點，然後一步一步執行，看程式是怎麼流的。

碰到事件驅動有複雜使用者交互的系統程式，要做這件事就會更加困難與費工。

常常會跳函數呼叫跳到一個天旋地轉還不知道到底幹了什麼有意義的事那樣。

沒辦法，雷很多，有時候主要流程與需求之外會有其他考量，產生許多可有可無的需求，不做的影響可能很微妙，但要做，可能需要的系統流程與對應的代碼，會壓過主要的流程，追蹤了大半天，還搞不清楚這是在幹啥的，因為幹的事可能本來就是基於某些設計師自己的考量才需要有那樣的功能。

又或是功力半瓶水的系統設計師要炫技，刻意使用某些被認為是厲害的技巧，在其實沒有需要的簡單需求情境上頭。

明明很簡單的需求，只要多套上幾個不需要不適切的設計模式，就可以變得玄乎玄乎，把原本那個簡單的意圖給藏得深深的。

傻蛋個人的體驗是，人性似乎是傾向於製造複雜的。

很多人不喜歡單調，於是會用點心思讓事情變得豐富一點那樣。

這樣的心態的軟體工程師，如果不受到嚴格的標準規範，就會大幅無謂的增加軟體系統的複雜度。

一個人一點點，每個人的語言與認知又有落差，規模大參與者多那個複雜度的累積速度就很容易失控。

而工程師文化不一定在乎複雜度的治理。

有的工程師，會認為新技術，更酷炫的技術就是好東西。

用更多更新更好的技巧就是專業。

目的是為了證明自己的聰明優秀，而不是讓系統容易被其他人理解與維護。

所以讀別人的程式碼，常常是痛苦的。

即使對方精通那些什麼Clean Code與Refactor的理論與技巧，只要對方有著熊熊的製造複雜的靈魂，而不是把複雜度治理當成至關緊要的事，那就很容易出現那種，局部與瞬間看起來很優雅，但整體結構卻難以掌握的奇妙情境。

傻蛋寫程式的習慣是，不要隱藏自己的意圖。

直接用註解的方式把實現一個需求的思路都寫下來。

後面的程式就是照上面的思路去組織起來的。

同時把入口與關鍵流程也用註解寫下來。

盡量讓程式凸顯主要流程，次要的流程可以用函數或子行程的形式切出去，避免一段程式主流程被藏在一大堆次要流程裡面，而被誤導而看錯重點。

特別是，想要用特殊的設計，來減少重複的代碼與功能的時候，不把思路蠢蠢的寫下來，並讓程式碼結構與那個思路有清楚配對，很容易就會神奇的完成很複雜的需求，但讓人一頭霧水難以理解的。

但即使是有這樣的原則態度，只要需求一路疊下來，偶爾懶那麼一下，回頭看自己的程式碼，有時候也會對讀者不友善的。

幾百行的程式碼，就是會不好閱讀。

上百甚至上千個沒有容易理解組織結構的程式碼檔案，可以讓人看得頭皮發麻。

真正實用的代碼，傻蛋覺得並不是看起來優雅聰明的代碼，而是能愚蠢的把目的想法充分揭露，只是為了達成目的的簡單代碼。

做軟體系統設計時，思考可以靈活，創意可以飛躍，但還是要為後面維護的人著想啊，讓每個讀代碼的人都得像看偵探小說一樣疑東疑西的才能破解你的謎題，這樣不是吃飽太閒又是甚麼呢？

如果不是從事軟體開發的人，讀這篇文章應該會乾乾乾乾到不行吧。

這也是正常的啊。

就像連這個系統功能與使用都不清楚，直接去看程式碼很難理解是一個道理吧。

所以看不懂有時候是正常合理的，真的啊！