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