2008/12/25 物件導向(OO)課程後，節錄以下回饋資訊
學習心得：
1. 講師提到的TestCase是我印象最深刻的地方..因為testCase關係也對自我程式的一種防火牆.在寫程式時就先考慮了各種可能的情況.
2. 專案開發時先確定最重要的部份ex:100個需求/20重要/5務必 最重要的5條需求務必要先出來.其他需求則是後面確定後再開發
3. 瞭解從需求訪談至系統上線的全部流程
4. 學習系統分析及系統設計的文件如何製作
5. 上課講的東西聽完是有感覺的，可是有感覺跟會不會是另外一回事，聽完之後覺得會的東西還真是少ㄚ，看來要好好充實自己一下了。
6. 專案開發文件部分，看起來很簡單，自己做發現還真的滿難的，我是覺得一來是要經驗累積，一來真的是要改變看事情的心態，因為我常常會以程式面來看專案，而不是以專案來分析功能
7. 對於程式部分，發現現在新的技術真是多，學完一種可能另一種又出現了，永遠趕不上；而且要把MVC架構表現出來，個人覺得不好實現，一句老話：還是經驗
8. 點醒了心中一些疑慮，讓我恍然大悟，原來就是這樣一回事。之前與同事到客戶那訪談需求時，心中所想的就是：我要怎麼解決問題，而非：問題有哪些，所以心中一直覺得怪怪的、開發的過程中也遇到很多當初訪談時沒有切確問清楚的部份，雖然進度如期，但是一路跌跌撞撞的。觀念與立場釐清之後，相信下一個案子會更順利。
9. 需求訪談的經驗分享讓我覺得受益良多，雖然說大致上知道可能會有哪些問題，但那僅只於技術上的，必須要站在使用者的立場思考，才有可能更深入的去問到使用者的問題；在訪談完分析之後再去列出相依性的的關聯來決定開發的優先順序，讓我覺得這是一個很棒的方法，之後的專案會讓自己以這樣的角度去切入寫出SD。
改善建議：
1. 目前自己還沒有一些想法,但是還滿想知道一些新的技術與應用方式的
2. 希望以我們實際開發的專案來做為教學範例，因為教材的系統範例往往比較簡單
3. 可否提供相關資料的研讀網站或書籍，可以讓我們繼續研讀
學習方向：(近來發現的學習方向，如果學會了，對我們這個團隊應該有幫助)
1. 可以試著使用TestCase方式來達到程式的穩定度.這樣對於整個的品質相信應該會有正面的效果.也減少錯誤發生的機率
2. 我需要養成良好的寫程式的習慣,以及努力學習自我本身coding的能力
3. 學習如何利用tool節省製作文件的effort
4. 學習如何準確分析需求、闡釋需求內容，讓系統從分析至開發階段不會有落差
5. 學習Junit測試工具的使用，這樣因該可以將Bug降到最低
6. 學習UML，至少要看的懂圖示
2008年12月31日 星期三
2008年11月11日 星期二
測試方法與案例
單元測試是確保成果的基礎，沒有完成單元測試的軟體只是把風險移轉給使用者，這是一種鴕鳥心態，也是驗證莫非定律的不良示範，凡映出來的結果將是更多的客訴，投入更多資源去除錯，成本增加，驗收困難，工作負荷增加...，這些都是沒有妥善執行測試的現象；反之，如果為了品質而過度測試，這當中的資源浪費又要算在誰的頭上呢？
因此，測試必須執行，但也要避免過度，怎樣找出平衡點？軟體開發者必須累積經驗並從中獲得真正適合該組織的知識...歡迎加入討論
衍生閱讀：Test Driven Development(TDD)
因此，測試必須執行，但也要避免過度，怎樣找出平衡點？軟體開發者必須累積經驗並從中獲得真正適合該組織的知識...歡迎加入討論
衍生閱讀：Test Driven Development(TDD)
2008年10月28日 星期二
Hibernate Entity Manager / JPA Annotation
ORM 除了用 xml 設定方式之外, 例一種方式就是用 @annotation, 這裡一樣透過案例展示, 直接示範幾種常用的關聯
包括：
1. 單一物件
2. 一對一關聯
3. 一對多關聯
4. 多對多關聯
5. 繼承關係
相關資訊:Test Driven Development(TDD)
包括：
1. 單一物件
2. 一對一關聯
3. 一對多關聯
4. 多對多關聯
5. 繼承關係
相關資訊:Test Driven Development(TDD)
2008年10月21日 星期二
Hibernate Entity Manager / ORM
使用過 hibernate 開發程式的人, 都會碰到 ORM 的問題, 這份簡報整理了常用的關聯案例,
包括：
1. 單一物件
2. 一對一關聯
3. 一對多關聯
4. 多對多關聯
透過案例展示, 方便大家日後查詢之用, 強調一下, 寫好的程式必須"通過測試才能算是真正完成"
需要完整的範例程式? 連同你的建議寄送到我的信箱! 歡迎各位提供建議 ^_^
相關資訊:Test Driven Development(TDD)
包括：
1. 單一物件
2. 一對一關聯
3. 一對多關聯
4. 多對多關聯
透過案例展示, 方便大家日後查詢之用, 強調一下, 寫好的程式必須"通過測試才能算是真正完成"
需要完整的範例程式? 連同你的建議寄送到我的信箱! 歡迎各位提供建議 ^_^
相關資訊:Test Driven Development(TDD)
2008年7月28日 星期一
UML 案例 <3> 元件圖
UML Component Diagram 設計案例
回到文章剛開始的問題，猜猜這張Component Diagram是在專案執行過程的哪個階段製作的? 答案是一開始的企劃階段，企劃階段製作 Component Diagram的好處很多，希望各位透過本文能有所認識，趕快開始善用這張圖吧！
關於適度切割功能這點，筆者的期待是，適度切割功能達到可重用(Reuse)的地步，可重用的概念一直是軟體設計與開發者期待物件導向能帶來的優勢之一，但是我們怎樣找到可以重用的元件呢？
如何解構循環相依？請各位讀者自行思考囉，日後有空再跟各位分享囉。 ^_^
強力推薦：敏捷溯模(Agile Modeling)
圖 1、電子商務 Component Diagram
圖 1、電子商務 Component Diagram是筆者過往曾經做過的項目(專案)，各位可以猜猜這張圖是在專案執行過程的哪個階段製作的? RA、SA、SD、DEV…哪個階段呢? 答案將在最後的結論當中揭曉。
對很多人來說 Component Diagram 代表的是靜態結構的組成，用來表達的通常是系統、子系統與各個模組之間的關連性，私下跟許多友人探詢後，發現很多人都覺得這類的 UML 圖型較不常用，更意外的是，這麼好用的圖例，很多人根本沒在專案中用過它！這是怎麼一回事？為什麼我每個專案都一定會出現至少一次的圖，卻在其他人的專案中鮮少出現？到底是哪一方面出現了差異？
先解釋一下這張圖好了，圖中有1) 產品結構管理模組、2) 訂單處理模組、3) CRM 資料交換模組、4) 授權處理模組、5) 物流處理模組、6) ERP 資料交換模組等六個模組；每個模組負責的主要功能分別用不同的介面分別定義，例如產品結構管理模組必須具備1) 商品結構定義、2) 替代商品維護、3) 商品資料查詢等三大功能，其他模組也有各自具備的功能，個模組之間的相互串連則透過相依關係去表達，從圖例當中可以看到，訂單處理模組將會使用到產品結構管理模組的商品資料查詢，而物流處理模組則會使用到訂單處理模組所提供的各項功能。
註：由於筆者所使用的免費工具目前尚無法完整表達 UML 2.0 的圖例，所以，採用相依關係，一般而言本相依關係可以換成 UML 2.0 的 Required Interface
從Component Diagram的結構當中，我們可以清楚的了解到各個模組之間的關連性與每一個模組的功能特性，也就是說，這張圖表達了本專案應該要完成的功能與範疇(Scope)，各位讀者如果花一點點時間去看這張圖，大概也可以猜出這個專案到底在做甚麼了吧？這就是筆者堅持要畫這張圖的原因之一，讓第一次專案團隊能對專案範疇有正確的概念，也知道類似的功能要放在哪一個模組裡頭。
另外，這張圖對筆者而言還有另外幾個重點，其中一個重點是適度切割功能，如果系統的功能無法被適度切割，我們怎能確保自己不會迷思在一堆的需求當中呢？就像在一團打結的繩索中抽絲剝繭，這是一個過程，不但能確實釐清專案的各種需求，也是確保專案不致迷航的一盞明燈。
第二個重點是，釐清元件之間關聯性，Component Diagram結構當中的相依關係代表者元間之間的依存度，這樣的依存關係也可以作為開發時程的重要參考依據；例如：物流處理模組需要使用訂單處理模組，訂單處理模組需要使用產品結構管理模組，本例的合理的開發次序是 1) 產品結構管理模組、2) 訂單處理模組、3) 物流處理模組，人力與時程安排便可依此為佐證。
在釐清元件之間關聯性的過程中，還可以協助分析設計人員找到系統可能發生異常的部分，下圖是典型的循環相依案例，從圖例中，我們看到訂單處理模組需要CRM 資料交換模組，CRM 資料交換模組也需要訂單處理模組，如果系統採取這種設計方式將可能導致日後無法抽換其中任何一的模組，因此，設計人員必須解構 & 改進這方面的設計，如此才能提升系統的穩定度並增加日後擴充的彈性。
對很多人來說 Component Diagram 代表的是靜態結構的組成，用來表達的通常是系統、子系統與各個模組之間的關連性，私下跟許多友人探詢後，發現很多人都覺得這類的 UML 圖型較不常用，更意外的是，這麼好用的圖例，很多人根本沒在專案中用過它！這是怎麼一回事？為什麼我每個專案都一定會出現至少一次的圖，卻在其他人的專案中鮮少出現？到底是哪一方面出現了差異？
先解釋一下這張圖好了，圖中有1) 產品結構管理模組、2) 訂單處理模組、3) CRM 資料交換模組、4) 授權處理模組、5) 物流處理模組、6) ERP 資料交換模組等六個模組；每個模組負責的主要功能分別用不同的介面分別定義，例如產品結構管理模組必須具備1) 商品結構定義、2) 替代商品維護、3) 商品資料查詢等三大功能，其他模組也有各自具備的功能，個模組之間的相互串連則透過相依關係去表達，從圖例當中可以看到，訂單處理模組將會使用到產品結構管理模組的商品資料查詢，而物流處理模組則會使用到訂單處理模組所提供的各項功能。
註：由於筆者所使用的免費工具目前尚無法完整表達 UML 2.0 的圖例，所以，採用相依關係，一般而言本相依關係可以換成 UML 2.0 的 Required Interface
從Component Diagram的結構當中，我們可以清楚的了解到各個模組之間的關連性與每一個模組的功能特性，也就是說，這張圖表達了本專案應該要完成的功能與範疇(Scope)，各位讀者如果花一點點時間去看這張圖，大概也可以猜出這個專案到底在做甚麼了吧？這就是筆者堅持要畫這張圖的原因之一，讓第一次專案團隊能對專案範疇有正確的概念，也知道類似的功能要放在哪一個模組裡頭。
另外，這張圖對筆者而言還有另外幾個重點，其中一個重點是適度切割功能，如果系統的功能無法被適度切割，我們怎能確保自己不會迷思在一堆的需求當中呢？就像在一團打結的繩索中抽絲剝繭，這是一個過程，不但能確實釐清專案的各種需求，也是確保專案不致迷航的一盞明燈。
第二個重點是，釐清元件之間關聯性，Component Diagram結構當中的相依關係代表者元間之間的依存度，這樣的依存關係也可以作為開發時程的重要參考依據；例如：物流處理模組需要使用訂單處理模組，訂單處理模組需要使用產品結構管理模組，本例的合理的開發次序是 1) 產品結構管理模組、2) 訂單處理模組、3) 物流處理模組，人力與時程安排便可依此為佐證。
在釐清元件之間關聯性的過程中，還可以協助分析設計人員找到系統可能發生異常的部分，下圖是典型的循環相依案例，從圖例中，我們看到訂單處理模組需要CRM 資料交換模組，CRM 資料交換模組也需要訂單處理模組，如果系統採取這種設計方式將可能導致日後無法抽換其中任何一的模組，因此，設計人員必須解構 & 改進這方面的設計，如此才能提升系統的穩定度並增加日後擴充的彈性。
圖 2、循環相依案例
最後一個要點是其他文章中提到的 “測試優先”，有了功能分割與元件化設計之後，測試也能聚焦，每一個模組都可以有足夠的測試案例去維持該元件的品質，後續整合測試就會相對容易，投入的人力、物力與時間也會比較容易掌握，相對的，客戶將會更加滿意專案的執行成果。
結語回到文章剛開始的問題，猜猜這張Component Diagram是在專案執行過程的哪個階段製作的? 答案是一開始的企劃階段，企劃階段製作 Component Diagram的好處很多，希望各位透過本文能有所認識，趕快開始善用這張圖吧！
關於適度切割功能這點，筆者的期待是，適度切割功能達到可重用(Reuse)的地步，可重用的概念一直是軟體設計與開發者期待物件導向能帶來的優勢之一，但是我們怎樣找到可以重用的元件呢？
如何解構循環相依？請各位讀者自行思考囉，日後有空再跟各位分享囉。 ^_^
強力推薦：敏捷溯模(Agile Modeling)
2008年7月25日 星期五
"救火隊"? 原來我們需要的不是救火隊
XXX 您好, 上次談過之後, 我發現一件事情,從急迫性的角度看過去, XX 公司的確需要一些好手充當救火隊去解決棘手的專案, 雖然, 救火隊是解決前人遺留下來的問題, 且這些問題多是透過 QA/QC 去檢測出來!!
但我必須告訴各位一個事實, QA/QC 檢測出來的結果都是屬於落後指標, 反映出來的現象就是時間不夠, 客戶抱怨增多, 事實是, 即便是已經取得 CMMI Level 3 在 QA/QC 很有經驗的公司都會碰到類似的問題.
從我得到的資訊研判, XX 公司需要的不是救火隊, 也不是 QA/QC, 而是能夠督促團隊成員練好基本功的"教練", 我指的基本功比較偏重的面向是預防工作, 例如以下問題：
1. 怎樣才能真正做好 SA 的確認?
2. 怎樣才能順利把 SA 結果移交給 SD 並確保溝通無虞?
3. 下一關怎樣承先啟後?
因此, 我要推薦一個觀念 "測試優先", 這觀念非常貼近實務, 多少可以替 貴公司帶來經濟效益, 希望能幫上點忙. 關於 SA 的預防, 我會問以下問題 ：
1. 客戶是否已經確認相關需求?
2. 客戶將怎樣確認並驗證需求已經被滿足?
3. 測試的情境與步驟為何?
以上問題, 若可以在每一個需求討論階段就被記錄下來並獲得確認, 到 SD 階段就會相對容易承接.
關於 SD ... 呢? "測試優先" 的觀念依然適用
相關資訊：Test Driven Development(TDD)
但我必須告訴各位一個事實, QA/QC 檢測出來的結果都是屬於落後指標, 反映出來的現象就是時間不夠, 客戶抱怨增多, 事實是, 即便是已經取得 CMMI Level 3 在 QA/QC 很有經驗的公司都會碰到類似的問題.
從我得到的資訊研判, XX 公司需要的不是救火隊, 也不是 QA/QC, 而是能夠督促團隊成員練好基本功的"教練", 我指的基本功比較偏重的面向是預防工作, 例如以下問題：
1. 怎樣才能真正做好 SA 的確認?
2. 怎樣才能順利把 SA 結果移交給 SD 並確保溝通無虞?
3. 下一關怎樣承先啟後?
因此, 我要推薦一個觀念 "測試優先", 這觀念非常貼近實務, 多少可以替 貴公司帶來經濟效益, 希望能幫上點忙. 關於 SA 的預防, 我會問以下問題 ：
1. 客戶是否已經確認相關需求?
2. 客戶將怎樣確認並驗證需求已經被滿足?
3. 測試的情境與步驟為何?
以上問題, 若可以在每一個需求討論階段就被記錄下來並獲得確認, 到 SD 階段就會相對容易承接.
關於 SD ... 呢? "測試優先" 的觀念依然適用
相關資訊：Test Driven Development(TDD)
eXtreme Programming
今天花了一個下午的時間, 總算把我經驗中的 XP 給整理好了, 個人認為, XP 是很務實也很實用的, 在我過往的專案有幾次的機會都有用到 XP, 不過, 大多都是民間專案, 政府標案則因為一堆的限制因素(要做一堆文件), 而無法拓展, 從經驗中, 最有效益的專案也大多都是採用類似 XP 的方式推展, 因此,
強烈建議正在推廣"節能減碳"的政府機關能夠換個思維, 採用 XP, 減少浪費
衍生閱讀：Test Driven Development(TDD)
相關資訊：Modifiability: Or is there Design in Agility?
訂閱：
意見 (Atom)