定義很重要
前幾天，同事承接了一個「軟體模組化」的案子，號稱是全事業處等級的案子，因此找了我和其他部分的精英，要說明一下他初步的規劃，也收集一下大家的意見。會議前我還是按習慣先問清楚，會議要討論的題目是什麼？有什麼資料是我們該先閱讀過的？他只給了我們一個簡報，大致上寫了些他的規劃。
「軟體模組化」是一個近年在公司聽到快爛掉，可在軟體開發領域中應該是已經變成化石燃料的名詞，正式的名稱應該是「模組化設計」。因為公司許多人對這個名詞有一些不切實際的想像，甚至還有一些異想天開，張冠李戴的實作，所以我再度跟他確認一下，他想要的軟體模組化，是「軟體IC化」的樣子嗎(「軟體IC」基本上是個更不"正經"的說法，不過對老一輩的人來說似乎更好懂，所以就這麼問了)？確認後，我就繼續看看簡報裡寫了些什麼。
簡報中理想的描述了他想在公司內創立一種特定遊戲的平台，請每個開發這種類型遊戲的各專案的開發者，都能以軟體「模組」的方式開發，讓A開發過的模組，能讓B複用，達到資源共享的目的。大方向看起來沒什麼問題，只是沒有名詞的定義或詳細的解釋，所以我就特別問了一下：你口中的「模組」有明確的定義嗎？一份源碼？一個package檔？還是一支函式庫？
他說都可以，我們不要在文字上面打轉，重點是「共享」這個大方向啊。我繼續提了一個可能的定義，他覺得沒問題，就這樣吧。聽得出來他真的不是很care，我也就不再追問了。反正，他真的不知道要解決什麼問題？現在有沒有人已經在做了？他只是要請大家來"討論"一下。
這種事情在我們的新人訓練中很常見，也是新人特別容易被考倒的地方。我們常會問新人：你為什麼知道在這裡要做這件事？簡報中的「傳上去」是指commit還是push？你講的編譯是compile,link還是build？#include後用「"..."」跟「<...>」有什麼不同？這些問題還真是喜歡雞蛋裡挑骨頭，對吧？你知道意思的嘛？幹麼一直卡在那裡過不去呢？
沒辦法，你這裡不清楚，到時候你就會在更撲朔迷離的地方過不去。
我本來以為那個會議，可能就是幾個比較資深的軟體人員，先就一些大方向討論一下，結果沒想到當場來了10幾個各種資歷不同的軟體人員。還好是線上會議，不會浪費我太多時間(？)。不出所料，從第一張簡報開始，就開始了"熱烈"的討論(聽起來很滿足他的需求？)。有的人說不懂他要做什麼模組化？我們已經做了很多啊；有的人說你要做模組化可以，可是不要強迫各部門使用；有的人說你不能要求各部門promise說什麼時候能交出元件來，我們也有自己的專案要趕。這種定義不明，只有意象的簡報就像乾材一樣，很容易從幾個"火星"問題開始燒成森林大火。有些人看苗頭不對，估計很快就把頁籤的聲音關掉，潛水潛到底，繼續幹自己的活了。
就像之前我跟許多同事常提過的，軟體設計什麼事最難？我會說「命名」絕對是前三名，因為 「命名」的本身就是一種「定義」的結果 。討論事情的過程，如果我真的很在意討論的主題是什麼，我也常常會把定義問個清楚：你指的「它」是什麼？你說的這個流程，是「A→B→C→D」這四個步驟嗎？我們現在討論的溫度是外殼的溫度還是核心的溫度？有時候我會得到「莫名其妙」，「很難討論下去」還是「很卡」的回應，也會讓我有點情緒。現在也比較容易放得下，讓討論繼續了。追求真正的答案本就是一趟不輕鬆的旅程，因為常常問題的本身就有問題。
定義為什麼很重要？因為它要求你想清楚，你要解決的問題是什麼？
「程式為什麼當掉了？」中的「當掉了」是什麼意思？畫面停住不動了？還是程式閃退了？還是畫面變黑了？還是流程跑掉了？不管是哪一種，你要解決的問題完全是不同面向的；「軟體模組化」中的「模組」是什麼？一整個專案源碼做為樣版？一份源碼？一支預編好的函式庫？你要模組化的「軟體」又是什麼？是整個遊戲？還是特定功能？如果你沒辦法講清楚它們的定義，就代表你根本沒想清楚你要解決的問題是移植遊戲太慢，還是遊戲調整太難？「效能不好」是指FPS不夠？按鍵反饋太慢？讀取太慢？還是NPC跑得太慢？如果搞不清楚你的「效能」是指什麼？你可能會付出事倍功半的優化成本。
定義為什麼很重要？因為這能讓你搞懂事情的本質，才有所謂的深度思考。
大家聽過很多保險商品對吧？不管業務員再怎麼試算給你看，熟知保險的定義的你，就會很清楚，保險就是「滿足條件才給錢」的金融商品，絕對不可能會是可以賺錢的資產。醫療險住院有給付，意外險住院有給付，看護險住院也有給付，那它們有什麼差別？以「滿足條件」的本質去看就一目瞭然，很快就能理解自己需要的是什麼。源碼風格大家都說好棒棒，可以優化軟體品質。可源碼風格的本質…就是「風格」不是嗎？大家既然都會笑說「裕隆的車子從賓士的修車廠出來，也不會變成賓士」，那為什麼會期待源碼風格可以改變軟體的品質？深度思考下去就會發現，多建立一些範式(Paradigm)可能還比較有幫助。
定義為什麼很重要？因為這是大家有效率協作的通訊協定。
各行各業為了加速溝通效率，都會有所謂的「行話」及「專有名詞」。並不是什麼太了不起的概念，就是我們要討論線性代數前，大家總得理解九九乘法的概念是相同的，才不會我們講了一大堆東西，聽眾根本搞不懂我們在講的是中文還是英文一樣。或許線性代數和九九乘法的比喻有點激進，但在抽象概念越高的知識型工作中，「失之毫釐，差之千里」的狀況卻一點都不少見。剛剛提到的「軟體模組化」中，「軟體」跟「模組」的定義不明，輕一點只是造成一次無效會議，嚴重一點可是會造成投入的資源浪費，甚至是整個軟體架構的嚴重偏差(偏偏人類又有保護自己已經做好的東西的傾向)；你告訴我程式「崩潰」了？好，那我就不用擔心是不是哪裡有死迴圈還是狀態機沒有弄好，可以專心去找是否有哪裡記憶體違規存取？如果我要去找哪裡「記憶體違規存取」，而你想來幫忙，那你得確保你是去看有沒有變數未初始化，有沒有超過陣列範圍的資料存取，而不是來檢查我輸出的檔案有沒有超過硬碟的可用儲存空間；如果我們在討論遊戲的「核心迴圈(core/game loop)」應該設計沒有問題，那我們的共識的下一步應該是指，開始可以加入一些技能或道具，關卡設計，或是故事劇情的世界觀，而不是指再找一些不同年齡層的玩家來試玩，還是討論主角設計的好不好看，這裡是否應該加一點特效或音效的。
很多時候，當我和同事在討論一些事情的時候，從他們能否清楚回答我那些「定義」的題目，基本上就能知道他們對這個主題理解到什麼程度。有時我會很慶幸，身邊的同事是真正專業的高手，他們可以真正做到簡潔明瞭的說明。有時我會很挫折，只得到一些「那不重要」，「別咬文嚼字」或是「大家不是技術人員」的回應。如果可以，我會再靜靜觀察後續的事態發展，因為很多時候這些事情真的只是一頭熱的表面討論或是應付了事，如果太認真跟大家吵起來，搞得大家不愉快，但其實根本就只是件微不足道的小事，那就太不值得。若大家真的是很認真的當一回事，通常到最後，這些人就會回頭來討論這些「定義」問題。
定義很重要不是嗎？大家真的要Do Something的時候，才會意識到要「Do the right thing」，而不是一頭熱的只是想「Do the thing right」。那些說定義不重要的，那表示這件事就是還沒那麼重要。