闡述軟體架構師素養的絕佳古文-柳宗元「梓人傳」

軟體架構師 (Architect) 一詞,雖是源自於國外建築產業的關鍵術語,甚而建築業大師 Christopher Alexander 的著作:「The Timeless Way of Building」(國內翻譯書為「建築的永恆之道」」,更是被軟體業界奉為設計模式 (Design Pattern)之父。不過,關於軟體架構師應具有的素養,卻是更早可以從「古文觀止」其中一篇:柳宗元所著「梓人傳」,早已道盡成為軟體架構師所需的技能為何。

這裡節錄此篇古文,並引用國內 C++ 大師早已所翻譯部份文言為白話,可以確實好好品味欣賞、一讀再讀反覆玩味思考的。

裴封叔之第,在光德里。有梓人款其門,願傭隙宇而處焉。所職,尋、引、規、矩、繩、墨,家不居礱斲之器。問其能,曰:「吾善度材。視棟宇之制,高深圓方短長之宜,吾指使而群工役焉。舍我,眾莫能就一宇。故食於官府,吾受祿三倍;作於私家,吾收其宜大半焉。」

他日,入其室,其床闕足而不能理,曰:「將求他工。」餘甚笑之,謂其無能而貪祿嗜貨者。

其後,京兆尹將飾官署,餘往過焉。委群材,會群工,或執斧斤,或執刀鋸,皆環立向之。梓人左持引,右執杖,而中處焉。量棟宇之任,視木之能舉,揮其杖,曰:「斧!」彼執斧者奔而右;顧而指曰:「鋸!」彼執鋸者趨而左。俄而,斤者斲,刀者削,皆視其色,俟其言,莫敢自斷者。其不勝任者,怒而退之,亦莫敢慍焉。畫宮於堵,盈尺而曲盡其制,計其毫釐而構大廈,無進退焉。既成,書於上棟曰:「某年某月某日某建」。則其姓字也。凡執用之工不在列。餘圜視大駭,然後知其術之工大矣。

繼而嘆曰:彼將舍其手藝,專其心智,而能知體要者歟!吾聞勞心者役人,勞力者役於人。彼其勞心者歟!能者用而智者謀,彼其智者歟!是足為佐天子,相天下法矣。物莫近乎此也。彼為天下者本於人。其執役者為徒隸,為鄉師、裡胥;其上為下士;又其上為中士,為上士;又其上為大夫,為卿,為公。離而為六職,判而為百役。外薄四海,有方伯、連率。郡有守,邑有宰,皆有佐政;其下有胥吏,又其下皆有嗇夫、版尹以就役焉,猶眾工之各有執伎以食力也。

彼佐天子相天下者,舉而加焉,指而使焉,條其綱紀而盈縮焉,齊其法制而整頓焉;猶梓人之有規、矩、繩、墨以定制也。擇天下之士,使稱其職;居天下之人,使安其業。視都知野,視野知國,視國知天下,其遠邇細大,可手據其圖而究焉,猶梓人畫宮於堵,而績於成也。能者進而由之,使無所德;不能者退而休之,亦莫敢慍。不炫能,不矜名,不親小勞,不侵眾官,日與天下之英纔,討論其大經,猶梓人之善運眾工而不伐藝也。夫然後相道得而萬國理矣。

相道既得,萬國既理,天下舉首而望曰:「吾相之功也!」後之人循跡而慕曰:「彼相之纔也!」士或談殷、周之理者,曰:「伊、傅、周、召。」其百執事之勤勞,而不得紀焉;猶梓人自名其功,而執用者不列也。大哉相乎!通是道者,所謂相而已矣。其不知體要者反此;以恪勤為公,以簿書為尊,炫能矜名,親小勞,侵眾官,竊取六職、百役之事,聽聽於府庭,而遺其大者遠者焉,所謂不通是道者也。猶梓人而不知繩墨之曲直,規矩之方圓,尋引之短長,姑奪眾工之斧斤刀鋸以佐其藝,又不能備其工,以至敗績,用而無所成也,不亦謬歟!

或曰:「彼主為室者,儻或發其私智,牽制梓人之慮,奪其世守,而道謀是用。雖不能成功,豈其罪耶?亦在任之而已!」

餘曰:「不然!夫繩墨誠陳,規矩誠設,高者不可抑而下也,狹者不可張而廣也。由我則固,不由我則圮。彼將樂去固而就圮也,則卷其術,默其智,悠爾而去。不屈吾道,是誠良梓人耳!其或嗜其貨利,忍而不能舍也,喪其制量,屈而不能守也,棟橈屋壞,則曰:「『非我罪也』!可乎哉?可乎哉?」

餘謂梓人之道類於相,故書而藏之。梓人,蓋古之審曲面勢者,今謂之「都料匠」雲。餘所遇者,楊氏,潛其名。

閱讀全文 »

整合測試還是單元測試比較有價值?

** 本文同步發表於 軟體設計鮮思維FB社群 **

看到國外某作者的一篇論述:「Lean Testing or Why Unit Tests are Worse than You Think」。這篇文章我瀏覽了兩遍,思考原作者從什麼樣的角度來看待所謂的單元測試 (unit test)。

文內有提,他純粹從經濟 (economic)的觀點來看待測試,然後接著從三項因子:成本 (Cost)、速度 (Speed)、信心 (Confidence)來比較 整合測試 (integration test) 與 單元測試 (unit test)的價值。

他的結論是認為:整合測試相對來得有價值許多。🤔

然後接著他再用 投資報酬率 (ROI, Return on Investment)與 程式覆蓋率 (Code Coverage)來佐證 整合測試 的高投資率。

這就讓我更肯定了,原作者是站在專案經理人 (PM, Project Management)的角度來看待整合測試,PM 最是偏好用指標來衡量投報率與顯性價值等。

問題是,投報率、覆蓋率等這些指標,是極難衡量隱性的因子與其所創造的價值啊! 試想想,該如何衡量軟體產品的彈性度、擴展性與維護性議題呢?

再則,整合測試與單元測試根本是兩種不同的構面與不同角色的人所負責的:

o 整合測試:產品釋出 (release)前涵蓋所有元件的測試,一般由 QA 品管專職人員擔任。

o 單元測試:系統開發期間對必要 (essential)性類別 (如 控制物件、資料存取物件、企業物件等)的測試,這必然由撰寫該類別的開發人員負責撰寫,不得假手他人。

閱讀全文 »

軟體工程師與軟體設計師有什麼不同?

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

看到這篇文章:「What’s The Difference Between a Developer and an Engineer?」。這篇文章試圖比較 "軟體工程 (engineer)師" 與 "軟體開發 (developer)師" 的不同點與各自所需技能為何。

Software Developer 我覺得也可以稱為 Software Designer,同為設計原意。

若是我個人的解讀,軟體工程師比較著重在 "How-to" 的實作面。他會深入探究各類技術框架與工具的使用,舉凡 UI端 Javascript-based 框架、底層系統層級的技術框架、甚而包括了 3rd party 的 utiltiy 類型的 library 等;同時還有各種開發工具的精通。

軟體設計師,則會比較關注在 "What & Why" 的思考創意面。文內有提,設計師更會加強在心智上的修煉,包括自我學習、探討、觀察、閱讀等軟性功夫上 (不一定馬上就能應用到實務工作上)。

閱讀全文 »

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

*** 本文同步發表於 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 的文化,從發想到創意的實現,一切自造,需整合相關軟、硬體知識,並從過程中持續學習與修正不足之處。

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

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

閱讀全文 »

關於軟體需求變動的一個小案例思考

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

一個發生在昨天輔導單位的一個小小的案例,應該也可以藉此讓許多開發人員反思下...。

某一技術高深的程式開發人員 (就簡稱 PG)對一已進行開發至一半時間的專案,突然 User 代表 (關係利益人,就簡稱 User)丟了一個針對要計算折扣代碼的邏輯的需求進來,而且看來好像挺複雜的樣子。

PG 心態上不是很愉快,都已進行至一半,現在才突然有這樣的需求,需要為此多花一至兩天的時間來撰寫它,而這會影響到既定的上線時間。

嗯,我的判斷是當然會多花一時間,但不至影響到預定的時間。心態上的不適 (為何這麼重要的需求到中後期才提出來)遠比實作的難度大很多!

我能作的是什麼? (在這個極小型的專案我兼職擔任 PM),幫開發人員多爭取一天的休息時間,讓他們心理好過些。

然後昨天這位 PG 花了很多時間在撰寫相關這邏輯的實作,甚至很認真的透過 SA 與 User 提相關的問題。

嘿!這時刻我給他制止了。。

閱讀全文 »

簡述何為瀑布式 (waterfall)軟體分析設計文件?!

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

什麼叫做「Waterfall (瀑布式)」文件?

就是文件整理看起來很用心的樣子,經由不斷地開會與確認諸多細節,然後在某次的會議決定階段告一段落,就給予該文件一個版號 (0.1, 0.6, 0.8 .....)。

所以,一個功能模組或作業流程,經過了幾次的版號更新,最終總算得以定案,然後再交付給 PG 據此撰寫程式碼。

不管大或小的單位,稍有組織性重視文件設計 (得以保存與傳承企業資產,其實是好事),幾乎就是採以這類 "瀑布式" 的開發模式。

如果這樣能順暢移轉至程式寫碼,那當然沒有問題。但是,需求分析其實是一種假設與期望,越是要求精確,越是不容易釐清。

那麼,為何精確度的細節非得要在文件分析階段就要求完整呢? 為何不搭配每一個階段的文件分析告一段落甚或當下就寫成程式碼呢?

每一次版號的演進,文件與程式碼從功能框架的較大目標範圍,再逐漸地往細節 (即精確度)貼近。

簡而言之,設計文件與程式碼本來就是「一體兩面」!設計文件引導程式碼的開發;程式碼的修正更新文件原來的假設。

所以,現實上當文件的版號制訂為最終版時,那麼,程式碼應該也是接近完工了。

為何不這樣作?這樣不是輕鬆又愉快? 其中一個很大的問題就在於,諸多實作的程式開發人員不太容易掌握所謂的「不確定性」開發態度。也就是說,如果沒有提供很精確的細節,開發人員已經不知道要如何寫出程式碼。

總之,各類角色的開發人員,對於軟體開發的最重要修煉就是要懂得先學會如何抓到「大」的主題 (topic),再來才是往「細」的程序/邏輯/欄位 作精。

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal