《軟體方法》上冊第2版推薦序

按：終於出版了!,只有潘老師會讓我這種小公司、非大牛寫推薦序，真是受寵若驚。

為了出版，老師壓縮了篇幅，並把標題改成了《一個人的軟體方法》。但其實言過其實了，再小的工程顯然也不是我一個人能幹出來的，少不了全公司大家努力。

我只是在開發環節，個別只剩我一個人的時候，做了一點微小的工作而已。

現在把我的原稿放出來。

軟體方法的力量。

——一個野路子程序員的1年升級之路。

我是個半吊子開發者。

在學校呆了很久，學的是現在大熱的模式識別、機器學習方向（叫AI或者大數據在當時是要被鄙視的），雖然總算精疲力盡地畢業了，但是確定自己不是搞研究的料，也不想做「本行」了。

於是想改個行，決定把自己之前將近十多年的興趣兵棋推演當成事業做，就投奔了當年的玩友，在一個微型公司給軍隊做軟硬體技術服務，找我來就是想給軍隊開發兵棋推演系統。

微型嘛，原來的1個兼職開發人員走掉後，我正好快畢業了，就先兼職，後全職，頻繁離職的應屆生除外，經常只有我1個人負責開發。

本來以為自己對這個業務場景熟悉得不得了，而且在學校也寫過不少代碼，應該很容易就「寫出來」，但事與願違。

註：在學校期間，用C++寫工業機器人操作控制語言（一種領域特定語言）的語法解析器；用matlab，R寫圖像目標歸類，語音分類演算法；用python寫集成了指紋，圖像，錄音的身份特徵數據採集工具；還部署演算法到MPI集群，移植演算法到gpu（那時候還沒有那麼多開源庫，只能自己用cuda自己寫）。當時自認為自己知識水平提得夠高了，什麼樣的複雜演算法我沒有見過，我和他們談笑風生……

然而，幹了一段時間，突然發現事情並不簡單。

自己費力寫了半天，只是寫出了一些要麼不能運行，要麼湊在一起硬運行起來只是「像個系統」，而且極其難修改調試的東西。

現在看來，自己之前在學校寫過的那些，都不能叫軟體系統，只能叫代碼，函數集合，頂多算工具。輸入輸出關係都是定義得非常清楚的（比如圖像->圖像中物體類別），複雜性只是在內部實現而已。

其實在軟體開發方面：自己既沒吃過豬肉，也沒見過豬跑。

本來有點干不下去了，像乾脆放棄，捏著鼻子轉行回到正在大熱的本行算了。但公司極力挽留，讓我不勝惶恐。

我雖然留了下來，但是，接下來的階段，應該怎麼才能改變自己在開發方面一窮二白的落後面貌呢（技能點該先點什麼？）聽說比程序員水平高的頭銜叫架構師，那假設自己是架構師，不是程序員，該有什麼視角，什麼能力呢？

從思想到行動上儘快改進自己的軟體開發能力，是剛需。

我就是在這種狀態下，通過知乎上的《UML八大誤解》吧（https://www.zhihu.com/question/23569835）第一次了解到潘老師和他的「建模」思想，時間是在2016年4月。

當時感覺裡面說的「唱曲的名家，唱到極快之處，吐字依然乾淨利落」就是我想達到的目標。然後就去UMLChina上看軟體方法網頁版和答疑。雖然老師說上冊出版的較早，讓看網頁版的，我還是買了個硬皮版的（對下決心看完的書，我都是買紙質的，有動力看完，然後在上面做註記方便。）到7月，正好在北京的周末全程實作課，就報了名。

正好，當時手頭還有個給軍校的小系統在開發，其實已經在原型階段折騰快2年時間了。但是由於雙方對需求工作流都沒有認識，對軟體的責任邊界沒有清晰明確的認識，導致反覆折騰。好在溝通與demo系統開發也就是折騰我一個人，沒有連累更多人（但來回炮製各種文檔還是要大家幫忙了。）

而看完《軟體方法》上冊，學習了全程實作過之後，我開始有意識用書里的需求啟發思路和提問方式和甲方溝通。而且確實發現了涉眾往往會做而不會定義；把不同類型的涉眾（車間主任和工人）放在一起訪談的問題和書里說的一模一樣：只會剩下在場軍銜最高那個人的意見……

此外，通過刻意關注涉眾利益，也能讓需求更清晰更高效率地被發掘出來。比如教員負責給很多期短訓班學員布置作業，發輔導通知。

一次，看了原型的全過程演示之後，甲方對學員的登錄方式提出了意見：

軍校教員（甲方）：「學員的登錄名，每次要教員自己在excel里拖拽編一個唯一的這個不行，為什麼不能用他的姓名？」

我（乙方）：「因為ID要保證唯一性啊！」

甲方：「那用他住的宿舍房間號可以嗎？學員在培訓期間都是每人住單獨一間宿舍，可以保證唯一性。」

乙方：「這樣單次短訓班沒問題，但是」（翻看之前訪談記錄）「好像每年都要有多次，而且希望保存歷年學員身份和作業？那樣同一個房間就會被多個不同班次的學員使用啊。」

甲方：「噢。這樣啊——」（若有所思）「但是，還是不能每次給他編一個班級內的序號。」

乙方：「為什麼不願意用這個ID呢？只要課前告訴每個人就可以了啊。」

甲方：「不行。那樣教員就太麻煩了。」

乙方：「為什麼呢？到底麻煩在哪裡呢？」

甲方：「每期學員很多，而且高級軍官年級都不小了，每次總有一些人不熟悉電腦，如果有1/10的人總是忘用戶名，密碼，總是來問教員，教員會不勝其煩的。」

乙方：「原來是這樣！」（這就是傳說中的涉眾利益吧？如果不問這麼細，差點溜走。但是實現方面還是要保證唯一性的啊，這是想起來了《軟體方法》里需求規約里取款機密碼位數那段，嗯，肯定要折中一下。）「那麼這樣行么：用年份+班次+房間號構造用戶名，這樣學員想到年份，自己的班次和自己的房間，就能想起用戶名，因為宿舍每班每次只住1個人，這樣用戶名是能保證唯一性的。而密碼用他的手機號後六位就可以。」

甲方：「嗯，這樣可以。」

當然，這只是和甲方溝通的一次中的一個需求片段而已，每次大概都有10幾條的這樣的需求。而之前因為沒有關注涉眾利益，往往反覆推翻、再改動。

在這樣刻意關注涉眾利益之後，神奇的效果出現了：溝通效率和改動質量明顯提升，改一個是一個，即使時隔一段時間，演示的時候涉眾已經忘記了自己之前的想法，但是只要從當初記錄下的他親口說出來的涉眾利益角度稍微一提，涉眾就會立刻想起來，而且很容易認賬，「對對對」成了口頭語，而且這時對軟體的功能越來越滿意，改動漸漸就沒有了。

有了這小項目從原地打轉到圓滿解決的牛刀小試，我又在報名了不定期的在線《領域建模高階》課程，到了2016年底，正好一個真正的推演系統項目來了。由於項目涉密，具體項目細節就略去了。

我這次正好跟著課程推進從尋找老大、揣摩願景、業務建模、系統用例，需求規約，分析模型，設計開發。。。

學的基本都用上了，包括自己用ea，但不妨礙給甲方炮製文檔（之前曾經有很大的抵觸情緒，認為焦頭爛額的情況下，炮製完全無用的文檔是浪費時間，但現在知道了，這種文檔也是交付產品的重要部分。很可能在甲方眼裡這些文檔的重要性還要更高些。）

整個2017年上半年，就是在這樣邊學邊乾的緊張狀態里渡過的，這次要是再砸了就真沒退路了。好在，扛下來了，對甲方，對公司，對自己，都算是有了個交代。

——自己在離開校門2年後，也算是在北京這個已經感覺陌生的城市，終於站住腳了。

而離學習軟體方法，才僅僅過去1年。

現在回顧一下最大的挑戰是：不但甲方涉眾有知識障，我自己的知識障也很大。恰恰因為自己玩了很久兵棋推演，又很有興趣，所以自認為自己很熟悉。要用智子法自己強迫忘掉的，不止是軟體開發部分，還有業務和需求部分。

然後是：要習慣當孤獨的少數派。在邊干邊學，我對軟體方法的掌握和理解不斷加深，也漸漸和甲方，和公司內部的領導和市場，和同事，經常意見不合。特別是進度緊的時候，我還在不斷重構系統的核心域模型，改進結果頂多是控制台上的文字滾屏，而不是美化甲方看得見摸得著的界面。 但是，在這種「敵人炮火最猛烈的時候"，我始終記著《軟體方法》里潘老師對核心域的話：「只有一個領域（核心域）的知識是系統能在市場上生存的理由」。即使別人都認識不到，我也必須保證我不斷強迫思考，找准核心域。然後就要感覺像是狗看骨頭一樣，死死地守住它的邊界。

而最大的收穫，不只是開發能力和效率提高方法論層面的提升，更是世界觀的改變和開悟。貫穿書中的一組最重要的概念是「需求 VS 設計」。真正在實踐過程中用不同的思考帽體會了這兩個概念的區別於聯繫後。一下就理解了很多軍事領域原來沒理解的概念（領域知識的書很多講得也不太清楚）：戰略VS戰役；決心VS方案; 籌劃VS行動；決策VS控制；而習慣了體會責任的分配與流轉，也能對很多聽起來唬人的噱頭有了自己的獨立看法：1個合成營真得指揮得動下面15個不同兵種的連嗎，作為控制類的營部責任這麼重，得有多少人？從核心域透鏡的角度，作戰和裝備領域，誰應該說"信火一體"（信息與火力），誰應該說「察打一體」（偵察與打擊），動詞和名詞的背後，可能體現的是他們的系統表達更像狀態機圖還是活動圖？

以上，就是我自己的1年來的親身感受。

我覺得，軟體開發其實也不需要讀很多理論的書，因為還有讀源碼+實際工作經驗呢。就像古代培養武將，是讀《孫子兵法》加戰史戰例，然後就是從實戰中鍛煉選拔，不需要武人讀很多書。雖然《孫子兵法》字很少，但是卻涵蓋了軍事領域之外的政治（業務建模），從國家角度對軍事系統提了什麼需求（兵貴勝,不貴久），然後才是軍事領域應該封裝什麼核心域概念（形與勢），然後是其他支持子域（地形，火攻，用間）。涵蓋了那個年代用兵的整個工作流。

現在每個工作流也都有很多經典著作了，以外國人寫的居多。軟體開發作為一個行業，也有幾十年了，也應該有一部《孫子兵法》出現了。

《軟體方法》至少應該能算是候選之一。

——許慶晗（工學博士 兵棋開發者） 20171011 00:56

對推演系統開發，作戰指揮感興趣的，歡迎交流

[email protected]