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

** 本文同步發表於 軟體設計鮮思維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),再來才是往「細」的程序/邏輯/欄位 作精。

2016_4.14-15_彰化軟件兩日教學行

因為農曆年後彰化某國際鞋業代工大廠購買了 EA UML 工具數百套,同時也針對 RUP (Rational Unified Process)所提出的 4+1 View 請我們規劃三天的軟體教育暨工具使用的課程。

我負責前兩日的課程,授課日期就在上星期四、五 (14/15)。因為一大早就要上課,所以乾脆前一晚就開車下彰化,並先於彰化市區—福泰商務飯店訂房住宿。

軟體教學@寶成鞋業國際

上個星期幾乎全是下雨天,尤其星期三傍晚當我開車到新竹路段時,那個暴風雨下得超級大,加上天色已暗,有夠難開。所以大約開了兩個多小時晚上7:30才到了彰化市區,馬上就入住飯店內。下圖是隔天白天時拍照的。
彰化市福泰商務飯店

閱讀全文 »

軟體思維顧問

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

Personal