在山姆鍋早期的職業生涯,還在擔任軟體工程師的時候,發生的一件事讓山姆鍋體驗到要讓整個團隊的開發成為一個完整可順利運行的系統,缺乏架構真的困難重重。

當時團隊連同技術主管有四個人,在開發的軟體是個 Java web 應用,使用的是很常見的三層架構:web、app 跟 data。這個軟體一開始的架構就剛好是四個模組,分別為「前端 UI」、「後台 UI」、「核心模組」以及「整合模組」(這些名稱是山姆鍋現在編撰的,在當時內部鐵定不是這樣稱呼)。山姆鍋負責核心模組,另外兩位工程師各自負責前端跟後台,而技術主管則負責神秘的整合模組。之所以神秘,主管分別跟三位工程師各自設計自己負責的模組介面,然後由他負責開發整合模組,這也是為何山姆鍋稱主管負責的模組叫做整合模組。而之所以神秘的原因是:山姆鍋連同另外兩位工程師從來就不知道整合模組如何運作。在前端、後台以及核心模組開發完成後(只剩整合),山姆鍋了解到現在的模組設計的介面根本就無法整合,多次在會議中提出這問題,請主管跟我們說明如何整合,主管一再說我們不用管也不用擔心,他會負責處理。就這樣一個月過去了,依然得到同樣的說法。由於專案時程僅剩一個多月,如果再沒有可以運行測試的軟體,專案鐵定會延遲交付了! 莫可奈何下,山姆鍋直接跟主管攤牌:現在就需要他完成整合,不然就承認他做不到 (由於當時是新創公司,公司有些主管甚至還是在學研究生)。事後才知道,雖然主管是資工本科系畢業,但程式開發能力根本不行,當時 CEO 只因為他是台清交畢業就指派他作為主管,但他卻好面子不想承認又想要有表現實際參與開發工作,這導致專案前期的開發很多部分要重做,也導致後來整個月山姆鍋每天都在加班。

上述的故事可能有點極端,但卻是山姆鍋遇到的真實案例。重點是:一旦一個軟體系統需要由多人來一起開發跟維運,就需要有人設計跟決定架構,參與的成員最好也能夠了解整個架構,了解自己負責的元件在系統中的位置以及扮演的角色。在這個案例中,還只是少數成員且相對簡單的架構都可以因為不清楚架構而導致進度停擺。所以,在實際動手寫程式之前,先確定好架構再說。即使是白板上畫的圖,只要能夠跟團隊成員溝通清楚都比打迷糊仗好。