成為軟體工程師的前兩年我學了什麼?

看了這篇文章:成為軟體工程師的前兩年學了什麼? (What I Learned in My First Two Years as a Software Engineer) 個人也蠻有感而發。

其實我進入職場前兩年,完全與「軟體」這兩字無關。退伍後沒多久先到如同資策會的資訊機構,花了半年時間上了關於 MCSE、Novel CNI/CNI 等與系統管理面的認證養成班。我算是很積極的,上完課的同時就去考認證,接連考取了上述的認證執照 (共 10 來個科目)。

當年認證是很夯的,也還沒有被搞爛 (一堆考古題),所以我找相關系統管理的工作是還蠻容易的。不過我後來選擇擇了一家從事 Client/Server 系統開發的公司,他們在應徵資料庫管理師。因為我對該公司採用 Oracle 資料庫系統極感興趣,起因是上 MCSE 有一門 SQL Server 科目,我對裡面有個範例 (圖書館資料庫表格結構設計) 非常好奇與納悶,為何表格分析可以這樣環環相扣? 問了當時的講師他也不知道。 :)

總之,一進入該公司後,我向經理提出要到 Oracle (當年位於民生東路) 上相關資料庫管理的課程。經理也很乾脆,當年這類課程 (MCSE、Novel CNE) 要價可不斐,至少 5 萬以上起跳。我可是很積極的,從完全不懂所謂的資料庫是做什麼,到考取 Oracle DBA 的專業認證,只花了不到三個月 (每上完一堂課就馬上去考,共有五門科目),這期間 K 的原文教材可是有 3000 多頁,只不過當年學習熱忱洋溢,可說是相當享受那種成就感。

當年我可還是全台灣第五個考上 Oracle DBA 的認證,甚而 Oracle 台灣訓練中心經理想要挖我過去那邊上班,不過當年我還是樂於待在那家公司,也可說是感謝那位經理能給我教育訓練的預算讓我上課充實技能。

不過這樣待了一年,老實說,我對與「系統 (OS/Network/資料庫)」的相處發現興趣不太大,工作上只要把關好兩件事:備援與效能調校,那就相當輕鬆了。所以閒暇之餘,想要自行寫一個圍棋 (學生時代最熱愛的棋藝,也在圍棋協會昇上業餘初段) 對弈的軟體。我還記得第一個自學的程式語言就是 Java,為此我又在工作期間花了一個月時間買書用力 K 相關語法,然後又去考取了一張 SCJP 認證。雖然勉強可以「寫出來 (那時我還是用 Java Applet 寫的)」,但程式碼卻是「落落長」,非常沒有成就感。

就是那個時候我才第一次聽到所謂的 OO (Object-Oriented) 物件導向這類神秘的技藝,聽說會了它就可以解決軟體許多相關的問題。 (能解決什麼問題我也不知道 !^^)

反正當年我還特別跑到重慶南路位於2F的「巨擘書局」,買了五本 OO 原文的書籍,當然沒有一本看得懂。那時國內也出了一本「世紀末軟體革命」,賣得嚇嚇叫,理所當然也跟風買了一本,用力研讀內容覺得好像很神,應該是技術能力要相當高深才能看得懂,總之當年我就是看不懂在寫什麼。現在當然可以理解了,然後也才知道這本書內容其實言之無物的。 >_<

閱讀全文 »

「軟體需求分析與塑模」- 單一作業流程的塑模

本文收錄於 我的電子書「軟體需求分析與塑模 – 第二章、企業流程的分析與塑模」。

描述與紀錄單一作業流程內部的一連串活動,使用 UML 活動圖 (activity diagram) 是最為適切的。

依據 UML 三巨頭的論述,活動圖主要的目的在陳述活動與活動之間的流程控制的轉移 (control flow transition)。
Activity diagrams emphasize the flow of control from activity to activity. (《The Unified Modeling Language User Guide》, Grady Booch, James Rumbaugh & Ivar Jacobson, 1999, pp. 257)

這裡所謂的活動,可以指企業的活動,也可以指應用程式中的某個特定功能。

不過一般來說,由於「活動」的定義並不如「物件」那麼明確,因此,在進行系統設計時,一般比較不傾向於利用活動圖來表達應用程式的結構 (採用物件模型較為恰當);也因此,活動圖通常會比較適合用於表達企業活動的工作流程關係。除此之外,由於活動圖非常類似傳統的流程圖 (flow-chart),因此,活動圖也適於表達細部程式的程序性結構。

參考下圖,藉由一個請假作業流程來說明 UML 活動圖的主要圖形元素。

圖、請假作業流程活動圖的基本圖示語法

 

閱讀全文 »

軟體技術人員最愛卻也是尾大不掉的萬用 Database Manager 物件

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

上星期我在教授 TDD.NET 測試驅動開發課程。其中有位學員分享他們公司會計系統的部分程式碼 (沒有機密性議題),想知道這該如何撰寫單元測試 (Unit Test Code)。

我先用 EA (Enterprise Architect) UML 工具掃描程式碼反轉為 類別 (Class) 圖,老天!數百個 Windows Form (每一個 Form 他們稱為 Report) 全連接到一顆共用的 DB Manager,封裝了基本的 CRUD 行為,再存取資料庫。剛掃進來時還真嚇了一跳跳,那個 Form 的連線,有如積體電路般密密麻麻的共同連接到如同就是 CPU 地位的 DB Manager!

2tier universal db manager

這肯定就是典型技術人員的傑作,用許多稀奇古怪的實作方式,讓所有的表單 UI 程式,傳進來 SQL 敘述,然後再去存取資料庫。看似方便簡單,但這顆萬用的 DB Manager 已經被約束了特定的實作技術與特定的資料庫,所以當然無法抽換,原來他們使用 ADO.NET 的連線,現在是不可能換成 Entity Framework;不僅如此,內部程式碼的擁腫肥大,當時的技術人員一離開,幾乎達到無法維護的地步。

閱讀全文 »

C# 實作共用變數 by Singleton – 以交易系統登入連線為例

問題

股票期貨交易系統的登入驗證連線,必須隨時保持連線狀態 (connection state),也就是必須設計為 Stateful (有狀態),並於盤中需隨時得知連線情形,若斷線則系統應該要能通知用戶做重新登入的動作。

如果有多個表單 (View) /多個類別需在執行期間 (run-time)可以察知共享登入的連線狀態,該如何實現?

解決方案

共用變數類別

最簡單直覺的方法,設計一個共用變數 (global variables)類別,並保存需要在多個應用程式/類別之間共享的狀態/值。

可以參考此篇的作法:Global variables class

閱讀全文 »

「軟體需求分析與塑模」- 跨多個作業流程的塑模

本文收錄於 我的電子書「軟體需求分析與塑模 – 第二章、企業流程的分析與塑模」。

每一個作業流程,有各自不同特定的企業目的 (specific business goal)。例如:

  • 訂貨流程的特的目的為讓交易有效率且安全可靠。
  • 出貨流程的特的目的為及早可將貨品交付到客戶手中。
  • 採購流程的特的目的為從供應商取得低成本、高品質的商品。

企業經營者/高階管理者、系統相關的利益關係人 (stakeholder)、乃至於系統開發團隊,希能透過這些作業流程看到較巨觀 (macro view)、更具整體的全貌 (Whole View),如此可得以有效地作整體性的架構規劃與設計。

跨多個作業流程,就是流程範圍更為廣泛,參與的人更多,所涵蓋的時間更長。而且往往因為現實上基於功能執掌,還是不同部門或不同地點就有不同的作業規範與範疇,但彼此這些作業之間仍需要連串在一起。

由Erickson以及Penker所提出的一個活動圖的擴充型態(stereotype),稱之為「Erikson-Penker 企業擴充模型」(Erikson-Penker Business Extension)。(《Business Modeling with UML: Business Patterns at Work》, Manus Penker & Hans-Erik Erikson, 2000, p.57),該設計圖形最適切用來描述跨多個作業流程之間的關聯與各自的企業目的。

這個圖形中,主要是將與作業流程相關的重要人、事、物以及這個流程所要達成的目標做一個連結;不過有關企業流程的內部細節,通常在這張圖中不會有過多的介紹,以免失焦 (內部的活動細節會由 uml 活動圖表達)。

Erikson-Penker企業擴充模型簡介

下圖即對 Erikson-Penker (底下簡稱火箭圖) 的企業擴充模型的重要元素作說明。

圖、Erikson-Penker 企業擴充模型的主要圖形元素

 

閱讀全文 »

[備註] Visual Studio 2017 跑 x64 單元測試的設定

最近申請到「群益報價/下單 API」,也下載了 C#.NET 的範本,但卻是用 Visual Studio 2010 編譯的專案,花了一個多小時手動編輯 .csproj,總算可以在 Visual Studio 2017 開啟執行

不過範本寫得非常之亂,典型的全把所有邏輯寫在 Windows Form 類別。實在看不下去,準備把一些主要呼叫的 API (Login,下單,報價) 重整下,從 Windows Form 全抽離出來,並撰寫單元測試 (unit test) 方便測試。

群益API 是採以 COM 相對底層機制所撰寫的,使用前要先註冊該元件 (SKCOMLib)。我直接採用 x64 64位元的處理器架構,完全不考慮 32位元,還好群益都有提供。

程式撰寫挺簡單,但執行單元測試卻出了問題,只要將「目標平台 (target platform)」改為「x64」就會出現一些很怪的錯誤訊息。原來以為是呼叫 COM 出了問題,甚至打電話問了群益的資訊部人員,但他們竟然說沒聽過單元測試,程式沒有從 Form 開始就看不懂。挖哩,不過他們確信 COM 元件沒有問題,看來還是出在環境設定上。

查找解決文與 Try-Error 大半個下午,總算,就是只要在 Visual Studio 2017 選單「測試」→「測試設定」→「預設處理器架構」改為「X64」就 OK 啦!

Visual Studio 2017 跑 x64 單元測試的設定
軟體思維顧問

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

Personal