論「當程式員不如賣香雞排」一文

今晚洗澡時,突然想到許久之前網路廣為流傳的一篇文章:「當程式員不如賣香雞排」。
內容道盡了在台灣軟體公司擔任程式人員的辛酸與無奈。
雖知道該文是以暗諷的方式來說出現今軟體業界的不合理與畸形,但總感覺,該文作者不會以為寫程式就是軟體的一切了吧?再則,在如此惡劣的軟體產業環境,是要放棄?要選擇出走?或是也可以選擇發下 “悲願”,努力來改造這個產業環境呢?

藉由該文,也來說說個人的一些看法...

對於該文內容,我個人是覺得:太貶低其價值了...

別誤會,不是貶低程式員的價值,而是貶低、看輕了賣香雞排的 “難度” 了。

我認為,賣香雞排比當程式員困難得太多了...
理由為何?

賣香雞排是屬於「個人企業」,個人是老闆也是員工,所以十八般武藝全都要會...

產品製程方面,要能炸出好吃的香雞排,又要便宜、又要大碗、又要讓顧客口齒留香、口碑相傳。在素材、料理烹調的過程中,可是不能馬虎的。

行銷方面,如何吸引顧客、如何與客人打哈哈、如何找到一個好地點、如何做出獨特性、如何讓口碑傳出去...等等,這可都是要花腦筋去思考的。

財務方面,在如此低廉的售價要能賣出超大塊的香雞排,又要支付固定開銷,包括攤位租金、素材(雞、太白粉)、沙拉油、雜支開銷等,每天一開張就要開始算計今天該賣多少香雞排才夠攤還成本,壓力是挺大的。

體能方面,嘿,攤販老闆們個個可都是體力超強。不能只單看營業的 6 個小時,還要看為了營業之前的準備工作、營業之後的收攤、採買等,一天沒有 12 小時怎麼會夠呢?

所以,要當一個 “稱職” 的香雞排攤販老闆,每個構面都要考量的,從產品、策略、行銷、執行力、人際關係等,都要面面俱到的。

至於當程式員,是屬於 “雇員(Employee)” 層級,所以,基本上,只要專注於:「完成上司交付的工作(Task)」即可!!
與賣香雞排老闆們來比較的話,工作性質單純得太多了。

擔任程式員,只有兩項挑戰:對外,如何應付上司;對內,如何應付寫程式。

如何應付上司,最重要的是 “心態問題”:千萬不要內疚於辜負了上司對你的 “期望”。

根本事實是,上司所交付的工作,絕大部分本來就不合理,要超時加班、薪水又低、又不重視軟體的品質與管理(別傻了,台灣的軟體公司老闆們幾乎都是業務出身的,哪會真正關心軟體?),熬夜加班工作,傷了身體,產出的卻是 “Dirty Job”,若像竹科的硬體代工的工程師們,忍受不愉快的工作環境,起碼還能換取股票,還勉強說得過去。

所以,如何應付上司,第一個是 “心態” 問題,”一皮即天下無難事”了。
再來,更積極一點,就換成是程式員本身如何 “選擇自己的老闆”,關於這點,個人之前也寫了一篇文章:「你要投資哪一種老闆?」,可以參考。

至於對內,就是如何應付 “寫程式了”。

若程式員所認知的軟體就是 “寫程式”,那麼,所看到的就只是 “Web Design”、”.NET”、”Java”、”PhP”、”MySQL” 等諸多工具(Tools),來協助完成你工作。
在這樣的層級之內,哪還挺容易的,就是學會如何善用這些 “機絲”即可。

學會寫 Java 程式,困難嗎?懂得英文基本文法,懂得基本程序(Procedure-based)操作,懂得善用 Google 找範例,在這個時代,連書都不用買,只要透過網路把這些 “基本操作手冊” 看完就好了。

簡而言之,程式員被分配到的,大都是 “Task”,只要 “應付上司”,”寫程式 — 完成 Dirty Job”...就可以安分地領固定薪水,難度比當賣”香雞排” 攤販老闆們容易地太多了。

但若知道 “寫程式” 並不等同於 “軟體”,要能有 “柔軟(Soft)” 的思緒才能通往 “軟體設計之道” 的彼岸,才能把 “軟體” 做 “軟”。

太多人以為寫程式就是 “軟體(Software)”,殊不知,程式產出、是軟體的表象。
就如同在「富爸爸˙窮爸爸-提早享受財富<2>」一書中,提出的「B-I 三角形」構面,雖然「產品」是位於 B-I 三角形最頂尖的 “呈象”,客戶最終也是要從企業買走的是企業產品,但若沒有底層背後的機制支撐, 包括領導、管理、溝通、系統、法律、財務等,會可能做出好的產品嗎?況且,很多人能做出比麥當勞更好的漢堡,可是能有幾個人能夠建構出一個比麥當勞更好的商業運作系統呢?

所以,個人的基本結論是,程式員有兩條方向可以選擇:
停留在原地,繼續追逐那些所謂的 “技術”,卻有可能不知不覺讓自己的頭腦僵化掉,又怨天尤人,覺得沒有伯樂來賞識;
另外一條路,努力讓自己 “向上提昇” 吧,學習各項領域的知識,包括生活、哲學、歷史、天文、企管...等,並將其他領域的哲理帶入軟體設計的領域內,就會發現到軟體與生活是一體的,是息息相關的,是那麼有趣的,而不是所謂的那麼的 “技術化” 的了。
當瞭解若選擇 “軟體設計” 之路前進時,就會發現到路是無限地寬廣,工作不再是只有充斥著 Java、.NET 等沒有”人性化”的工具而已。

恭喜你,此時,你已不再只是 “程式員” 了,而是 “軟體設計師(Software Designer)”~懂得將設計的美學融入現實的軟體產業技術。

創意可以無限地發揮,而技術會被汰舊換新,但軟體的成形會因為無形的創意設計發揮而更能生意盎然、生生不息。我想,這也就是吳清源大師所說的:「中和之道」了吧。

至於程式員考慮轉行賣香雞排,強烈地建議,不要自討苦吃了,要懂得的構面太多太多了,當自己的老闆絕對是不輕鬆的。

在此,也向賣香雞排的老闆們說一聲:您辛苦了,如此艱鉅的行業,非我爾等所能勝任的。

【專案】Prototype by OpenWFE

最近協助桃園縣某技術學院的系統開發。

一個小案子,基本要求是使用 Workflow 系統來做簽核,Java-based,最好是 Freeware(因為案子的經費有限)。

主要是協助他們 survey 使用哪套 Workflow 系統、並撰寫 Prototype 來打通相關的技術關節。

Survey 結果,個人是偏好使用 OpenWFE
OpenSource、可以被包裝成商業產品出售、相當漂亮的架構(分為四大塊 Component:Engine、Worklist、Reactor、WebClient)。

OpenWFE 是定位於 BPM(Business Process Management),又來得比 Workflow 的架構層次較高一層。

亦即,從 “Manager” 的角度(View)來操作時,只要利用 UML 中 “Activity Diagram” 定義好 “Flow Definition”,而後端的 Workflow 系統即會 “Realize” 每一個 Activity。;
而從 “Technical” 的角度來看時,即是要如何去 “Realize” 每一個 Activity。

ss-droflo-flow_1.2.png

該系統非常漂亮的是,完全以 xml 的方式來做設定(系統、Flow Definition)及資料傳遞(Form),相當地棒!!

架構雖漂亮,不過,要 “客製化(Customize)” 的地方粉多...
例如,要提供 “Web Service” 功能時,我們可以 “Extend” WorkSession 元件(目前版本僅提供 RMIWorkSession、RESTWorkSession),設計一個為 “SOAPWorkSession” 元件,好處即可讓 ASP.NET 的 WebForm 透過 WebService 來呼叫 WorkSession 元件了。

整個架構現在大致已瞭解了,為了完成此 prototype 的開發,現在剩下的就是改寫 WebUI 這部分了。
WebClient Component 是以 “STRUCTS” Framework 為底層的框架,這部分個人比較陌生,大概也要花幾天時間才能 “打通” JSP->STRUCTS 的關係。

等整個 protype 開發完成後,再把心得及開發步驟大致列舉出來。

物件導向的軟體設計觀

由於軟體開發廠商致力於提供更好的物件導向化的工具,包括從物件導向程式語言(OOP,C++、Java、VB.NET…)至使用者端介面的開發工具(圖形元件化,如 Button、Textfield、Form…,乃至模型化的工具(Rational Rose for UML)。似乎,採取了這些工具,軟體開發人員就得以享受到物件導向化軟體開發的美麗新境界,得以脫離傳統軟體開發方式的夢魘。

殊不知,物件導向化的開發設計並不是萬靈丹,並不是採取了物件導向的技術,就能簡化軟體的設計 ; 再則,物件導向設計的思維,也不是由 UML、OOP、Tools 等這些表面所獲得的知識就可以能理解的。

物件導向化的軟體設計是從真實世界上人們面臨問題時,所運用的哲理及技巧來解答問題,將這些智慧及經驗的累積,來反應至軟體的設計思維。所以,並不是因為有了所謂的 “軟體” 才會有 “物件導向” 這樣的技術產生,反之,如何運用前人為了解決生活上的問題所累積的智慧及經驗,甚而創造自己的智慧,並將經驗傳授他人等這些技巧來反應至軟體的設計思維,才是軟體開發人員所需具備的涵養。

例如,介面(Interface)的設計,老早在現實的生活上隨處可見,好比,設計了雙孔插座,使得家電用品不需要知道內部複雜電路的設計,只要依循其規格:雙孔插座、110V 電壓,任何家電用品即可享用其共通的規格,造成了多型(Polymorphism)的效果,進而增加再利用(Reuse)的好處。

但反映到軟體的設計上,大部分的軟體開發人員卻沒有體認到介面設計的好處, “Design Pattern” 一書即提到:

「介面是物件導向系統的基石。想辨識物件,只有靠介面這條路 ; 若不知道介面,便無從得知物件的資訊,也無法叫它作任何事。物件介面並不含任何實做事項 – 物件有權自由決定該如何實做這些操作,因此,兩物件即使介面完全一樣,也可能會有完全不同的實做。」

為何需要這些生活上的哲理來輔助軟體的設計呢?主要的原因也就在於 “變” 這個因素。因為 “變” 造成了軟體系統開發的障礙,提升了複雜度、增加高度維護的成本。如果軟體開發人員一直無法認清這點,一直想以逃避的方式來凍結 “變”,既不合情合理、沒有人性化,也使得軟體系統無法順應善變的需求 ; 反之,若能認清 “變” 的本質,進而擁抱 “變” (Embracing Change),使得軟體系統能生意盎然、生生不息,而提升了軟體系統的高度價值,這反而因為 “變” 而帶來了更巨大的經濟效應。

兩段式 RUP 的開發綱要

e-化的 Business 系統的特色即在於強調分散式(Distributed)的架構。而分散的系統又必須整合以建構完整的企業服務(Business Process),並期能達成快速組裝流程來因應顧客的需求(Requirements)。

在現今新潮流的分散式系統的特色又凸顯了:

● 每個 Site 是為整體系統的子系統(Sub System)的一份子。

● 子系統之間有依存性(Dependency)的關係,此種關係是為一種動態的服務需求來建立的。而提供動態的服務則以 Web Service 來串連。

● 子系統很有可能是各種異質性的系統建構的,所以不能僅使用某種廠商所提供的分散式技術,而必須採取更具標準化的分散式交換資訊的標準。所以這更凸顯了以 XML、SOAP(Simple Object Access Protocol)等元素所組成的 Web Service 的價值:XML 提供了結構化來訂定資料交換的標準 ; SOAP 提供了架構於 HTTP 之上的一種簡易交換資料的通訊協定,利用 URL 即可在不知所提供服務的系統的實體位置狀況下,此稱之為位置的透明化(Transparent),能以簡單的 領域名稱(Domain Name) 命名來與對方溝通。

● 不能假設所有的子系統都是由自己來建立的,有可能有些子系統是需要外包(Out Sourcing) ; 或有些子系統是已既存的(Legacy System)。所以對於子系統之間的整合,我們是強調於介面(Interface)上的整合,而不是與內部的實體系統來聯繫。可以想成每個子系統都是一個可以獨立運作的有機體,有機體之間是利用觸角來相互溝通。此觸角(Interface)是對外溝通的唯一管道,對於有機體內部的結構,外部的系統不需也不必知道其細節。

分散式系統具備了上述的特色,這使得我們對於分散式系統的分析及設計上的開發流程(Development Process),勢必做一些修正,其主因在於傳統的分析設計假定於:

● 將欲開發的問題領域(Problem Domain)看待為一個完整的系統。

● 因為看待成為完整的系統,所以都假設從分析、設計乃至實做不太考量到分散式的問題,也因如此,就可能僅會是一張完整的類別圖(Class Diagram)。

● 傳統的分析都是建基於從已知的需求來取得領域上的知識,並據此來建構類別圖。但是提供 Web Service 的分散式系統,常常必須在不知道 User 需求的前提下,也要能提供服務。如何在未知需求的情況下來分析系統,就變成了是分析師非常大的挑戰了。

先整合各分散的子系統,將其觸角連結起來,以快速提供動態完成的服務給顧客是分散式系統最大的特色。相對於不同以往先假設一個完整的系統,再去切分再整合的手藝有著完全不同的開發流程的思維。

所以在不違背 RUP(Rational Unified Process)的基本精髓下,我們需考量修正 RUP 的開發流程步驟來因為現實分散式系統的架構。

在此,提供了所謂兩段式 RUP 的開發流程:

第一階段先將焦點集中於各分散的子系統的整合,以建立一致性的架構(Architecture)。這也正符合了 RUP 的最重要的基本準則:Architecture Centric(First)!

然後第二階段則依據在最抽象的整體架構思維上,從外部的 Actor(如顧客)所觸發(Trigger)的 Use Case的需求分析上,可以據此來得出許多個小的 Use Case 分佈在各子系統上,串結合作以達成顧客的 Goal。開發團隊,就針對此,來針對各個 Sub System各自帶開,各自表述,依 RUP 的四大階段及紀律(Discipline)來做分析及設計,以實現(Realize)該 Sub System 所負責的 Use Case。

此兩段式的 RUP 開發流程是以反覆式(Iterative)的方式來漸進循環的。也就是說,先建立整體的雛形架構(Architecture)後,每個負責實做子系統的團隊必須定時的回報(Feed Back)以驗證該整體架構的一致性及完整性。如此反覆循環,才有可能建立一致性、整體性、和諧的分散式系統。

Re:解讀『XP軟體製程』的字面意涵

點空間一位網友對本篇解讀『XP軟體製程』的字面意涵蠻有獨到的見解,故收錄參考。

就字面而言, 譯為 ‘極致’ 或 ‘極端’ 似無不妥.
但卻無法凸顯那 ‘magic letter X’ 的意涵.
(X 意味著; Uncertainty, Goal, .., and God’s promise.)
直譯的過程, 失去了原作者的匠心,
畢竟是 ‘eXtreme’ 而非 ‘Extreme’

至於 ‘最善 (perfection)’ 也並非 XP 之旨
反倒是 ‘刀口 (edge)’ 方頗具 XP 之趣.
That is, the edge of the chaos.

Iteration 的真諦在於 Timed-box 而非 Decomposition,
重點在於 produce business values, 意近 ‘commitment’
乃制衡 Agility 與 Discipline 不可或缺之器. (或云 Risk Control)

XP 所闡述的是 ‘執簡御繁’ 的心法(Culture)而非招式
故不宜單就 ‘方法論’ 的層面比較之.

或許多餘, 但還是值得一提;
Test-first 的妙用在於 discover alternatives that fulfill the requirements.
Refactoring 的可貴在於 facilitate simplicity that achieves beauty.

明遠, July 13, 2004

軟體設計與交易<2>-What is Transaction?

資訊系統的設計,只有良好的 OOAD 是不夠的,同時也要考慮到分散式系統的現實環境,其中,Middleware 要能確保有穩健的交易環境是相當重要的,所以,對於 “交易(Transaction)” 這個術語,需要有清晰的瞭解才行。

在商業上, ”交易” 係指兩個契約當事人之間的一種交換行為。例如,向小販購買冰淇淋甜筒,是以金錢來換取零食 ; 在一家公司工作,是以技能及時間來交換金錢。
在交易的過程中,會試圖來保持交易的穩定性,也就是說,你會確信交易能符合雙方的期望,所以商業交易的第一法則定律就提到:

「Every movement of commerce in one direction is accompanied by an equivalent movement in the opposite direction」
(每項朝某個方向的商業行為,必然伴隨一個等值但是反方向的商業行為)

例如,您投一塊錢到公用電話機,電話公司就讓您通話三分鐘,這種商業活動是等值但呈相反方向。這符合商業第一法則,雙方誰也不欠誰,皆感到公平合理。萬一您投了錢幣,卻被電話機吃掉了,您會感到吃虧,就違背商業第一法則了。

在軟體系統上,交易就包含了商業上的交換觀念。針對企業資訊系統的交易,是一種 “工作單元(unit-of-work)” 的執行,以存取一或多個共享的資源(在實體環境上,資源經常是置於資料庫上),所謂的工作單元,就是一連串的相關活動必須一起完成。例如,向航空公司預購飛機票,”預購”的程序就是一個 “unit-of-work” 而組成許多的活動:記錄飛機班次及座位、信用卡刷卡(debiting a credit card)、產生機票,三個活動共組成一個 “unit-of-work”。

交易是存在於各種不同系統的一部份,而每一筆的交易,其目標都是一樣的:執行一串活動的 “工作單元(unit-of-work)” 而結果導致具可靠性的交換。

例如:
ATM(automatic teller machine):
主要功用為存款、提款、轉帳等。執行這些工作單元而成為交易。例如,執行提款的工作單元,首先,ATM 會檢查帳戶內的金額以確定沒有透支,然後再從你的帳戶內扣除該筆金額,並從 ATM 內吐出該筆現金,完成交易。

線上書籍及訂購:
例如透過 Web 向博客來訂購書籍,這樣型態的購買也是一種 “工作單元” 而發生了一筆交易。在線上訂購的過程中,首先鍵入了信用卡卡號,然後經由博客來訂購系統的驗證,費用就從信用卡上扣款,而書籍就經由郵局等掛號寄送過來,經由一連串的活動而完成了交易。

可以瞭解的是,交易是高度複雜並且經常伴隨的是訴諸於大量資料的操作,交易的過程當中如果發生錯誤,不僅僅是金錢的損失,甚而可能影響到身家性命!所以,交易必須要能保持資料的完整性,也就是說,每一次的交易均要能完美地執行該工作,否則就要回復到交易之前的狀態。

交易的四大特性
在高度大量資料交易的環境或者是 mission-critical 的系統,交易是不允許有絲毫的錯誤,因為這個理由,在交易服務領域的專家們鑑定了交易需要有四大特性的遵循才得以說這個系統是有安全的交易環境:

交易必須是 atomic, consistent, isolated, and durable (ACID)

Atomic
所謂的 Atomic,係指交易必須是完全地執行否則就根本不執行,這也就意味著在 “工作單元” 內的每一項工作在執行過程中皆不能有差錯,若任一工作發生錯誤時,則整個的 “工作單元” 或交易就中斷,所有已變更的資料必須回復為未修改前(undone or rollback)的狀態。若在 “工作單元” 內的所有工作皆執行成功,則該交易就被 “commit”,代表著所變更的資料需要永存到 Database。

Consistent
保證當交易完成後,必須讓系統的狀態保持一致性。何謂一致性的系統狀態?例如,在顧客完成提款的交易後,銀行系統的一致性狀態必須依循著 “客戶帳號的存款總額不能是負數的” 的規則。

Isolation
單一交易的執行不能受到其它程序或另一交易的干擾,也就是說,在該筆交易所存取的資料不能被系統的其它部分影響,直到交易或 “工作單元” 完成執行。

Durable
意味著在交易的過程當中所變更的資料必須在交易完全地執行成功前寫入到某些型態的實體儲存機制,例如 Database,而不會因為系統的當機(crash)而導致資料的遺失。

軟體思維顧問

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

Personal