0%

【Day - 27】開發模式 - 隕石開發

文章同步於it邦

前言

鐵人賽來到最後3天了,我想講開發模式
這和程式會不會跑有什麼關係,當然有,關係可大了

當你沒有思考過開發模式的時候,就很容易讓軟體開發出現問題
例如說:我今天走一步算一步,我就直接下去寫

結果發現寫出來的和業主、PM、市場需要的產品完全不同
此時你會面臨幾個選項

  1. 全部重來,但這代表你的交付時間只會延長,有簽約的狀況下還會違約
  2. 硬著頭皮交差,如此一來就是損失商譽
  3. 人生重來

這兩者似乎都不是我們樂見的

那又要如何選擇我們要的模式呢,就在接下來的文章介紹
今天先來輕鬆的介紹,惡名昭彰的隕石開發

介紹

從前從前有一個工程師,他叫小明
他花了1個月的時間,把某個系統建構完成

此時某位荷包蛋,我們稱它為蛋蛋君
蛋蛋君跟小明說:「小明阿,我發現我需求對錯了,你要把A功能整個改掉重做」
…說明需求…
小明:「可是這會涉及到很多的層面,這樣子是連核心的業務邏輯都不同了,規格書當初不是這樣…」
蛋蛋君:「不行,我就是需要,還有我們只有3天的時間,我已經說3天後我要交給客戶了,你一定要改出來,就這樣」
然後蛋蛋君就走人了

1天後…
蛋蛋君:「小明阿,我需要幫某個網站多加一個功能,不難」
…說明需求…
小明:「這個功能涉及的層面很廣,不是說改…」
蛋蛋君:「照我說的做就對了,還有明天就要!交不出來就直接扣考績!還有A功能也要交出來,我跟客戶掛保證說明天就要了!」
小明:「不是說三天…」
蛋蛋君:「有時間廢話還不快點做事,我不管你怎樣做,你就是要做出來,另外這樣不能報加班,讓我看到你報加班,你連年終都不用領了。」

隔天…
小明:「好了,我趕出來了,我在公司做到凌晨三點才走人」
蛋蛋君:「慢死了,你是不是沒什麼能力阿,快點走,我不想看到你。」
然後蛋蛋君轉頭直接跟客戶說:「是,這些都是你要的功能,在我的領導之下,雖然晚了一點,但我還是交付給您」
小明:#$%$#%^

我們可以看到,規格書的需求被破壞、臨時的插件這些都是隕石
莫名其妙有個神仙從天上砸隕石下來
再拿你的心血說這是他的功勞

更慘一點,後續還是要叫你加上其他功能
這就是隕石開發

優點

我條列以下優點

  1. 逼出你個人的極限,不過高機率寫爛扣
  2. 證明參與該開發模型的員工,通常CP值都非常高

缺點

我想應該是會折壽吧

如何用Clean Coder的方式去面對

不講幹話了
工作上就是會有那麼多無理的要求,身為一個專業人員,確實是該將公司的利益視同為自己的利益

基本上身為一個專業人員,就必須從中找出良好的解方,時間趕沒錯,但還是不能像爛架構妥協
舉個例子:
約莫我在寫這篇文章的前幾天,我才被要求說要改某個核心功能
PM說的倒是簡單,但真的這麼做,我就必須要資料表中加入8個欄位
但受限於我們使用的套件,跟資料庫格式設計非常有關連,且又會影響到顯示,所以這件事其實沒有那麼容易

這個欄位你就想像是,我有一個資料表示用來儲存學生的資訊,而這8個欄位儲存的是他們考試的成績
所以哪天他們要多考一科要在紀錄上去你就要再多開一個Column
大概是這個概念

於是乎我就必須幫自己想個解套的方法
後來我找了各種文章、GitHub issue想出了一個能夠符合他們的需求,又可以保持資料表的彈性不違反正規化的作法

當然啦,如果說他們只給幾小時,我可能也沒時間找了。
但我們還是要盡力的去說明各種做法的利弊,至少盡到告知的義務

提升自身價值

這一切聽起來都不合理
但仔細想想,也是我們選擇這間公司的

不如思考,為什麼我們會在這個地方
所以,多多面試、刷題、做side project、讀書
身為一個Clean Coder當然是找專業的公司囉

參考資料

メテオフォール型開発
轉載好文:隕石開發法