《三國演義》中濃墨重彩描述的大多是武將的勇力以及謀士的計策和辯才。花筆墨稱讚陣法精妙、器械發明奇巧的寥寥可數。但若是能進入篇章的，就一定是驚世之作。令人印象深刻的有曹仁的八門金鎖陣、諸葛亮的八卦陣、劉曄的霹靂車以及諸葛亮後期發明諸葛弩和木牛流馬。其中八卦陣被吹噓的神乎其神，甚至劉備兵敗後，諸葛亮用幾塊破石頭布個陣就差點整死陸遜。

演義中的邏輯破綻很多，八卦陣真有這麼神奇，諸葛亮只要在蜀國各處咽喉都用石頭擺個陣，不就可以輕鬆搞定國家防禦？諸葛弩如果那麼牛B，乾脆每人一把，兩軍交戰立馬打機關槍一樣“突突突”，還不瞬間統一三國？稍加推敲立刻破綻百出。古往今來沒有一樣東西可以亙古不變，管理學中有一句話說的特別好“唯一不變的就是變化”。然而，在軟體設計與開發中，我們常常違背規律地尋找著“八卦陣”和“諸葛弩”。

在教學和開發過程中，我常常會聽到學生或有人談論這些問題：“哪種語言最好？”，“我應當學什麼語言？”，“用SSH架構把”，“這個專案一定要用XXX框架”。我的回答是：任何開發語言都一樣，沒有最好的語言，只有最適合某一專案的語言；任何語言的思想都一樣，思想是內功、語言是招式；框架如果能幫助快速開發和提高可維護性就用，否則棄之。作為一個專案管理者而言，任何一個專案的本質思考順序應該是：經費、維護、功能、效能。

首先是經費，“不以盈利為目的的企業都是在耍流氓”。一個專案如果只有十萬的經費，你TM又要用ORACLE，又要負載均衡，又要跨平臺，你不是找茬是幹什麼？這就好比1塊錢買了個包子，質問老闆餡裡面為什麼沒有鮑魚海蔘一樣可笑。本文重點不在此，略過不提，關鍵談談八卦陣和諸葛弩給我的啟示。

1. 八卦陣與系統框架

   陣法在很多地方和系統框架非常相似。每個人在陣法中都有特定的位置，需要做指定的動作，就好像採用了某種框架後，需要按特定的方式進行程式設計一樣。曾經很長一段時間，我都在思考，如何把24設計模式好好地用到專案中；如何把structs2作為團隊開發必須遵守的準則；如何在專案中用好SSH。結果發現一件可悲的事情，框架越高階，維護成本越高，而且隨著時間的推移，人員的變動，專案的維護越來越無法持續。

   這就好比八卦陣，縱觀整本《三國演義》，懂這個陣法的人有那麼幾個，但只有諸葛亮一個人能用好。這就好比公司裡有一個巨牛無比的技術大拿，設計了一套巨牛無比的框架，然後訓練公司的一群技術小兵通過框架開發專案。技術小兵上手快，開發簡單，往往一行程式碼就可以實現高階功能，開發出來的專案無論在穩定性還是效能效率方面也都異常出色。但如果需求有變動，框架級的修改只有這個大拿才有能力改的了。作為公司的老大，你敢用這個框架嗎？如果是一錘子買賣的專案，我會用。但是核心專案，我肯定是不敢。因為大拿會跳槽，會生病，會請假，會出各種各樣的意外。一旦大拿不在，關係到公司命運的核心專案就會垮掉。作為專案經理，我要的是所有技術人員都能進行程式碼的維護，或至少在不超過

   1個月的培訓後，能夠對專案的程式碼進行維護。太複雜、維護成本太高的框架我會直接無視。這就好比，諸葛亮五丈原身死之後，《三國演義》中再也沒有出現八卦陣一樣。

   這方面血的教訓很多，特別是做管理資訊系統，一個領導一個想法，一個領導一個需求。曾經有一個鐵路系統的集中監控系統，頂層設計和請了一個巨牛無比的技術大拿來做，設計了一個非同步的4層結構，跟蹤一個訊息兜兜轉轉十幾個類檔案跳躍，導致後期根本無法維護。結果推倒重來，用最簡單的方法進行序列設計，效能下降很多，但整個專案維護使用了7年。

   所以，我現在的一個準則是：只有在70%的技術成員都能掌握某一框架的時候，才能利用這個框架進行開發。

   相比"八卦陣"，我更喜歡"諸葛弩"。

2. 諸葛弩與控制元件和呼叫介面

   如果把陣法比作系統框架，諸葛弩就像是封裝好了的控制元件或功能介面，功能單一（快速射箭），操作簡單（扣動扳機即可）。我不需要知道這個功能是怎麼實現的，只管知道怎麼去用就好。

   而在使用框架時，往往會碰到過度設計的問題。好比我需要一把拖把，控制元件就是提供了一把成形拖把，我只要拿他去拖地就好。而過度設計時，提供的則是：木棍類、布類、鐵絲類，需要程式設計師再去把木棍、布、鐵絲組裝成一把拖把。然後還興致勃勃地誇耀，這個木棍類還可以用在掃把功能上；布類甚至可以單獨成為一個抹布功能。對於這種設計，我只想說“去你大爺的”。

   所以，在大多數專案中，我都會要求專案teamleader做好功能封裝，最好能封裝成特定功能的控制元件。只要告訴呼叫者方法名是什麼，需要傳什麼引數即可。同時，儘量結構簡單，能不自定義類的儘量不自定義類。為的就是所有人都能對程式碼進行維護。專案的可維護性高於一切！