Duplication, 係 Program 入面係理應避免的, 正如見到重覆既 Code 就應該進行重構一樣, 但在 Database 層面上既管理又可能係另一種講法. 係 Knowledge Level 入面, 儲存既資料應該避免重覆, 因為所做既係最新既資訊, 以最實時既資訊去處理日常既運作, 雖然用既係最新既資訊, 但儲存落 Database 入面就可能要將所有有關既 Value Object 儲存埋, 因為往後既日子如果 Knowledge Level 有所改變, 亦唔應該影響到 Database 入面 Operation Level 完成品既歷史, 方面了解當時既情況, 等同於 Data Mining 一樣, 做既唔係避免重覆, 而係有必要地控制重覆, 呢個就係 Database Design 入面一個重要既地方!!

• Flow / Business Logic
• Input (Import Data, Interface for 3rd Party)
• Output (User Interface, Report)
• Database
• Logging
• Permission

在以上幾個 Concern 上, 而 Logging 同 Permission 呢兩樣野其實應該可以重用, 而且應該可以視為另一個軟件 / Domain Area.

Database 使用方面, 因為市面有不同種類既選擇, 而為左可以應用係唔同 Database 上, 好多人都會加上一個 Data Access Layer, 正常既 implement 手法都係 Object Relational Mapping, 在 .net 主要有 LGPL License 既 NHibernate, Castle Project 既Active Record, 又或者係 .net 3.5 既 Linq To SQL 及 Entity Framework, 這些 Module 已經被外國引用成為主流, 因為使用者不用因應不同既 Database 而寫大同小異既 SQL, 避免了因小異而不段尋找問題, 只要學習一套, 其他由 OR Mapper 做便好了.

Logging 方面, Debug Log 其實可以用 Apache License 既 log4net, 而 Audit Log 我覺得應該可以視為另一個軟件而寫到一個 Lib 黎比全公司用, 以統一全公司軟件開發基礎.

Permission 方面主要有 Authentication 同 Authorization 兩個部份, 我覺得可以寫得開一個 Lib, 因應唔同需要 (e.g. 用 AD or 自己既 Login Table) 而各自使用同一個 Interface 既唔同 Implementation, 總好過不同 Project 都用緊不同既處理手法.

Input 同 Output 方面其實都幾難重用, 不過都應該可以寫到一 d 相對應既 Lib (e.g. Import/Export Excel, Customize User Control 或者既定的 3rd Party Solution).

Flow 其實係最難重用既部份, 因為應該唔同 Project 都有唔同既 Flow / Business Logic, 而常見既處理手法都會使用 Object Oriented Design, 而為了保證質素, 外國 (包括 Microsoft) 寫左套測試系統黎令做 Automate Testing, 有早期自己用開既 NUnit, 或者 Visual Studio 2005 打後既 Unit Testing Framework, 當然仲有好多其他既 Implementation, 只不過自己用開 NUnit 而無再留意.

綜合以上不同既 Concern, 其實除左 Flow/Business Logic, Input 同 Output 之外, 其他部份應該都可以重用, 如果每個 Project 都可以重用這些 Module, 寫軟件既時間應該可以集中一點在不能重用既部份而提高用家對軟件質素既評價, 亦可以有時間做 Performance Turning 及 Unit Testing, 使軟件能夠提升質量, 有關點解要 Testing 既資料可以參考舊 Post, 而 Performance Testing 其實亦可以靠 Unit Test 黎做監察 (詳見 Pragmatic Unit Testing in C# with NUnit 內有關 Performance Testing 一節)

重用既除左可以減少需要 Implement 既時間外, 對新人黎講都會容易跟, 因為套套系統都用緊同一樣野可以減省 Pickup 現有系統既時間. 不過對於重用方面, 公司既軟件管理政策亦同樣重要, 如果個個 Project 都係 Copy 一套出黎用, 那麼發現一個 Bug 就要搵晒全公司既所有 Project 一個個改, 這些處理手法在 AntiPattern 內亦有提及, 往往做成不良後果.

不過以上既推論都有重要既假設: 一個好既 OO Design 同 Design for Reuse. 如果設計得唔好, 就沒有人會用, 如果不是為重用而設計, 就不能重用.

對我在舊公司管理及維持左 Reusable Lib of Web Module, Data Module 同 Common Module 及不同 Internal Project 年幾時間既我, 加上接近七年前大專開始既軟件開發生涯, 在 OO Design 同 Design for Reuse 都自覺有相當既經驗, 雖然亦有好多不足既地方, 但亦希望跟住呢條路行. 而因未發新公司有現醒啱用既 Lib , 所以自己寫左一些重用到既 Lib, 加上 Project 開始繁忙而盡量希望在 Project 內實行軟件架構, 短期內應該有好多機會提升自己在設計及實行方面既經驗, 希望現實真係可以咁 Ideal 啦.

好多人覺得測試對軟件方面只在於用戶接受測試 (UAT), 因為只要通過 UAT, 公司就可以袋袋平安. 不過, UAT 通常都浪費人手, 而且該次 UAT 只計對於該次既軟件需求, 當需求需要更改, 所有既測試都要人手重頭做過, 浪費人力物力.

自動化軟件測試既好處係可以減省人手及時間, 以及提高軟件既質素及完整度.

以下係一個由 NUnit 提供既自動化測試例子:

// 一個 object oriented 既 Account class
namespace bank
{
  public class Account
  {
    private float balance;
    public void Deposit(float amount)
    {
      balance+=amount;
    }

    public void Withdraw(float amount)
    {
      balance-=amount;
    }

    public void TransferFunds(Account destination, float amount)
    {
    }

    public float Balance
    {
      get{ return balance;}
    }
  }
}

namespace bank
{
  using NUnit.Framework;

  [TestFixture]
  public class AccountTest
  {
    // 自動化測試來測試 TransferFunds Method
    [Test]
    public void TransferFunds()
    {
      Account source = new Account();
      source.Deposit(200.00F);
      Account destination = new Account();
      destination.Deposit(150.00F);

      source.TransferFunds(destination, 100.00F);
      Assert.AreEqual(250.00F, destination.Balance);
      Assert.AreEqual(100.00F, source.Balance);
    }
  }
}

以上只係其中一個例子用來測試軟件既完成度, 在現實上, Test Case 除左要測驗一般情況外, 仲要測試錯誤情況出來既結果, 保証軟件質素, 所以正常使用既情況係唔會得一個 Test Case 咁少.

要實行 Test Driven Development, 通常要有一個良好既 Object Oriented Design 以及 Design for Test, 如果沒有這兩個設計既技巧, 那測試既質素有可能會受影響.

愈多 Test Case 未必代表軟件的準確率愈高, 正常情況 Test Case 既數量應該多過 Use Case 既數量, 而且會因應不同既考慮點而增加一定的測試數量, 以我所知, 在某些大學既科目中, 有計算要有多少 Test Case 既試題 (因為我都有睇過), 用作驗證是否足夠全面地測試每一行代碼.

在測試失敗時, 有問題既地方除了可能係軟件本身外, 自動化測試部份亦有可能會有錯誤, 錯誤既多少在乎實現 Test Case 既人對軟件測試既知識同經驗所得.

雖然軟件在有測試既環境下推出, 但有時都有可能會在軟件發現有 bug 既情況, 當遇到這個情況下, Programmer / Tester 應該用 Test Case 去模擬問題既環境, 當得出相同既結果後才可以更改軟件, 因為未能模擬出相同環境下更改軟件, 失敗後亦未知是軟件問題定 Test Case 問題, 所以 Programmer 應該先更改 Test Case 後才更改軟件, 而更改軟件途中, Programmer 亦可透過測試來避免 side effect 出現, 所以不段發現問題環境才能提高軟件既完整性, 以及提高軟件人員對軟件既信心.

測試, 除了要滿足軟件既完整性, 亦要滿足不段改變既需求, 世界變, 軟件同測試不變就只會不進則退, 所以為新既需求而更改軟件及擴充其功能既環境下, 自動化測試係必須的.

一年前我工作既地方, 因為無自動化測試, 軟件無 Design for Test, 要用到硬件 及 3rd Party 提供既模擬程式下, 人手測試既時間應該超過一個月, 除了測試一個月既時間外, 測試既人手通常都要兩至三人, 而且大部份都係重複既輸入工作, 以及已改幾句 code 而重做半小時既測試結果既慘況下, 自動化測試變成我寫軟件生活既其中一個有興趣深入研究既地方.

用 Open Source 既原因, 主要係集眾人既力量來提高軟件質素, 如果有 bug, 只要 1 個人 debug 就可以解決, 提高了可重用性, 亦可以提高軟件既完整性.

而減低成本方面, 我相信都有一定效果, 當然市場上有人已經提過, 請識用 Open Source 既人其實佢既人工都會高左, 但對公司黎講應該可以減低成本.

使用方面, 其實大多都係得幾類, 一係工具, 而且可以應用在不同領域; 一係已標準化程序, 就功能更加完善. 所以使用 Open Source 係利多於弊.

Core Competence 係指企業核心能力, 亦都係企業不可代替既競爭力, 等同於 Sony 既電子細小化技術, Mac 既圖象技術一樣, 每間公司能夠待續成長就要有一個 Core Competence!! 而 Distilled Domain 就係個 Core, 經多次程式員同 Domain Expert 討論及詳細理解過後既精華所在, 但如果一個 Core Domain 得不到質量管理, 最後都係發揮唔到佢競爭優勢.

Domain-Driven, 因為要解決既問題多數係 Domain Problem, 所以如果 Software Developer 未能理解該 Domain, 其實對軟件既質素長遠都有影響. 而當一個不良既設計存在於一個運行緊既系統內, 作為 Software Developer 係咪真係可以說服到管理層 (通常係 Project Manager) 去追求質素而去面對一個有可能存在既風險呢?

因為自己對軟件設計有追求及自己不段既進步, 面對住以前寫過既部份質素無咁好既設計(或者係 Code)因為已經運行當中而無法提高品質, 可以做既就係在一個新既系統未設計之前, 盡量去理解 Domain Problem 同 Business Needs 而去做一個精練既設計, 加上軟件架構同良好既編程習慣, 令跟隨者能易於管理及因需要而重構, 自己又能隨著經驗增加而設計出更高質素既 Domain 及周邊工具, 咁先可以有較地提高生產力.

一個好既 Domain Design 亦都好需要一個良好既 Utility 支持, 等同於 Core Competence 入面, 除左 Core 之外, Non-Core 但 Essential 係避免 Outsource 一樣, Utility 亦十分重要, 亦需要得到內部廣泛使用及質量管理 (e.g. Test-Driven Design), 不會抄襲而注重重用, 咁先可以真真正正提高效率, 質素及生產力, 呢幾個理念亦係我對軟件設計既堅持.

Factory
Repository
Specification
Domain Model with Aggregation

而宜家寫既 Code 大部份都會跟呢個方向做, 雖然有時都無寫 Factory 黎生產 Object, 但自己就將 Repository Inherent DAO, 咁加埋 Spring.net 既 NHibernate Template 就可以更快地寫好一個 Program, 而 Validation 呢部份就用 Specification 黎做, 配合埋 Shared Kernel 就可以支援唔同既 Bounded Context.

用左 DAO 之後, 大部份既 SQL 都交由 DAO 負責, 除左 DAO 之外, 其他地方應該唔會出現 SQL, 我覺得咁樣會方便管理, 同埋係更改!! 而實際 Program 上面, 基本上係拎個 object 舞來舞去, 無乜咁大特別, 舞完一輪就用 DAO Update 返落 Db, 方便易用!!~

不過, 當你 apply 左 smart ui 之後, 其實亦限制左個 software 既可擴展性, 因為所有既 business logic 都係晒個介面度, 如果你寫既 software 愈來愈大, 而 business logic 只可以不段咁 copy and paste, 就會變得複雜同難以管理, 當有 logic 要轉, 就要轉晒所有版面引用過既 code, 呢個亦都係之前我個 post 所講: “爛於抄, 精於用” 既道理, 亦正正就係點解要有 software design 同 software architecture 既原因!!

而我自己, 因為係一個太過 OO 既人, 凡事都 object-base, 所以我都會盡量唔比 smart ui 出自我手, 當然工作需要既我就要用, 但我有得選擇既話我一定會行 object-base!!!

• Software Architecture Interview Questions Part 1 ( Design Pattern )
• Software Architecture Interview Questions Part 2 ( Design pattern )
• Software Architecture Interview Questions Part 3 ( Design Pattern )
• Software Architecture Interview Questions Part 4 ( Design Pattern )
• UML Interview Questions Part 1
• UML Interview Questions Part 2
• View Video of Design Patterns
• SOA Interview questions Part 1 Recent Added

1. Highly Involve Client. 呢方面對 External Project 或 Internal Project 既使用性都不大. External 方面, 公司未必希望 Client 一齊 Design, 因為大部份既公司都會 Technology Focus, 所以 Client 比既 Idea 對未完全接受 DDD 既公司黎講未必接受到. Internal 方面, 高層雖然應該會有好既 Domain Knowledge, 以及比較容易做到 Involvement, 但係在於高層既角度又未必抽到咁多時間黎陪你做 Domain Design.
2. Use of infrastructure. 對於香港大部份 SME 黎講, 未必有良好既 infrastructure, 雖然現今有大量良好既 Open Source Project, 但未必適用於公司既原有 framework 同 culture, 而且就算 define 到一個好既 infrastructure, 都未必得到傳統既 Developer 接受.
3. Test Driven. 香港未必有咁多既 SME 公司會 Apply Test Driven, 因為係香港既社會, 好多 Outsource 既 Project 都會係短時間內完成, 所以係咁既環境下未必 Apply 到 Test Driven.

因此, 要將 Domain Driven Design 引入到香港既公司會比較難, 所以對我黎講都係 apply 一部份就算.