創意確是來得比程式碼品質有價值;但好的程式碼仍是有意義的

*** 本文同步發表於 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 接著在下一段更是提到:

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

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

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

文章導覽

   

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *