文章同步於it邦
前言
鐵人賽來到最後3天了，我想講開發模式
這和程式會不會跑有什麼關係，當然有，關係可大了
當你沒有思考過開發模式的時候，就很容易讓軟體開發出現問題
例如說：我今天走一步算一步，我就直接下去寫
結果發現寫出來的和業主、PM、市場需要的產品完全不同
此時你會面臨幾個選項
- 全部重來，但這代表你的交付時間只會延長，有簽約的狀況下還會違約
- 硬著頭皮交差，如此一來就是損失商譽
人生重來
這兩者似乎都不是我們樂見的
那又要如何選擇我們要的模式呢，就在接下來的文章介紹
今天先來輕鬆的介紹，惡名昭彰的隕石開發
介紹
從前從前有一個工程師，他叫小明
他花了1個月的時間，把某個系統建構完成
此時某位荷包蛋，我們稱它為蛋蛋君
蛋蛋君跟小明說：「小明阿，我發現我需求對錯了，你要把A功能整個改掉重做」
…說明需求…
小明：「可是這會涉及到很多的層面，這樣子是連核心的業務邏輯都不同了，規格書當初不是這樣…」
蛋蛋君：「不行，我就是需要，還有我們只有３天的時間，我已經說３天後我要交給客戶了，你一定要改出來，就這樣」
然後蛋蛋君就走人了
1天後…
蛋蛋君：「小明阿，我需要幫某個網站多加一個功能，不難」
…說明需求…
小明：「這個功能涉及的層面很廣，不是說改…」
蛋蛋君：「照我說的做就對了，還有明天就要！交不出來就直接扣考績！還有A功能也要交出來，我跟客戶掛保證說明天就要了！」
小明：「不是說三天…」
蛋蛋君：「有時間廢話還不快點做事，我不管你怎樣做，你就是要做出來，另外這樣不能報加班，讓我看到你報加班，你連年終都不用領了。」
隔天…
小明：「好了，我趕出來了，我在公司做到凌晨三點才走人」
蛋蛋君：「慢死了，你是不是沒什麼能力阿，快點走，我不想看到你。」
然後蛋蛋君轉頭直接跟客戶說：「是，這些都是你要的功能，在我的領導之下，雖然晚了一點，但我還是交付給您」
小明：#$%$#%^
我們可以看到，規格書的需求被破壞、臨時的插件這些都是隕石
莫名其妙有個神仙從天上砸隕石下來
再拿你的心血說這是他的功勞
更慘一點，後續還是要叫你加上其他功能
這就是隕石開發
優點
我條列以下優點
- 逼出你個人的極限，不過高機率寫爛扣
- 證明參與該開發模型的員工，通常CP值都非常高
缺點
我想應該是會折壽吧
如何用Clean Coder的方式去面對
不講幹話了
工作上就是會有那麼多無理的要求，身為一個專業人員，確實是該將公司的利益視同為自己的利益
基本上身為一個專業人員，就必須從中找出良好的解方，時間趕沒錯，但還是不能像爛架構妥協
舉個例子：
約莫我在寫這篇文章的前幾天，我才被要求說要改某個核心功能
PM說的倒是簡單，但真的這麼做，我就必須要資料表中加入8個欄位
但受限於我們使用的套件，跟資料庫格式設計非常有關連，且又會影響到顯示，所以這件事其實沒有那麼容易
這個欄位你就想像是，我有一個資料表示用來儲存學生的資訊，而這8個欄位儲存的是他們考試的成績
所以哪天他們要多考一科要在紀錄上去你就要再多開一個Column
大概是這個概念
於是乎我就必須幫自己想個解套的方法
後來我找了各種文章、GitHub issue想出了一個能夠符合他們的需求，又可以保持資料表的彈性不違反正規化的作法
當然啦，如果說他們只給幾小時，我可能也沒時間找了。
但我們還是要盡力的去說明各種做法的利弊，至少盡到告知的義務
提升自身價值
這一切聽起來都不合理
但仔細想想，也是我們選擇這間公司的
不如思考，為什麼我們會在這個地方
所以，多多面試、刷題、做side project、讀書
身為一個Clean Coder當然是找專業的公司囉