I'm CaLendarW Blog

公司呢排有計劃要封鎖 Instant Messenger, 主要係 MSN, 而個計劃都差不多要實行, 但大部份既同事們亦已整裝待發地尋找其他辦法, 對我黎講, 無左 MSN 的確係有 d 唔方便, 而封鎖 MSN 亦都不是一個最佳既辦法. 自己覺得, 對運作既部門黎講, 封鎖 IM 的而且確係可以提高生產力, 但對開發團隊我又未必同意, 因為開發同運作唔同, 所以我唔讚成 block IM.

可能因為呢排日日返工放工都睇住本 Art of Agile Development 既關係, 諗既野都會由 Agile 方面出發. 而其中一個最好既解決 IM 方法係 – Pair Programming, 只要兩個人一齊, 不必要既活動就會減少, 而因為 Pair 既時間係 Design, Coding 同 Testing, 咁只要完成晒手頭上既工作, 咁員工喜歡做什麼就應該比佢自由. Pair Programming 既好處有很多, 例如: 提高生產力, 提高質量, 提高可用度, 監察及教育等.

因為 Pair Programming 有監察既用途, 在生產過程中不必要既 “工作障礙” 亦會減少, 而因為兩個人一起 Design 同寫 Code, 只要兩個人用心去寫, 質量就會提高, 而且有時候有些地方表面上好似做完, 但多個人諗下就可能會發現唔完善, 加上兩個人諗既野, 多個意見, 可以提高軟件既簡潔性, 對軟件既質量有十分好既改善, 而且 Agile 講求既係溝通, 經過兩個人溝通後所創既成果就會愈來愈好.

在教學方面, 因為係兩個人一起 Design 同 Code, Detail of Content 做既乜兩個人一定會知, 這樣就算其中一個人去左第二 team 度做野, 都有一個人可以問. 另一方面, 一個人寫 Code 同跟人地 d Code 時好多時下意識都會出現因為無同類經驗而創造了 Stovepipe system, 這會產生很多無謂既重複, 做了相重既東西, 所以 Pair 可以解決到呢方面既問題, 而且當兩個人分開後再跟其他人實行 Pair, 做到似曾相識既問題時就會諗起重用某些 Code, 就可以大大提高系統既可重用性及減少不必要既重複, 從而提高生產力.

不過, 另一方面, 要實行 Pair Programming 亦有一定既難度, 正如 Agile 係 base on 好多十分良好既理念一樣, 以我這半年在公司入面既觀察, 公司未必有足夠能力去 apply agile development, 例如公司無一個良好既 Continuous integration(CI) practice, 而 CI 同 agile 一樣, 都要有一個良好既 version control practice (唔係就咁 commit/update 咁簡單, 詳情請看 Pragmatic Version Control with Subversion), 良好既 test-driven 環境及智識 (而點解要 Test 就詳見舊 Post – Why Automate Test), 以及 programmer 要有良好既 refactoring skill, 軟件要 Design for Test 等等. 除此之外, 公司因為有很多不同既 project, 加上好多時要 on-site 工作, 而令到公司既 programmer 只得好少既溝通機會, 加上高層對 agile development 同 software configuration management 都好似唔太熟, 表現上好自由地比 Developer Implement Project, 但實際上就因為沒有溝通技巧而造成各自為政, 員工經驗得不到分享, 減慢了開發進度.

要係公司 Apply Agile, 詳見 Art of Agile Development 既 Adopt XP 一節, 因為解決人既問題始終難過選擇用邊個軟件做 Version Control, 點起 CI Server, 點學寫 Test Case 同邊度上 Agile 既研討會等, 書中有一大篇不同層面人事既應對方案, 所以都唔想多講 (無理由 copy 人地 d 野出黎架麻).

雖然現在自己未有最好既軟件開發環境, 但希望未來幾年可以不斷地進步, 直至令環境追上國際水平!!~

係軟件設計方面, 其實主要都想將唔同既 Concern 分開, 以我做開主要有以下幾個:

• 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 啦.

Test Driven Development, 係以測試來驅動程式既設計, 目的係為了提高軟件既質素.

好多人覺得測試對軟件方面只在於用戶接受測試 (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 而重做半小時既測試結果既慘況下, 自動化測試變成我寫軟件生活既其中一個有興趣深入研究既地方.

有時工程師會因為想將自己既履歷表寫好一點, 而推薦用一些未必係最善長或者最好既科技同方法去解決問題, 這些決定往往會影響成果.

其實, 最好既工作前路係由一班因為你為計劃作出了最好既決定而滿意既顧客為你建立的. 良好既信譽會比起你用最好既科技或方法帶來更大既好處. 在重要或者緊急既時間, 最新既科技永遠不應該放進客人的計劃內.

你要記住你被委託的職責, 作為架構師, 你應忠誠於公司及避免所有有衝突既興趣. 除非計劃有足夠時間及機會, 才可滿足你工作既需求. 如果你為計劃內應用最佳既建議而不使用未善長最新既科技或方法, 所有人都會因為你用最適當既科技多而感快樂.

當然, 有時新既科技往往太動人而難以抵抗, 甚至不適用於現在既情況. 有最好既解決方法, 計劃才有開心既團隊, 開心既客人. 這會給予足夠既時間來深入現有既科技, 你或者可以用自己既時間學習新既科技. 與其用不熟識既科技在唔夠時間既環境下完成計劃, 不如用熟識既科技來處理當前既問題, 再用空閒既時間去上堂, 又或者陪下屋企人吧.

無論如何, 將顧客放得比自已短期目標前是不會錯的.

##############################################

As engineers we sometimes recommend technologies, methodologies and approaches for solving problems because deep down we want to have these on our resume and not because they are the best solution for the problem. Such decisions very rarely result in happy outcomes.

The best thing for your career is a long string of happy customers eager to recommend you because you did the right thing by them and for the project. This goodwill will serve you orders of magnitude better than the latest shiny object in the latest shiny language or the latest shiny paradigm. While it is important, even critical, to stay abreast of the latest trends and technologies this should never happen at the cost of the customer. It’s important to remember that you have a fiduciary duty. As an architect you have been entrusted with the well-being of your organization and its expected that you will avoid all conflicts of interest and give the organization your undivided loyalty. If the project isn’t cutting edge or challenging enough for your current career needs then find one that is.

If you can’t do that and you are forced to be in such a project, then you and everyone else will be happier using the right technology for the customer rather than for your resume. It’s often difficult to resist utilizing a solution that is new and cool, even when it’s inappropriate for the current situation.

With the right solution, the project will have a happier team, a happier customer and overall far less stress. This will often give you time to go deeper into the existing older technology or to learn the new stuff on your own time. Or to go take that painting class you always wanted to do. Your family will love you for it, too – they’ll notice the difference when you get home.

Overall always put the customer’s long-term needs ahead of your own short term needs and you won’t go wrong.

By Nitin Borwankar in 97 Things Every Software Architect Should Know

This work is licensed under a Creative Commons Attribution 3