2010冬遊日本關西Day2-D梅田空中庭園展望台

February 25 08:55~11:00

離開大阪港之後，按照行程表接下來應該是要去「WTC宇宙大廈展望台」與「梅田空中庭園展望台」。因為晚上還要搭火車趕到奈良怕時間不夠，而且這兩個景點都是「展望台」，跟Kay討論過後決定跳過「WTC宇宙大廈展望台」，直奔「梅田空中庭園展望台」。

「展望台」顧名思義應該是那種很高、很高，的建築，遠遠就可以看的到，沒想到為了找這個「梅田空中庭園展望台」，繞了好久，問了兩個日本警察，好不容易才找到。

在背包客棧網站有一篇文章介紹要如何從御堂筋線梅田站走到「梅田空中庭園展望台」，借用一下上面的一張google map地圖看了就知道。

「翻拍」自http://www.backpackers.com.tw/forum/showthread.php?t=51315

 

雖然背包客棧這篇文章是2007年就發表，但是2010年去玩的時候並沒有讀到這篇文章，一出梅田站後傻眼，人好多。

 

離開地鐵站，看到的是。

 

靠著極不清楚的指標，iPhone4電子羅盤，兩位非常熱心但卻雞同鴨講的日本警察，以及Kay的方向感，先經過一個看起來有點高級的地下道。

 

然後來到一個很長、很長又有點陽春的地下道，有種越走越荒涼的感覺。

 

沒想到一出地下道，附近的景色和梅田站完全不一樣，有種來到重劃區的感覺，看來就是這一棟大樓了。

 

 

人還滿多的

 

居然還有旋轉木馬。

 

還有在賣一些有的沒的。

 

走近一看，這個空中展望台是聯結兩棟大樓而形成的，滿特別的。

 

到日本的時候是11月底12月初，到處都可以看到耶誕樹。

 

要準備去觀景台了，看照片應該是要搭電梯到35樓。

 

搭完電梯之後還要搭個長長的電扶梯。

 

終於到了「梅田空中庭園展望台」，地方還滿大的，有一個賣咖啡的店。

 

夜景真的好美，幸好最後有找到。

 

 

 

 

 

展望台內部一角，可以寫下許願的小卡片繫在耶誕樹上，變成白色耶誕樹。

 

由於夜色太美在此站停留過久，要趕快離開趕去奈良了。從這個角度看點燈之後的耶誕樹更美。

 

看到這邊如果細心一點的鄉民們應該會發現一個bug，怎麼沒有吃晚餐的照片呢？ㄟ，其實一來到「梅田空中庭園展望台」大樓的時候Teddy和Kay就在一樓的某家咖啡廳吃晚餐了，但是由於走的太累了，根本沒心情拍照。再加上日本的咖啡廳有一個缺點，室內是可以吸菸的。雖然有區分吸菸區與非吸菸區，但是並沒有把吸菸區單獨隔間，所以整個空間都是煙味。Teddy和Kay快速用餐完畢之後就趕快逃離案發現場。

關於咖啡廳室內可以吸菸這一點，台灣終於贏了日本，讓出門在外的Teddy內心湧起一絲小小的驕傲。

***

友藏內心獨白：這個Day2怎麼還沒結束啊。

如何測試Singleton（3）

February 23 14:09~

在第二集中提到下列五種不加入reset()便可測試原本WidgetFactoryV1這個Singleton的方法，今天要把這個問題做一個結尾。

• 每次執行單一測試案例（test method）時啟動一個新的JVM
• 利用Reflection或是MockObject工具重設mFactory為null
• 利用繼承
• 使用Nested Classes
• 在分散式持續整合系統（CI）上跑測試案例

除了這五種方法之外，Teddy的另一位學弟（那冒出來的那麼多學弟啊…XD）提出了一個根本的問題：學長，你的程式根本寫錯了啊。看一下學弟所建議的版本：

對照一下之前的版本：

學弟的看法是，原本的WidgetFactoryV1本身結合了Singleton與Simple Factory這兩個patterns，所以讓WidgetFactoryV1的測試變得困難了。應該要把Singleton的責任放到Win32WidgetFactory與MotifyWidgetFactory身上，讓WidgetFactory只負責傳回不同平台的Singleton即可。

所以，只要在測試案例只要寫成這樣就可以了：

 

全部綠燈。

 

學弟還很熱心的寫了一篇文章來回答這個問題，有興趣的鄉民可參考這裡「問答(2) -- Testing simple factory」。

***

程式改成這樣的確是好測很多，但是俗話說，有一好沒兩好，修改過的程式引發一個問題：

把平台判斷的責任丟給client判斷：Client呼叫IWidgetFactory getWidgetFactory(String aPlatform)來得到不同平台的IWidgetFactory實作，這些實作「理論上」在同一的JVM中只會有一個，也就是說你不應該在軟體畫面上同時看到Win32的Widget元件與Modify的Widget元件。修改之後的程式允許用者寫出這樣的程式：

雖然Win32WidgetFactory與MotifWidgetFactorty本身都是Singleton，但是從應用程式的problem domain來看，這兩個Singleton在runtime是彼此互斥的，同一時間只會存在一個。修改之後的程式因為放寬這樣的限制，所以自然也變得比較容易測試了。

***

那如果把程式改成下面這樣呢？

讓Simple Factory（WidgetFactoryV3）自己判斷平台，client必須藉由改變環境變數來得到不同平台的的IWidgetFactory實作。耶，這個做法好像是介於V1與V2版本之間，容易測試但是根本上還是允許client端可以同時得到Win32WidgetFactory與MotifWidgetFactorty，所以還是有著V2版本的問題：

 

最後一個版本：

這個版本跟V1比較像，client端透過WidgetFactoryV4的getWidgetFactory在同一個JVM中只能得到同樣一份IWdigetFactory的實作。寫到這邊有種鬼打牆的感覺，總之Teddy想說的是，這個問題的本質比較像是：

如何測試一個static block，static method或是受final static變數所控制的不同程式路徑。

***

為了這麼一個小不拉機的問題，劈哩啪啦扯了這麼多，好像有點無病呻吟之感，又有一點「用程式繞口令」的味道…Orz。最後回答原本Teddy提出來三個問題的前兩個問題…啊，這麼快就把這三個問題給忘了：

問：到底設計classes的時候，應不應該加上類似reset()這種「為了方便測試而存在的method呢？」

答：這個問題有人贊成也有人反對。贊成的人認為，為了所謂的testability的原因，可以「有條件的」經過深思熟慮之後，在classes裡面加入為了方便測試而存在的methods甚至是nested classes。反對的人認為這種作法會汙染原本classes的介面，可能會導致誤用與誤解（有潔癖的人通常屬於這一類的…XD）。Teddy的看法是，如果有其他的手段，例如可以用reflection或是mock object frameworks來解決不易測試的問題，就儘量避免這種為了測試而存在的methods或是nested classes。如果不行，那麼為了測試理由加入一些methods或是nested classes也尚可接受。Teddy當年在念書的時候，也曾經研究過design for testability的問題，但是因為資質不足，研究了幾個月之後搞不出個鳥來，後來就放棄了…Orz ^ 3。

問：如果應該，那麼要如何避免這些為了測試而存在的methods不小心被其他人誤用？

答：在Java中可以把這種僅供測試使用的methods宣告為只有同一個package的其他classes才存取的到，然後把test cases和待測程式放在同一個package裡面。總之就是想辦法控制一下只有測試程式可以存取到這些僅供測試使用的methods。另外就只能靠寫文件，註解，或是用annotation在程式中標示一下那些methods或是classes是僅供測試使用的。

以上，報告完畢，稍息後不敬禮解散；稍息。

***

友藏內心獨白：有把這系列三集都看完且眼睛沒扭到或抽筋的鄉民們在此幫你們拍拍手。

投影片下載：Scrum框架下的流程改善策略

February 23 16:39~16:55

ezScrum團隊已經公布了三月十號「Scrum軟體開發工具與方法 - 系列講座(六)」的報名網址，活動完全免費（當然鄉民們要自己花錢搭車到活動場所…XD），想參加的鄉民們可以到這裡報名：

 

Teddy負責那個session的投影片可以在「這裡」下載。

***

友藏內心獨白：台北下了一下午的雨。

如何測試Singleton（2）

February 23 10:06~11:38
昨天為了三月十號的「Scrum軟體開發工具與方法 - 系列講座(六)」做了一整天的投影片，整整有快十個小時。活動的報名網址應該過一兩天就會公布了，還有一些細節還沒喬好，等報名網址公布之後再通知鄉民們，以下是當天活動的「Beta 版 搶鮮版」海報，對活動內容有興趣且當天沒有要去吃喜酒的鄉民們可以參考一下（據說當天是農民曆上的好日子，很多人要去參加喜宴…XD）。

***

可能是昨天用腦過度，今天有種腦袋空空的感覺（還是因為吃太飽了，剛剛「不小心」把今天中午的午餐給吃掉了…XD）想來想去今天就談一下上次沒談完的如何測試Singleton這個問題。在「如何測試Singleton（1）」中，Teddy問了三個問題：

1. 到底設計class的時候，應不應該加上類似reset()這種「為了方便測試而存在的method呢？」
2. 如果應該，那麼要如何避免這些為了測試而存在的methods不小心被其他人誤用？
3. 上面這個測試Singleton問題，是否還有其他方法可以在不增加reset() method的情況下達到測試的目的？

今天先討論第3個問題。在搞笑談軟工Facebook社團中有好幾位鄉民們給了Teddy好幾個答案，基本上要讓原本程式（下圖）的測試案例可以順利執行有以下幾種方法（如果忘了原本的問題請把第一集再看一次）。


每次執行單一測試案例（test method）時啟動一個新的JVM
由於每個測試案例都在一個新的JVM環境中執行，所以每次執行Singleton測試案例的時候上途中的12-27行會被執行，便可以藉由設定不同的「widget_platform」環境變數來控制要產生Win32WidgetFactory或是MotifWidgetFactory。但是這個做法有一個缺點，由於每次執行一個測試案例都需要啟動一個新的JVM，所以執行速度會比較慢（路人甲：沒關係，我的電腦速度超快）。

利用Reflection或是MockObject工具重設mFactory為null
Java的Reflection機制可以讓鄉民們存取物件的私有變數，這個方法以前Teddy也有在撰寫單元測試時用過，學弟告訴Teddy「這裡」有一份資料可供參考。另外有一位鄉民告訴Teddy：「PowerMock framework裡的WhiteBox class有個setInternalState可以用來重設mFactory為null」，有興趣的鄉民們可以去試看看這個PowerMock工具 。但是這個方法也有一個缺點，就是如果程式語言沒有提供類似Java的Reflection機制去讀取私有變數的話，那麼這個解法就行不通了。

利用繼承
這也是另一位鄉民提供的答案，如果不想在待測程式身上加上reset()這種為了測試而存在的method，可以用寫一個新的類別來繼承待測程式，並且在這個子類別中實作reset()，然後在測試案例中就改測試這個子類別。但是這樣做必須要把原本mFactory由private改成protected。另外，如果原本的待測程式是設計成不允許繼承的final class的話，這一招也沒轍。

使用Nested Classes
這是由Teddy的另一位學弟所提供的方法，把test case以nested classes的方式寫在待測程式身上，如此一來便可直接存取待測程式的私有變數。缺點是test case跟production code（待測程式）會放一起，但是也有另外一派的人認為這是個優點（情人眼裡出西施嗎…XD）。

在分散式持續整合系統（CI）上跑測試案例
在本地端不要執行這個測試案例，直接丟到CI系統中讓CI系統執行。這個方法乍看之下有點賴皮，自己解不了的問題丟給別人處理，但是有時候這卻也是不得不為之的方法。例如，如果有兩個測試案例真的個別需要產生一個會呼叫到Windows與Linux平台特定系統函數的Singleton物件，那麼四種方法便無法解決此問題。像是Jenkins這種支援分散式持續整合功能的CI系統，可以讓使用者設定，把不同的測試案例分派到不同的slave端執行，如此一來便可解決此問題。但是這個解法也有一個缺點，那就是programmer無法在本地端執行這些測試案例，所以把程式碼commit到CI系統之後才會知道測試案例是否通過。換句話說，programmer可能會送交有bugs的程式到CI系統中。
以上總共提了五種可能的解法，有沒有第六種，有，不過留到下次再說明。最後Teddy還有一件事想說，以上這五個解法的實際內容，如果鄉民們看完之後還是不懂，那也沒關係，反正鄉民精神本來就是來看熱鬧而不是看門道的。重點是，Teddy想傳達一個觀念，從事軟體設計遇到問題時必須要有備案（alternatives）。設計的問題都是所謂的「取捨問題」，很難找到絕對好而沒有任何副作用或是缺點的設計（怎麼覺得跟吃藥一樣）。當遇到問題的時候，如果擁有的備案越多，越容易「在一堆爛蘋果中找到一的比較不爛的」。如果沒有能力找出任何備案，最後可能落得如此的下場：

• 默不吭聲吞下一個無俚頭的解法。
• 皇上聖明，皇上聖明啊…（三天後）…皇上聖明啊…。
• 進化成派大星…呵呵…你不是方褲褲的海綿寶寶（流口水ing）。
• 下一個老闆也許會更好。

***

友藏內心獨白：剛出爐的文章，趁熱快吃。

目標管理，不要吧

February 21 15:22~17:10

記得兩、三年前看過一篇關於目標管理的文章，寫得很棒，剛剛花了點時間找到這篇文章，是Slack (中文版：別讓員工瞎忙)這本書第十八章。這本書Teddy看的是中文版，定價才250台幣，強烈建議各位鄉民們也去買一本來看。

簡而言之，這本書的第十八章告訴鄉民們，不要採用目標管理，因為目標管理只能達到局部最大（最佳）化，而非整體最大化。舉個例子，團隊的bugs太多了，於是聖上定了一個績效指標：產生bugs越少的開發人員，績效越好。

又是生命會找到出路這句老話，大智慧沒有，小聰明一堆的各位鄉民們，腦力激盪一下要如何「無腦減少bugs」。以下Teddy先拋磚引玉提供幾招：

• 不寫程式：所謂「沒有買賣，就沒有殺害，讓我們一起保護鯨豚，大家說好不好…XD」嗯嗯，應該是「沒有程式，就沒有bugs，讓我們一起不寫code，大家說好不好…」。這真是太偉大的發現了，跟無薪假一樣簡直可以得諾貝爾獎了。把禪宗「本來無一物，何處惹塵埃」的精神應用在軟體開發上面，真是令人忍不住想按一個讚。
• 不寫困難的程式：好吧，連一行程式都不寫也說不太過去，那就專門挑那些比較簡單，不容易出錯的工作來做好了。這樣子產生bugs的機率就降低了，績效也變好了。 那困難的程式誰寫？「關我屁事啊，我只負責每個月領錢」。
• 作假帳：每個做生意的人都知道，帳本有兩種，一種是外帳，給國稅局的人看得，讓國稅局的人覺得自己真是好可憐啊，稅就可以少繳一點，最好是可以不用繳稅還可以領補助金。另外一種是內帳，給自己看的，目的是讓自己看了以後今夜作夢也會笑。鄉民們可能會想，這全都是公司逼我的喔，聖上要看美麗的數據，那我就想辦法提供美麗的數據。怎麼提供？和其他開發人員先串通好，有bugs先不要回報，私底下先通知你。另外一種方法就是，打死不承認這是一個bug，或是說這個bug與我無關，都是別人的問題（不是你的錯，也不是我的錯，都是月亮惹的禍。可以把bugs算在月亮頭上嗎…XD）。所以開發人員大部分的時間都不是在寫程式，而是在想辦法撇清關係，以及找替罪羔羊。

實施此制度之後，bugs數量是降低了，公司也倒了…Orz，謝謝再聯絡，下一位。

類似的例子太多了，例如Teddy還在唸書的時候當過一門物件導向分析與設計課程的助教，需要幫學生review設計。作業要求學生必須在class diagram上面標示出使用了那些patterns（老師沒有硬性要求要用多少個patterns），但是既然有了這樣的要求，學生自然把這個要求當成績效指標。所以哩，哇賽，每一個人的class diagram都好精彩啊，各式各樣該出現、不該出現的patterns都跑出來見客，熱鬧程度簡直可以媲美清明上河圖…XD。

學生內心獨白：啊助教你不是想要看很多classes和patterns嗎，我就給你很多classes和patterns啊，誰怕誰啊。

Teddy：是誰告訴你Teddy要看很多classes與patterns？看的Teddy眼睛好累，說好的物件導向設計呢？

學生：物件導向是什麼東東，好吃嗎？

***

還有沒有類似的例子？有。某公司想量測programmer的「生產力」，偉大的「牠」建議：要測量每個programmer每天的LOC（line of code），LOC越多的，生產力愈高。

不要奸笑，Teddy知道鄉民們心裡在想什麼。嘿嘿，這還不簡單，我方只要派出ctrl + c與ctrl + v這兩員大將就搞定了。

啊，甚麼，你說是因為「指標訂得不好」才會這樣。那請問開發軟體要訂哪些指標才算好，留個言教教大家吧。

***

扯了這麼多，到底要如何改善軟體開發生產力與品質？套句Mobile01上鄉民經常講的一句話：請爬文。

Teddy介紹的書多看幾本，還有把搞笑談軟工上面的文章整篇背下來，再不行找Teddy去當顧問，這樣就差不多了。

鄉民內心獨白：人家要免費的答案啦。

Teddy：免費的牛肉要不要？

***

友藏內心獨白：風蕭蕭兮易水寒，Teddy一樣要吃飯。

其實軟體人才很缺…嗎？

February 20 22:32~23:35

最近Kay常常罵Teddy，說Teddy自從買了平板電腦之後，睡前都在看Facebook或是Mobile01，或是連到YouTube看瘋神無雙（這是什麼鬼…XD），都沒有完整把一本書看完。好啊，說Teddy沒把書看完是不是，Teddy就看完一本書給你看。在前幾天就利用睡前花了兩天把「約耳續談軟體」中文版給看完了。嘿嘿，整本看完喔（有什麼好得意的？）。

這本書真的寫得很好，很多地方看了讓人拍案叫絕。但是，沉澱了幾天之後，Teddy突然有一種感覺：「我是神經病嗎？（鄉民群內心獨白：Yes, you are.）」Teddy沒事幹嘛看這麼多軟體的書啊，看了越多只是讓自己更氣而已。這些書寫得再好，全台灣眾多的「天才 老爹 老闆」、產品經理、專案經理，他們都沒在看書的啊。就我們這些該死的工程師最倒楣，每天上班做專案、寫程式、除錯、寫文件，還要聽大官們鬼扯，累得要死。這些都算了，回家還要看書進修，以免趕不上多變的技術。

你的老闆，主管，還有眾多大老們，極可能是隱性的「海綿寶寶」，他們迫切需要的是「派大星」，就給他們「派大星」吧。

***

今天在聯合新聞網上看到一則李焜耀先生的專訪，標題是「李焜耀談產業／軟硬結合 創新商業模式」，引用一下整篇報導的最後一段話：

台灣過去是培養硬體人才，其實軟體人才很缺(這句話請大聲唸十次)，台灣目前不需要增加工學院，而是軟體學院，中國大陸就有軟件學院。軟體是廣義的，包括人機介面，以及如何設計出讓客戶好用的網頁等。

「其實軟體人才很缺」，軟體人才真的有那麼缺嗎？還是軟體人才出社會之後都被訓練成 狗 奴才了？（Teddy就認識一隻…啊，這隻不算，因為這隻出生時就是牠而不是他…XD）希望這些大老闆們如果真的覺得「其實軟體人才很缺」，不要再搞代工那一套來開發軟體，甚麼「責任制」，「加班，加班，我愛你」，都可以丟到垃圾桶了…錯，直接丟到焚化爐，丟到垃圾桶不小心又被「牠們」給撿起來重複使用。

「約耳續談軟體」中文版第223頁教鄉民們如何開發出好軟體：

頂尖的工作環境 –> 頂尖的程式員 –> 頂尖的軟體 –> 賺大錢

就這麼簡單，講完收工。

***

友藏內心獨白：Teddy私人還可以教你一招，先把「牠們」處理掉，軟體就會變好。真的，這是天底下唯一一招不花錢，又可以省錢，還可以讓軟體品質變好的招數。

交戰守則，自己寫

February 19 11:10~12:41

曾經在網路上看到一則新聞，標題叫做：德軍看到敵人可以直接開槍了，新聞內容如下。

由於傷亡慘重，德軍修訂交戰守則，今後在阿富汗的德軍不必看到敵人囉哩囉嗦的警告半天，才開槍了。

德軍一九四五年戰敗以後，受到制裁成了沒牙的老虎。有很多的限制，前幾年根本不能出國，現在跟北約盟國一起在阿富汗作戰。為了確保不侵略的形象，德國國防部頒佈了一本有七頁厚的交戰守則，裡面規定，德軍在敵人還沒殺死自己之前，不可以殺死敵人 德軍在敵人沒準備好要開槍以前，不可以開槍。開槍以前還必須用英文以及帕什屯和達里這兩種阿富汗語喊出「聯合國，別動，再動就開槍」這兩句話。

北約部隊私下說，在阿富汗戰場要認出德軍很簡單，手裡緊握著交戰守則，死在地上的就是了。德軍最近終於修改了交戰守則，把七頁減成四頁。新守則規定發現敵人就可以開槍，不用等敵人裝好子彈，打開保險，當然也不用先警告敵人了。

***

很多想要採用或是已經嘗試Scrum的鄉民們心中可能都會有這樣的一個問題：

Scrum或是其他的敏捷方法都說不用等需求全部都確定之後就可以寫程式了，問題是我正在開發一個資料庫應用系統，如果我不先把資料庫的schema全部都設計好並且讓使用者畫押確認，那我根本無法把工作分配給開發人員去施工啊？總不能設計好一個table就馬上開工吧。

討論這個問題的solution之前，先回答另外一個問題：

• 在以前的經驗中，是否只要先花時間把資料庫的schema設計好，後續的schema幾乎很少更動？

如果這個問題的答案是Yes，那麼恭喜你，你遇到了一個需求很明確的專案，或是一個什麼都不會要求，並且胃口很好什麼都吞得下去的 白癡 好客戶。那還管什麼Scrum不Scrum的，就按照你原先覺得很好的方式去開發軟體就好了。先把需求包含資料庫schema設計好，假設花了你整整兩個月好了，之後再把Scrum團隊找來，開始施工。在這之前Scrum團隊成員可以先去忙其他的事。

不要為了 CMMI而CMMI  Scrum而Scrum，最後落得手裡緊握著Scrum講義，死在地上的下場。

***

對於想要導入Scrum的團隊，都會遇到一個很根本的問題：如何把現行的軟體開發方法，偷渡…不對，應該說過渡，或是「無痛」轉換成Scrum所描述的方法，並獲得所有敏捷開發方法所宣稱的好處：每個iteration結束都有一個可執行的軟體、可以隨時接受客戶需求變更、開發出高品質的軟體、賺大錢、取水某、嫁好尪、出國比賽，得冠軍，拿金牌，光榮倒轉來…等等等等等。

Yes, you can…大概run個幾十上百年應該就可以（這是在開發軟體還是準備修道成仙…XD）。

如果鄉民們是一位軍人，國防部可以給你武器，給你裝備，給你後勤支援，給你發餉甚至是加薪，讓你無後顧之憂的去打戰（那個國家的國防部那麼好？）。但是國防部沒辦法給你一個「完美敵人」，沒辦法要求敵人一定要跟你打正規戰。你的敵人可能是把炸彈綁在C字褲上的辣妹（氨辛啞？），或是開車以時速300公里衝撞崗哨的101歲人瑞阿嬤，或是準備到處散播致命病毒的瘋狂科學家。

「新守則規定發現敵人就可以開槍」，好，很好，非常好，非常之好，好的不得了。為了自身安全，那就來個「看到黑影就開槍吧」，你心裡面暗自竊喜的如此盤算著。但是，這樣也不行啊，到時候又引來濫殺無辜的批評，每天聽到這些 狗嘴 名嘴在電視上大放厥詞，你的下場也好不到那裡去。

七刀，吃這個也癢，吃那個也癢，那到底要怎麼辦？

沒什麼怎麼辦，就是要看著辦。每一位好的工程師，心中都有一本交戰守則（Teddy內心獨白：其實不好的工程師心中也有一本，而且比你的那一本寫得還要好很多…Orz）。這本交戰守則，可能是歷經十幾年以上的實戰經驗所累積出來的寶典。也可能是苦學多年看了幾百本書與論文的心血結晶。想要輕輕鬆鬆聽了幾場免費的演講就寫出一本屬於自己的萬用交戰守則是不可能的。

演講還是要聽，搞笑談軟工還是要看。但是最重要的還是要回歸原點，馬步有沒有好好地蹲，基本功夠不夠。如果鄉民們的「國防部」沒有給你足夠的訓練與資源，只能想辦法自己變強，或是換個「國防部」吧。下一個「國防部」也許會更好…XD。

***

友藏內心獨白：這一篇亂七八糟的到底在講什麼碗糕。