iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 2
0
自我挑戰組

軟體工程漫談系列 第 2

打孔機與現代方法

筆者雖然是個年輕人(心虛),但也聽師長說過,在很早很早的年代,寫出一段程式要debug有多麼的困難。在那個年代,寫出一段程式,要使用打孔機,很像現在大考依然常用的那種電腦閱卷卡,到計中排隊submit,過段時間去領結果,萬一錯了,就再拿張紙,修正錯誤後再去提交,再等結果...,一直到結果正確為止。

打孔卡,來源:Google

你可以想像,在那樣的年代,事前做好完整的規畫有多麼的重要!你也許需要把所有流程完整的畫出來,何時if,else時要幹啥,你甚至連print出變數內容來debug都要事前規劃,並且考慮再三。這也就難怪我們讀書時,老師們都會叫我們一定要經過充分完整規畫後再動手寫程式了。

我必須要先說,這樣的習慣是非常好的。有了好的規劃,可以檢哨走歪路的機會,也可以幫助程式設計員釐清思路與邏輯。然而,當你的產品越長越大,大到了單一專案再也容納不下,一個人也無法獨力完成時,你要怎麼辦?你還是能像以前那樣做出完整又細節的規劃嗎?以現代軟體發展的速度,也許當你規劃完,商機已經失去,那你也不用真的實作了。

現代的軟體開發,探索式的功能開發,成本已經大大降低。git幫助你錯誤時及時回頭,CI工具幫助你隨時做好完整測試與上版準備,容器技術幫助你隨時在任何環境架設一模一樣的新服務。當然,規劃還是得規劃的,但是,有需要到每個case每個邏輯轉折都要想通才能動工嗎?那倒未必...

敏捷開發,以scrum為例,有規律週期性的產出、檢討、與方向調整的過程。我們每個sprint只做目前最重要的幾件事,同時為其做出邏輯規劃,也只規畫這些,未來的功能,我們等需求更明朗時再作決定即可。同時,當有一個新功能或是新技術,你不確定是否要真的投入大量心力去實現時,你也可以花一個sprint的時間研究或是做一個prototype來看看成果如何。

敏捷流程不是快,是有彈性。我們每一到兩周就會檢討並調整方向與內容,同時產生出一個幾乎可以直接上線的商品。在這強敵環伺,弱肉強食的激烈市場,您有什麼理由不接受敏捷開發流程?


上一篇
<前言> 懶惰的工程師萬歲 粗談DevOps與軟體工程
下一篇
用數學方法說明增量與迭代的力量
系列文
軟體工程漫談7

尚未有邦友留言

立即登入留言