不能為自己找藉口

最近與許多軟體開發人員相互交換心得與討論。發現,絕大部分的朋友們並不是很快樂。
問他們原因,因為覺得「軟體產業」這個環境不太成熟,所做的工作很無奈又沒有成就感。

所以,只要會發出 “唉” 叫聲的朋友,我都會建議買最最有幫助的一本書:「吃了那隻青蛙」。吃多了青蛙,就可以治好你的 “唉唉” 聲了。 😉

一位朋友,他想當專業顧問,倒推回來,他也知道該提升管理能力與技術能力。但,要如何做、如何進行,他就說了:
“因為產業的不成熟,專業顧問不容易生存;因為要顧到生活,不敢下定決心踏出第一步;因為…所以…等等等。”

說真的,到哪一個單位,幾乎都有上述提及的情形,要嘛就怨大環境不佳,要嘛就覺得待的單位不理想,要嘛就嫌豬頭老闆 …等等。

我是覺得,幹嘛那麼不快樂?
這些所提及的都是事實,但是,怨東怨西對個人有什麼幫助?
說難聽點,這些理由都是為自己在找藉口。

自己的命運決定在自己手裡!
與我現在所待的環境有何關係?這些都只是一種必經的過程而已。

產業環境的不成熟? 那不是更好? 更有個人所發揮的空間。
公司待的不愉快? So What? 一皮天下無難事,會有比在軍中還更無奈嗎?屆時拍拍屁股走人,又是一條好漢。

唉聲嘆氣、為自己找太多的理由與藉口,這才是最可怕的,因為會怠惰心智、會妥協於現實。慢慢地,意志消沈後,就像籠中鳥關久了以後,再也不敢展翅高飛了。

No Execuse!! 不要再為自己找藉口了,那只會傷害到自己。
快樂一點,想到軟體業界處於混沌的亂世,我就更開心,因為,更有機會嶄露頭角了;想到軟體設計是那麼好玩,就如同看漫畫那樣地愉快,然後,又能靠這賺錢。哇哈哈,真是開心~

至於現實的經濟生活? 當然要兼顧囉~
從 “你想要什麼” 倒推回來思考及規劃,大概可以找到 8萬四千種方法來賺 “安家費” 。所以,看來,我覺得也不是大問題。

做有趣的事、又能幫助到別人、還能賺錢。我是一直朝這個 “三贏” 的方向在走的。
至於現實工作的不愉快或經濟生活尚未達到足夠的水平,那都只是一種過程。不要以為這是磨練或吃苦,我反而覺得這些過程是一種享受、是一種樂趣。
堅信自己會到達所設定的目標,往那個方向走,多跌到幾次。生活就是充滿了這麼多的刺激與樂趣。

{UML2.0} Component Diagram 簡單說明與範例

Component(元件) 圖:

  • 元件圖專注的焦點有二個:
    • 元件所提供的介面(Interface)。
    • 元件之間的相依性(Dependency)。
  • 與業界推導的規格,如 COM+、EJB …,並沒有直接的關連。
  • 元件,其本質其實就是物件!但最大的不同點在於:物件強調的是 “個體(Instance)” 的特徵及外在行為;而元件強調的是 “介面(Interface)” 的溝通。
  • 元件的單位有大有小:
    • 顆粒度細緻(fine-grained)的元件,會比較接近本質性(Essentiality)、單一性(Atomic)。所提供的介面是屬於高度穩定的。
      *** 領域物件(Domain Object),係源自於該領域所經常溝通的術語(terminology)。
    • 顆粒度粗糙(coarse-grained)的元件,也可稱之為聚合(Composite)元件,是基於完成某項功能或為提供服務而聚合了欲完成該功能或服務的多個 “Part” 組件來達成任務。其所提供的介面是較不穩定的(功能會基於需求而善變)。
      *** 模組(Module)、子系統(SubSystem)等,即為功能性的元件 — 基於服務或功能而形成的聚合元件。

UML 2.0 Component Diagram
(縮略圖,點擊圖片鏈接看原圖)

傷腦筋的 “How-to” 問題

這兩天,有許多位網友加入我的 msn 聯絡人,我挺開心,也喜歡與他們透過 msn 溝通對軟體設計等的想法。

才剛寫完一篇:「甚麼是 “How-to”?」。
結果這幾天,很失望,問我的盡都是 “how-to” 類的問題,還是與軟體一點關係都沒有的…
我覺得,這些網友挺不尊重我的~

例如,有個網友問我:

下午 11:51:54  ... 寄密件副本 一般郵件原始檔會被加密 
下午 11:52:07  ... 有辦法可以反解回來看出寄給那些email 嗎? 

又有位網友問我:
架設 Blog 的頻寬架要多少? 該申請多少頻寬來架設 Blog 才夠?

唉! 這類的問題,利用 Google 查一下不就可以找到資料?
例如,打個關鍵字:”密件副本” and “加密”,可以找到一堆的參考資料。
又如,打個關鍵字:”Blog” and “頻寬”,不就可以找到一堆架設 Blog 的頻寬參考資料呢?

很奇怪,真的很奇怪,為什麼連最基本找尋資料的意願都沒有呢?為什麼都想抄捷徑直接問這類的 “How-to” 呢?為什麼我會被視為是回答這類 “how-to” 的人呢?(這點我覺得最可悲)

當然,這些網友不是無心之過,我想,他們的生活應該與朋友們經常相互之間會問這類型的問題。

但是,相對地,我也該思考學會如何 “婉拒” 這類 “how-to” 的問題,該如何 “引導” 他們找尋自己所需要的資料。

他們可能以為這些問題我都會,殊不知,我幾乎都不會。只有當需要的時候,才會去找資料參考。”用完” 後我也就都忘記了。

什麼叫 “How-to”?

“How-to”,中文翻譯叫做 “如何”。例如底下的句子:

  • “如何使用” Mindmanager(心智圖工具) 畫心智圖?
  • 如何讓 JSP/Servlet 透過 JDBC 連結資料庫?;如何實做 EJB(Enterprise Java Bean?

“How-to”,是一種程序、是一種步驟,基本上,照本宣科,依照指導手冊或既往經驗,不需花太多心思,即可完成工作。

尤其,現在 “How-to” 的取得來源太多太多了,透過 Google,要找到程序文件、範例等…太容易了。

“How-to” 是站在 “用” 的觀點,如何 “使用” 某種工具,用得好,用得熟悉,能達成使用的目的就可以了。

“How-to” 重不重要? 當然,因為會增加我們在生活上的便利,例如開車,就是一種 “用”。

但是,若站在 “軟體設計” 的角度,那麼,”How-to” 可就不是最重要的了。

為什麼?因為,”How-to” 會讓你忘卻設計的本質;會讓你沒有自己的思維;會讓你少卻反思的能力;會剝奪你創意的天賦能力。

設計之所以為設計,也就在於能把自己的想法表達出來,無論對錯,自然會有回饋的建議與修正。

看過大陸某網站所提的一句:「軟體以用為本」。
個人覺得從使用者的觀點來看,無庸置疑;但若站在軟體設計者的角度來看,可要千萬慎思!從 “用” 的角度來開發系統,往往只會看到系統的 “外觀”,而忽略掉了系統的 “結構”。

不要以為,UML 就是設計;程式就是 “How-to”。
不然不然。業界充斥著太多這樣的假象了。

沒有自己的想法、沒有反思的能力、照本宣科,依循某書本或某專家的話來做…。這些才叫做 “How-to”。

舉一個例,透過 msn,問了一位朋友,什麼是 “Sequence Diagram”?
沈默了一會他回答:”表示某一個任務經過物件的順序 及使用時間,還有相關訊息流的傳遞”。

他的回答對不對? 那是最標準的定義,但是,一聽這個回答,我就很清楚,這位朋友沒有心中自己的想法。
為什麼?那是書本作者必須對大眾讀者有一個很明確的 “定義”,所以必須用很沈悶的工程語句來做敘述定義。大多看了書的讀者,就背了一大堆這些無聊的定義,卻沒有花心思於潛伏於定義背後的 “哲理”。

若要我回答,我會很肯定的 “說出” 我對 Seq. 圖的感覺:
“一群物件之間的互動合作完成所賦予的任務”。
這還悶了點,更簡明一點;
“一群演員照劇本演戲”。

對不對? 那不是我最在乎的。說得不對自然會有人來 “指正”。
我所在乎的是,有沒有真正說出心中自己的體會。

軟體設計師,要多花心思於 “What” and “Why”。這些,非僅從書本的知識得來,更需要從生活中體會、觀察、保持好奇心,多花時間與自己的內心對話… 才能有自己的體悟。

例如,有人問我要不要教授 EJB?
若是 “How-to” 對 EJB 的實做,那確實六個小時就可以學得了的。
但是,我非常懷疑他學 EJB 的目的。問了他:學 EJB 的目的是什?又,到底,你認為什麼是 EJB? 他回答不出來。

我也曾經問一位很 “高竿” 的 Java 工程師,EJB 的目的何在?他覺得理由是 “ReUse”。
這是一般 EJB 的技術書籍及規格的制式答案。
是嗎? 那麼,難道,使用 Java Object 就無法達到 “ReUse” 的目的嗎?

其實,重點不在於是否 EJB 是以 “ReUse” 為目的。而是在於是否我們真有用心於思考這些書本所提的 “定義” 或 “說明”,有太多…,充斥了 “表象” 與 “假象”。

做一個簡單的結論:

  • 會 UML、懂 “物件導向” 等 “技術”, 不代表你會軟體設計,就是軟體設計師。(簡單的判斷,若無法以最平常的生活化例子來解釋 UML、物件導向,那麼,我不太相信他懂軟體設計)
  • 程式開發不代表 Programmer 沒有將軟體設計蘊含其內。
  • 不是擔任 SA/SD、Architect、Designer 等角色就是軟體設計師

所以,到底什麼是 “軟體設計”?
肯 “思考” 的人,就是軟體設計師。
也就是說:
當你自己能具備自我的思維、反思,並懂得回饋互動時,你就是軟體設計師了。

而這些,都是每一個人與生俱來的天賦能力。
我們所要努力的,也只是將這與生俱有的天賦能力給激發出其潛能而已。

{UML 2.0} 關聯類別(association class)

一般 UML 書籍對 “關聯類別(assocation class)” 的定義及說明如下:

  • An association class connection is a UML construct that allows an association connector to have attributes and operations (features).

「UML Distilled」一書提及:關聯類別(assocation class)允許你在關聯上面增加屬性、操作和其它(類別)特性。

書中所舉參考範例如下圖:


圖一 關聯類別 — 摘錄自 "UML Distilled 3rd edition"

文中說明為:從圖一,我們可以看見 Person(個人)可能會參加很多會議。我們必須保有這個人對這些會議的出席情況:藉由新增一個 attentiveness(出席意願)屬性到關聯上,我們可以達到這個目的。

說真的,我對以上對於關聯類別(assocation class) 的定義及說明並不盡滿意!

閱讀全文 »

軟體思維顧問

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

Personal