＊＊＊ 本文同步發表於 FB 社團－軟體設計鮮思維 ＊＊＊

前幾日在許多新聞電視台播放這則新聞：「牙醫預約APP 七年級生月營收20萬」。

的確很欽佩這位七年級生，剛出社會沒多久，就將自己的理想與創意實現，並因此而創造出公司的金流 (cash flow)，立穩經營的腳步。

然後在看播放新聞的過程中發現到，喔，該 App 創辦人兼開發者，應是利用 GitHub 作版控 (version control)與維護程式碼的。這很正常更是值得鼓勵與借鏡，即使少數三兩個軟體人員，藉由雲端儲庫 (cloud repository)作版本管控，更能實行遠距協同開發與溝通，讓協同開發更形順暢。

然後又一瞥看到開發者撰寫的程式者，只是一小段而已，不過應該看得出在某一個方法 (method) 內撰寫了許多 if..then..else 的條件判斷陳述。

喔，這其實算是違背了「Clean Code」簡潔程式碼的原則。每一條判斷陳述可能是代表了單一的工作單元 (unit of work)，當條件判斷陳述越多、變化越頻繁，越是難以維護。一般這最好是施以重構 (re-factoring)，運用「萃取 (extract)」的技巧，分派單一工作至相對應的類別/方法 (class/method)內，讓程式碼回歸到簡潔易讀好維護的原點。

這讓我又再次思考一個問題：到底發揮創意並具體實現最重要，還是要求程式碼乃至工作的品質？

這幾年個人乃至於所屬的顧問團隊，可說都相當要求系統 (包括分析設計產出與程式碼)的開發至維護期間的品質，目的是為了讓開發更形直覺順暢，以及讓後續的維護更能應付變動，如此更能增進系統整體的價值。

但個人更是推崇 Maker 的文化，從發想到創意的實現，一切自造，需整合相關軟、硬體知識，並從過程中持續學習與修正不足之處。

創意的發揮來得比單一所擁有熟練的技能甚或品質更有價值！！

那回歸軟體領域，如此為了維繫軟體程式碼的意義何在？ 這可真不容易回答！

以我在這個業界多年所看到的現況大都是，程式碼寫得很糟糕，所以需要更多人超出更多工時，耗費不必要的精神/精力去維護軟體系統 (具體就是程式碼)。而在這個業界的軟體人員為了現實的生活，使得在工作上不得以因循苟且，日久也不會更不能把原來美好的理想/創意得以實現了。

增進軟體 (程式碼) 品質，讓自己更輕鬆些，時間較多可以有更多的發想與創意以及包括知識技能的提昇。個人比較傾向是這樣的想法。

倒是軟體業界資深的大師 Kent Beck (重構的創始者之一, TDD 測試驅動開發的作者與創始, Agile 方法論的先驅)，在 Implementation Patterns 一書中的前言提了這一段：

「好的程式碼是有意義的。我見過太多醜陋的程式碼仍替它們的主人賺進大把鈔票，所以在我看來，軟體要取得商業成功或被廣泛應用，好的程式碼品質既不必要也不充分。

即便如此，我仍然相信，儘管程式碼品質不能保證每好的未來，但它仍具有意義：有了品質良好的程式碼以後，業務需求能夠被充滿信心地開發與交付；面對機會和競爭，能夠更及時地調整方向，而開發團隊能夠在挑戰和挫折面前仍保持高昂的鬥志。

總而言之，比起品質低劣、錯誤重重的程式碼，好的程式碼更有可能：幫助使用者取得業務上的成功。」

Kent Beck 接著在下一段更是提到：

「即便不考慮長期的經濟效益，我仍然會選擇『盡我所能』編寫出好的程式碼。．．．。編寫好的程式碼讓我有滿足感，不僅因為程式設計本身，還因為知道別人能夠理解、欣賞、使用和擴展我的工作。」

天哪～ 我覺得已經一語道盡為何要寫出好的程式碼的最好解答了？！

其實無它，就是喜歡與熱愛自己的工作－程式寫碼。進而當寫出覺得自己好的程式碼，得以讓別人欣賞與肯定，那就是一種無以言語的滿足與成就感了。