I'm CaLendarW Blog

null coalescing operator – ?? 係用黎決定參數是否 null 既算式, 自 C# 2.0 開始支援, 作為 null 既使用簡化.

// .net framework 1.1 既寫法
if (obj.Currency != null)
    cbxCurrency.SelectedItem = obj.Currency;
else
    cbxCurrency.SelectedItem = DefaultCurrency;

// .net framework 2.0 既寫法
cbxCurrency.SelectedItem = obj.Currency ?? DefaultCurrency;

長度上係短左, 識既人會易睇左. 另一方面, 通常既用法會同 Nullable 一齊用, 但自己平時無乜用開 Nullable, 所以對此無乜 comment (知道有呢樣野, 但唔知咩情況用先叫做適合, 所以都未用過.

// nullable int
int? i = null;
int result = i ?? 5;
// Output: result == 5

一年了, 一年前既今日, 我離開了第一間工作既公司, 在同學介紹既新公司返第一日工, 不知不覺地就過了一年, 這一年入面, 成長了? 感覺上唔多, 退步了? 或許吧.

這一年內, 跟過既 Project 應該得 3~4 個, 有簡單既寫軟件教學手冊, 有跟過 Module 入面既 Admin 部份, 有寫過全個 Module 所有部分都由自己設計至插入到主程式及 Deploy 到客戶使用, 又有全個系統由自己設計至將部份 Module 分配給同事幫手做, 實習經驗係多左, 同人相處既技巧亦變左.

由讀 CityU 開始, 係咁讀書既習慣都未有變, 雖然畢業後已經無得入圖書館, 但得到阿 Ken 既幫助仲可以係 CityU 借書, 以及係 CityU 入面間商務度訂書, 一個月都仲可以睇完一本書. 不過, 科目上都大部份都仲係 Software Engineering, 連阿 Ken 都 Comment 過我太過集中係呢方面, 要我試下搵其他方面 Study 下, 但 Software Design 同 Software Architecture 仍然係我最有興趣既科目.

除左讀書之外, Software Design 既 Skill 都強左唔少, 一來由書本及工作上得到經驗, 二來由 Study Open Source Project – NHibernate, log4net, rhino-tools, wordpress 等得到了不同既 Design 思維及 Coding 技巧, 以及一年來每日吸收既 CodeProject Email, CIO.com 既 article 等, 都令自己既資訊慢慢地貼近國際及想多了如何令軟件更適合公司業務, 設計技巧不段地進步, 不過現時仍然未有可以教我野既前輩, 而 Community 中既 Gathering 近期又開始少左, 技術提升亦開始緩慢, 畢竟工作環境仍然有大部份舊 Project 強烈地使用 Store Procedure 做主要既 Business logic, 程式員喜歡在兩個 IDE ( Visual Studio 同 SQL Server Management Studio ) 中編寫程序, 這令用開 Object-Oriented Design 既我在前人既 Project 成果中減慢了學習進度, 減少了軟件既可讀性及可重用性, 也增加了 Trace 既難度. 不過興幸既係在呢一年中, 要跟既舊 Project 無乜, 只要自己寫既新 Module, 所以在應用 OOD 方面可以由我話事, 期間亦寫了不少可重用既 Module.

呢一年黎, 因為 Design Skill 好左, 加上 DDD 既經驗多左, 在設計 Flow 方面已經可以用到 Sequence Diagram 及 Domain Service 作軟件設計. 這些技巧在提升 OOD 方面亦有了一定既幫助.

編程方面, 因為應用了 8 ways to be a better programmer 既 Practice, 能力上亦提升了不少, 不過因為前期技巧不足所以後期工作多左好多.

自立方面, 因為之前係 KML 兩年半既工作中學到了自立, 呢一年黎大部份時間都仲可以一個人處理到, 但與同事合作方面仍然需要學習, 畢竟我無以前 Joanna / Isaiah 對教人及管人方面有咁好既耐性.

大錯, 在呢一年內都發生過一次, 因為同事無放 Store Procedure 既 Source 上 Version Control, 而自己一開始都有日日 Backup, 又無為意要為佢 Backup, 最後要同事將佢過去兩星期內無 Backup 既野再重做多次, 呢個雖然唔係我錯晒, 錯之前亦都同同事講過要上 Version Control, 但明知佢無視我既說話, 而雙方又無為意要 Backup 就左 Restore Database, 使對方寫好了既 Store Procedure 要重寫過係身為出黎工作了三年幾既我既一大過失.

近期同事們開始討論 Coding Standard, 但這其實係每一個程式員都應該有既基本野, 唔應該係拎出黎講, 但因為公司無定義到, 而且有些人跟本唔知有呢樣野, 又或者唔知不同語言有不同既定義, 所以 d Coding Style 不一致, 另一方面大部份人太著重於編寫 Store Procedure, 始終對軟件既可重用性黎講未必係一年好事.

回顧一年, 技巧上學習到既雖然多左, 但自覺專業程度係低左, 對比一個外國既 Top Coder 黎講仍然有一段距離, 畢竟香港沒有外國咁優質既環境及培訓, 要追上世界級數還要落多點力!!

MsSQL 內既 Identity Generator, 雖然被發現當 Table 儲存超過一百萬行時, 由 SELECT @@Identity 或者 SELECT SCOPE_IDENTITY() 會存在 Return 值錯誤既問題, 但經過呢個幾月既開發都未出現問題.

係 MsSQL 入面, 新增 Record 時主要提取 Primary Key 既方法主要有 @@IDENTITY, SCOPE_IDENTY() 同 IDENT_CURRENT(‘table_name’) 三種:

@@IDENTITY
使用 @@IDENTITY 會 Return 當前 Session 任何 Table 最後生產的 Primary Key, 如果 Insert statement 運行後如果有任何 Trigger 中會 Insert 在其他 Table 的話, @@IDENTITY 就會變得不準確.

SCOPE_IDENTY()
使用 SCOPE_IDENTY() 會 Return 當前 Scope 內確實 Insert 左既 Primary Key, 就算有任何 Trigger 在背後運行都不會有任何影響, 係一個最好既選擇. 不過經由 MS Connect 入面既 Feedback 顯示, Table 被新增至一百萬行後, Return Value 有可以會籨 1 開始數起, 這問題由 MS 回應既答案中回答到已增加到它們的 Bug tracking database 中.

IDENT_CURRENT(‘table_name’)
而 IDENT_CURRENT(‘table_name’) 會 Return 指定 Table 最後生產出來的 Identity, 由於它不會理會任何 Scope 或者 Session, 當有多於一個 Scope 或者 Session 運行時便有機會出現不準確既問題.

因此, 在以上三個尋找 IDENTITY 既方法中, 並沒有一個能在任何環境下百分百準確既方法, 所以在 MsSQL 使用 Identity Generator 便會有潛在問題既可能性, 因此在 deploy 前應該對 Database 作詳細測試, 已確定當前既環境設定正確.

再者, Identity Generator 亦開始慢慢地被其他類型既方案取代, 例如 GUID, Hi/Lo or UUID 等等.

正如之前 CS != SE 文章內所講, Technology 其實永遠唔會有錯, 錯就只會錯在未能正確使用它們既人, 而軟件其中一個用途就係用來避免人們使用犯錯, 所以在程式篇寫時應該以不同既設定技巧及文檔來避免人們使用錯誤, 那軟件才容易正確地被使用!!