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

*** 本文同步發表於 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才到了彰化市區,馬上就入住飯店內。下圖是隔天白天時拍照的。
彰化市福泰商務飯店

繼續閱讀 »

簡單聊聊軟體設計的 SRP (Single Responsibility Principle) 原則

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

SRP, Single Responsibility Principle (單一責任原則)

這是上星期課堂中,當我解釋 Multi-tier MVC 分層結構時,聽到學員告訴我的。

哈,這是我第二次遇到學員有告訴我這個術語,看來都蠻熟悉 Martin 在 "Agile Software Development, Principles, Patterns, and Practices" 一書內所提到的幾個軟體設計原則。

不過當我問他們工作上是否至少有把 UI 與 Logic/Data Acess 層分離? 沒有!還是全都攪在一起,沒有人講究上述分層的 "基本責任分派"。

沒有「知行合一」,確實實踐並從實務中體會與調整作法,那麼,學會 "背" 這些術語是沒啥用處的!

其實也只有一個字需要真正了解:責任 (responsibility)。

o Web UI (view & ui controller) / Standalone UI:Presentation (只負責傳送與回傳已運算資訊)。

o Domain Controller:負責控制流程 (control flow)。

o DAO (data access object)/ Adapter:負責連結資料庫/外部系統。

o Entity (或稱 business) Object:負責處理邏輯運算。

確實理解 "responsibility" 這個術語可不是用背的,而是身體力行,從過程當中去體會該術語的「真諦」。

從原點出發,一個詞彙可通一堆觀念。如當確實做好單一類別的責任分派時,所得到的效果就是「高內聚力 (high cohesion)」—責任明確。

軟體開發工具越是易用強大所以不需要作設計?

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

昨日與一位業界的前輩喝咖啡聊聊 (兼談合作事宜),他是國內頗負盛名的 CMMI 輔導認證的顧問。

雖是相當資深且擔任多家知名大企業的顧問,但仍孜孜不倦,時程總是排滿,利用空檔時間至許多技術課程單位當學生,藉此了解下業界採用所謂的方法論/新技術...等。

他分享了兩件軼事:

  • 他至台大上 C#.NET 語言入門課程,有約40來位的學員上課。
    講師竟然跟他們說,現在系統開發根本不需要設計,只要會操作工具、拉一拉畫面,簡單的下幾個指令,就可以很快速的產出應用程式。
  • 他上某單位現在最夯的 SCRUM 開發流程課程,講師拿它與其它方法論比較,甚至還嚴重的批判,而其中更是包括了 CMMI (顯然誤解,它並非是流程方法論)。

    這位前輩很感慨甚至有些不悅,尤其是批判到他的專業領域-CMMI,明明就只是一種制定達成目標的框架而已,怎麼會是拿來與 SCRUM/Agile 等相提並論呢?

他認為講師應該是擺在以該課程的主題為中心來傳授相關知識與技能的,但怎麼能對自身並不了解的領域妄下斷論/批判,進而傳達非常不正確的觀念,這豈不是誤人子弟呢?!

哈,其實軟體業沒啥新鮮事,這些見聞也都早已習以為常了。尤其是隨著系統開發廠商提供的工具/機制越完善,雖然可以大幅減低開發的時間,但卻也造就了軟體人員的墮落,過度地依賴這些工具的使用,卻少有思考軟性較具本質性「虛」的那一面向

我與那位前輩稍微解釋下,針對第一點,講師只要稍微修正下講法即可。不是不做設計,而應該是說抱著「簡單設計 (simple design)」的態度 ,事後再佐以「重構 (refactoring)」來逐漸修正調整,快速的 I&I (iterative & incremental)以構成設計/實作一體的開發循環。

設計是必然會做的,但該講師顯然誤解所謂的「設計」是那種以往 (其實現在也很多單位是這樣做)要做仔細規劃、產出一堆文件卻不適用實作的 Waterfall 方式。

至於 CMMI 與 SCRUM/Agile/RUP 等方法論之間的關係,我在9年前就曾發表過「利用 UML 類別圖表達 CMMI Content 與範例說明」。

其實簡單的說,因為 CMMI 只是制定各等級所謂成熟度的目標框架,但它並沒有提供要如何 (How-to)達成 (achieve)的作法;如何達成正是這些方法論可以提供的,所以其實把 CMMI 視為 Interface,上述方法論視為是實現 (realize)該 Interface 的具體性類別 (concrete class);兩者可以形成很好的互補,並非是拿來比較、相互衝突的。

第 1 頁 / 共 242 頁123456789101112...203040...最後一頁 »