iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 28
0
Software Development

軟體開發隨筆談系列 第 28

軟體開發也應當恪守工程的嚴謹與明確

有別於人文學科,工程通常是帶有嚴謹、明確目的的。雖然常聽到程式設計是一門藝術,但這不妨礙軟體工程也帶有工程性質,就如同建築,也是設計與工程兼具,所以不能用程式設計帶有藝術性質就不去遵守其嚴謹性、不去實踐工程的專業素養。

在軟體開發中,從小到大、從深到淺、從定位到產品,從程式碼到文字紀錄,都應當是有明確的目的與定義的。從最為工程師知曉的 SOLID 中的單一職責原則(Single responsibility principle),就講明了一個類別應該只能有一個理由去變動,從這裡概念延伸出去,我們也會要求單一方法應該也只負責一件事情,就如同 Unix 所言「讓程式只做好一件事」。所以我們盡量明確定一個建立每個變數、每個方法、每個類別、每個命名空間、每個套件的目的、它們的職責、以及它們的存在理由與範疇。

如果嚴謹遵守這個概念,變數名稱就會明確、並且只存在需要他的範疇(Scope)、一個方法不會有太多切換用的參數作為開關,因為他只會一次做好一件事、一個類別不會太大,畢竟他只負責一種職責、只代表一種存在。寫出來的程式碼自然漂亮、帶著工程之美。

另外,在規劃軟體時,也要嚴謹的去定位他的價值。如同我們要蓋房子時,盡量在一開始明確定義它的目的,一般的住宅很難改成立體停車場或是大型餐廳、商辦大樓不可能變成工廠,縱然現實可能存在不斷改變的案例,但一旦定位變動過大,該建築可能就會東加蓋、西補強,變得醜陋。

所以我們在做軟體產品時,一定要明確暸解我們開發這個軟體是為了什麼,如果後來打算轉換定位,或許應該考慮的是另外開一個軟體專案,而不是硬要在原本不適合的基礎上實作與當初定位相差甚遠的功能。

而在 API 的設計上也是如此,如果沒有一個一致的風格、沒有系統性的規劃路徑與方法,那麼這個 API 就難以被呼叫者暸解,甚至會耗費無意義的時間在弄懂其不直覺或是反人性的設計,讓除錯成本提高。

除此之外,一個 commit、一個 branch、一個 Pull Request 的存在目的都應該要明確,維持只為一個目的變動、一個理由存在,這樣才不會在未來追溯時產生想找的變動在意想不到的位置裡,而在 Code Review 時也比較能讓讓變動之間的關聯更緊密,讓檢視者更好抓到重點。

程式設計有其藝術性,但軟體開發也確確實實是一門工程學問,它們的美除了來自於各種哲學外,更表現在工程的嚴謹上,不能因為其相對現實實體來說較抽象,就忽略它的工程性質。


上一篇
軟體開發的日常練習
下一篇
軟體開發不是一個人的事
系列文
軟體開發隨筆談31

尚未有邦友留言

立即登入留言