軟件工程師應該堅守的價值
「Code 寫得好對公司有用嗎？」這一篇我們談到Martin Fowler如何分析軟件質素和開發時間的兩難，這次就讓我們看看Robert C. Martin 在其近作《Clean Architecture: A Craftsman’s Guide to Software Structure and Design》對於軟件開發時，軟件工程師所面對的難題。
還原基本步，軟件本身究竟對於軟件的持份者有何價值？Robert C. Martin認為主要有兩種：行為價值（Behavior）和結構價值（Structure）。
行為價值，意思即是軟件本身的用途。首先軟件會被設計成使得某個機器以指定的方式運作，並因而可以幫助開發方創造或提高利潤。而軟件工程師則是負責幫助系統的使用者建立一套對於這個軟件系統的功能定義（functional specification），或者是其需求文檔（requirements document），然後編寫相應的程式使得機器能夠符合這些要求、定義。而當程式的運作不符要求，軟件工程師就要負責除錯，並解決問題。
結構價值，意思即是軟件的靈活度。軟件之所為「軟」件，皆因其柔軟，保持靈活，容易被改變，否則就和硬件無異。軟件本身用意在於能夠通過一種方式，輕易轉變機器的行為。
改變的實行
很多時軟件工程師以為自己只需要應付行為價值，按照需求編寫程式，並持續改錯才可以，但現實並非如此。
對於軟件的持份者來說，他們所提出的一系列改變的範圍都是大概類似的。但在軟件工程師來說，處理持份者的改變就如要持續將一堆拼圖塊，拼到同一個愈變複雜的拼圖裏。Robert C. Martin比喻為將方形的螺絲擰進圓形的螺絲孔裏，因為現有的系統的「形狀」（shape）不會和要求的「形狀」相同。
改變的範圍和「形狀」之間的分別，很多時就成為影響軟件成本的關鍵。有時改變的成本比例會遠遠大於所需改變的大小，亦令開發成本年年遞增。
改變的難度理應只與改變的範圍（scope）有關，而非與改變的「形狀」有關，而這牽涉到系統的架構設計。因為只要架構設計傾向一種「形狀」，那麼新的要求就更難得以實施。
兩種價值的爭持
那麼，這兩種價值如何取捨？系統能夠運作重要，還是系統能夠輕易改變重要？
如果問一個業務部經理，答案自不然是前者，並認為現時的功能比起往後的靈活度重要，而不少開發者亦會跟隨這種說法。不過，Robert C. Martin認為後者比前者來得重要，他舉例說：
- 如果一個程式能夠正常運作，但完全無法改變的話，那麼當需求改變，程式就不能夠運作，而開發者亦無從將之改變。程式就等同垃圾。
- 如果一個程式目前未能正常運作，但容易改變的話，開發者就能使其運作正常，便可以隨著需求改變加以修改。程式就能夠持續有用。
當然，有些系統因為一些功能、定義，的確無法改變，因為其改變的成本超出改變所帶來的利潤。而這時，業務部經理就會因為你任由該系統到達一個無法改變的程度憤而大怒。
緊急和重要的分歧
Robert C. Martin 提到一個分析難題的方法： The Eisenhower Matrix。
難題通常有兩種，緊急的和重要的。通常緊急的都不特別重要，而重要的都不特別緊急。而系統的功能就是前者，而系統的架構就落入後者。而在The Eisenhower Matrix裡頭，就分為四種：
- 緊急而重要的；
- 不緊急但重要的；
- 緊急但不重要的；
- 不緊急又不重要的；
業務部門和開發者通常就是將緊急但不重要的事，優先於緊急而重要的。他們沒有將重要的和不重要的分開，而導致真正重要的事情被忽略，重要的系統架構就被不重要的功能所覆蓋。
Robert C. Martin指出，分析事情重不重要，責任不在業務部門，因為他們沒有能力去分別。所以開發者為了公司長遠利益，應該有責任去指出事情的優次為何，而和各部門的作出持續掙扎，其他的部門亦應如此。
開發者作為開發軟件的一員，應該清楚這種和各部門之間掙扎，堅持系統的靈活度，以維護系統架構，這也是職責的一部分。
Website: https://ones.software/
Email: hello@ones.software
Tel: (+852) 5538 3410
更多資訊可以留意 ONES Publication 定期發佈的文章，亦可以聯絡我們，我們的網址是： https://ones.software