[軟體開發] 公司想要的快，真的有那麼快嗎？
The speed of software developement.
Published in
3 min readApr 27, 2020
開始講廢話前，我們先看個影片吧！點一下上面那個連結，會發現最快抵達右方端點是位於中間軌道的那顆球，我就把這個現象類比到軟體開發上。
第一顆球（軌道長度最短）
- 一般公司大概都是這麼想的，只要寫出來的程式碼能動，軟體能賣就好，趕快賺到錢是重點！（賺錢確實很重要，不然員工的薪水還有各種成本要怎麼支付呢）於是工程師礙於時程壓力，使用最快速的方法寫出能動的程式碼（通常是 hard code），在期限內將軟體交付出去（太好了～貨出得去，錢進得來，公司發大財！），但同時也開始欠債——技術債，隨著需求的成長，程式碼變得越來越複雜（工程師 mermer：程式碼怎麼越來越難改動＠＠，老闆 mermer：工程師的動作怎麼越來越慢＠＠）。
- 嘿嘿～此時是不是該導入一些軟體工程的手法了呢？例如：重構、撰寫單元測試並且自動化⋯⋯。
第二顆球（軌道長度居中）
- 乍看之下，這條軌道比上一條還要長，怎麼球會比較快抵達目的地呢？這邊就先跳過原理不說，從實驗結果來看原來直線距離（最快速的方法，通常是 hard code）不一定會是最快的，這也是正在成長中的軟體很常遇到的狀況，那些歷史共業（技術債 mermer：出來混總是要還的）正在拖慢開發的速度！
- 雖然本人的物理也沒有學得很好，但感覺可以用「重力加速度」、「位能轉動能」之類的原理來解釋，在該篇推文中提到了「最速曲線」，那我就借用這個名詞類比到軟體開發上，稱之為「軟體開發的黃金曲線」。
- 我認為「軟體開發的黃金曲線」基本上包含了幾個原則：SOLID、每次 checkout 的程式碼都要比原來的好一點點⋯⋯這些都是《Clean Code》提到的內容。
第三顆球（軌道長度最長）
- 發現這條軌道，一開始就有大量的位能轉換成動能，那速度上應該也不差才對啊！嗯～但也許是因為前期的能量轉換過程較長，加上後面還有一段距離要跑，即使具有一定的速度，仍然讓第二顆球捷足先登了！可惡⋯⋯。
- 這個現象類比到軟體開發上，我認為就滿像「Over Design」，前期花了太多工夫，也不確定未來是否一定會使用到，相較來說第二顆球的軌道設計是恰到好處，也就是說盡量每一次都做到「剛剛好的軟體設計」，但什麼是「剛剛好」，有時候也是相當依賴設計者的經驗。
最後總結一下，不論是哪一種類型的軟體開發，幾乎都會遇到上述類似的情況：
- 第一顆球 — 技術債（欠債要還、何時要還？）
- 第二顆球 — 開發的黃金曲線😀
- 第三顆球 — Over Design
還有軟體開發其實很需要節奏 ，就像千五賽跑一樣需要「體力」跟「配速」，盲目衝刺絕對不是個好辦法（這時 Scrum 心中 mermer：好像該我上場了）。
Last Updated April 27 2020
