為什麼我說在撰寫程式之前，還是先做個簡單的分析比較好？

我們可以從討論中獲得共識，但你跟你的需求獲得共識了嗎？

前言

上個禮拜，我在公司對新人進行教育訓練，我依舊按照我原來進行訓練的步驟開始，先了解主題與內容，也就是新人想學習得內容？比如是前端？或者是後端的開發等等。接著是新人的程度到哪裡？如果假設我是要教 C# 與 ASP.NET Core MVC 的開發，那麼我得先調查新朋友是否已經撰寫過 C# 以及對 OO (Object Oriented) 了解的程度到哪裡？再來，就是從我們一般進行專案開時，所所有會使用到的技術來排定學習的優先順序，當然了，也考量學習的新朋友目前所擔任的角色。

學習是需要被課製化的

再回到本文想要講述的重點，因為每一個人的基礎都不同，已經熟悉的技術內容都不同，所以經過客製化的訓練內容也會有些不同。

而我們現在談的是軟體專案開發，既然是專案開發，那麼開發的內容(產出的內容程式碼)是來自於使用者需求，所使用的技術只不過是幫助我們去勾勒出『使用者』需要的『成品』（也就是成運作+並達成使用者標的與期望解決的問題）的軟體最終成果（也許是網站 Web／APP／..Others），

也就是說，使用何種技術只不過是種手段，但是你有沒有 Catch 到使用者真正的期望與需求那可能是另外一件事情。

在真的開始寫程式之前，建議還是做個簡單的分析吧！

在開始之前，我隨口問了一下新朋友，你知道 OOAD 嗎？就是也可以拆解開來分別談 OOA/OOD ？ 結果新朋友告訴我，她只有聽過 OOP 而已，沒有聽過 OOA 與 OOD?

我聽到之後非常的驚訝，因為這位新朋友再來公司之前去恆逸上過課而已，也許已程式開發為主的課程並不會提及這些，也有可能軟體開發內容層面範圍較廣無法全面提及也是實屬正常。

我告訴她，其實在台灣目前的產業裡，也不太重視分析／設計這兩個階段，但是我個人反而比較重視這想個階段，但並不是說我不重視使用的技術 & 軟體架構設計，因為使用哪一種軟體架構設計／Patterns 是來自你的『使用者需求』，像是幾年前，我曾經寫過一篇文章：『從使用者需求、談軟體架構設計』這篇文章所講述的內容一樣，一切都是來自你的需求。

而有部分 Bug 亦是從需求而來，而從需求而來的 Bug 往往最難修改，可能得翻掉架構也說不定。

圖（一）、從需求而來的 Bug

很多時候，可能是你需求沒弄清楚，而不是 Tester 沒有發現 Bug。不要等到你的 Bug 大到無法消滅時，才來傷腦筋。

從分析開始

圖（二）、其實你一直在做 Modeling

其實你一直在做 Modeling，即便你是直接寫 Code，你只不過在你的腦袋裡 Modeling，然後什麼Modeling的過程都沒有 Keep 下來，唯一產出來的就只有 code。

在我的決戰 OOAD 系列課程裡，我曾提到從分析的角度來看一切事物、透過模型 Modeling 來設計系統，這麼做有許多好處，除了能夠透過 Modeling 或是圖形來模擬系統運行的情況、也能在腦中將需求釐清楚，這在當你沒有人可以和你討論需求時，透過與（模型/Modeling） 的腦力激盪下，會有好似與人討論的效果，因為我們知道，同事之間的需求討論有時會靈光乍現，事實上，你與模型間進行腦力激盪時也會有相同的效果，相信我。

如果你與團隊間能夠透過 Modeling 來進行溝通，那麼對需求的離情，哪一些需要再與客戶確認的會更清晰與清楚，且花費的時間會更短、更有效率。

• 線上租車系統

圖（三）、UC01車輛租用系統

   

這裡，我以一個線上租車系統為例，以 Use Case 來說明也非常單純，因為需求簡單，所以只有一個『主要事件流』

底下是我提供的一連串的訓練內容 & 順序：

(1). 從物件的角度來看世界

圖（四）、從物件的角度來看世界

從物件的角度來看每一件事情，這也是比較貼近在真實世界裡所看到的情況，而這也是種思維、思考方式。從物件角度來看，『物件』與『資料』是密不可分的。

(2). UML 相關 Notations 說明

圖（五）、在 UML 裡常見的 Relationships

在這個 TOPIC 裡，我說明在 UML 中常使用的 Relationships 關係，這在表達程式碼實作時，也非常重要。了解關係的使用能夠在從分析 順暢的到【設計】與【實作】時比較無往不利，或者是在閱讀團隊的 Class Diagram 時也更能夠增進溝通的效率，兩了解更多也可參考我的線上課程：決戰OOAD系列課程（線上版）(用我的連結購買講師才會抽比較多唷～謝謝您)

(3). （考試）將 Class Diagram 撰寫成程式碼

這裡我要求新朋友將底下的類別圖撰寫成程式碼。

圖（六）、基本Car與巴士轎車關係圖 (Class Diagram)

 

另外，由於初學者最容易搞錯 Association 的線頭方向，說明當 A Class 使用到 B Class 時，這個 Class Diagram 該怎麼表示？

又或者反過來說，你讀到一張 Class Diagram 時，你得馬上知道它的『程式碼』大概長時麼樣子？這你得反覆訓練自己，不用實際撰寫程式，手繪幾張稿子就等於大致上驗證過設計會是怎麼樣子的。

(4). C# 泛型說明

圖（七）、C# 中泛型的種類

這我再次詢問時得知其可能連程式語言中的泛用型態 Generic 都不是非常清楚、甚至沒用過... 那麼這在設計上會很吃虧的，因為我們在設計到實作其實 Generic 會用得非常多，更不用說套用一些 Patterns 來解決一些特定的問題時，如果不懂 Generic 這會非常的麻煩，Generic 應該是程式語言中基礎中的基礎了，這在實作上可以產出共用性極高的程式碼。

所以，我只好安排一場 Generic 的入門到實務的課程.. 其實老師不好當！XD

(5). C# LINQ 從概念到理論到實務開發

圖（八）、LINQ 從基礎入門到實務

再來就是，我們實務的開發裡 LINQ 使用的會非常的多，LINQ 這已經算是 C# 的重要特性之一，若不清楚怎麼駕馭它，後續的開發會很有問題。由於新朋友也是對 LINQ 一知半解，在這半天的課程只好講 LINQ 入門實務課程，並帶 Lab 要求下載 LINQPad 來做這個 Lab 範例哈哈哈

(6). ASP.NET Core MVC 基礎開發

最後，留給下次的重頭戲了...