I'm CaLendarW Blog

Human Factor, 讀 Degree 果時其中一科有教過, 工作環境, 工作類別等等既因素都會影響到員工既工作表現, 而我發現呢度有好多錯配既情況發生, 雖然好大部份都因為人手唔夠既問題而產生出黎既, 但如果無人理, 咁就會令到資源流失 (產品質素, 公司形象, 人才或時間). 今日有一大個進步, 因為 Tommy 開始認識 Software Design, 希望呢個好既行為可以持續落去. 除此之外, 今日都比左好多意見, 雖然接受程度要進一步觀察, 但起麻係一個好既開始. 公司缺少既係一個發表意見既地方, 就算底下一班人識幾多野, 無上面既人援助基本上咩都做唔到, 而感覺上會發表意見既人亦唔多, 咁落去其實對公司發展亦有一定影響, 希望今日發表既意見可以令公司氣氛有所改變啦!!

前日子維 send 左個 post 比我, 內容幾好, 都係講緊 software improvement – 8 ways to be a better programmer in 6 minutes

1. 用大 Size 既字
當用左大 Size 既字後, 因為睇既野少左, 所以你就要開始諗點寫短一些既 method, 從而減低軟件既複雜性及增加可讀性

2. 將 hard code 既 string 變得討厭
這樣可以鼓勵你寫少一點 hard coding, 同埋指示你那裡有 hard coding

Visual Studio Options

3. 學習一下關鍵字 (keyword)
每隻 language 既關鍵字都有佢既用途, 請認識一下 language 不同關鍵字既用處. 以我為例, 呢兩年都開始學多左用不同既關鍵字, 例如 (is, as, ?? opertor 等), 識多一點更會簡化自己既 coding, 亦對自己既寫作有幫助.

以下係原文提供既幾個 .net languages 參考: C#, VB.net, F#.

4. 增加 1% 代碼覆蓋度
除左用自動化單完測試外, 進一步測驗一些內容深入難明或易錯既地方. 增加 1% 覆蓋度對代碼更有幫助

5. 閱讀 Open Source Project
學習一下 Open Source 既代碼, 對自己會有幫助. 近年都開始睇緊 NHibernate, Rhino-Tools 等既 Source Code, 當然係有些難度, 不過真係 improve 到好多方面既 skill, 例如學下人地 d Test Case 點寫, Inheritance 既 Test Case 點寫, 人地用咩 keyword 去處理事件, 同埋人地點設計等等.

亦可以參考原文建議既 Hanselman’s Weekly Source Code series.

6. 用代碼分析軟件進行分析
這個可減少代碼既複雜性.
原文有幾個 Tools:  fxcop, StyleCop, clone detective, ndepend, 或者 code metrics feature of VS 2008

7. 找一個最醜既 method 進行重構
重構一個不唔清晰既 method 可以提升到軟件既架構, 可讀性, 重用性等多個方面

8. Stop Reading, Start Writing
學以致用才是最好既學習模式, 最好由最基本既寫起, 原文建議寫 Complier. 另一方面, 我見過既好多人都有個好重要既問題, 就係佢地從來都無 Start Reading, 有些連學校教既野都唔會去用, 寫出黎既野完全難以重用!! 請記住, 係 Stop Reading 之前係有個 Start Reading 的, 如果你無一個清楚既概念, 無 Start Reading 既話, 就好難會學得好!!

公司呢排有計劃要封鎖 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 野出黎架麻).

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

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 而重做半小時既測試結果既慘況下, 自動化測試變成我寫軟件生活既其中一個有興趣深入研究既地方.

近期同同事討論緊用 Visual Studio 2005 定 2008 既問題, 雖然有關既 Project 唔係我負責 (因為我負責既話我一定會用 08), 但我都加入左討論. 以上頭既指示, 那個 Project 現階段會用 2005 來完成, 因為目標係寫 .net 2.0, 但正因為目標只係 2.0 既 platform, 又唔係 3.0 or 3.5, 用 08 可以方便到 developer, 點解唔用 d 比較新既 technologies 呢? 正如 Isaiah 之前我同講, 如果我有部快一部既電腦工作可以提高工作效率一部既話, 咁應該要提出換機. 又正如某個客既公司, 佢因為內聯網既速度問題, 而令公司過百既員工工作效率減慢, 這究竟得到了每月減少了既營運成本, 定係失去了因速度慢而要增加既人手, 高層使用電腦所等待既時間呢.

上頭表示: 用 2005 進可以攻, 退可以守, 因係舊 Product, 而且只支援 .net 2.0, 所以用 2005 就一定無問題. 而我覺得, 如果只怕新科技會帶來既問題而選擇逃避, 而外間因什麼都沒有而選擇了新科技, 那如何創新, 那競爭力便會不知不覺地下降, 繼而損失了帶頭既角色.

創新…….在香港還有嗎?