Developer的價值在哪裡？

前陣子CIO來訪，約我出來見個面聊聊天，順便跟我說說在我休假期間公司發生了哪些事。CIO跟我提到了一件令他頭痛的事，想問問我的意見。他說團隊中有個dev不聽他的話，不受控制，想知道我的想法，畢竟我是team lead。

事情的原由大概是這樣。目前團隊正專注於某個專案M的開發，而且CEO相當重視這個專案($$$)，希望團隊可以在九月結束時完成第一階段功能並且在十月初開始做UAT。這個專案當初是由我建議CIO由某個資深人員A來跟總公司進行需求分析、系統分析及開發，理由是A是最資深的，分析能力不錯，也有一些架構設計經驗。當時只有A一個人獨立作業，因為其它成員都在忙於另一個時程更緊的專案N，而專案M相對的不是那麼趕。後來專案N完成後，所有的資源也開始投入到專案M，而專案M也開始由A主導帶領三個開發人員一起做這案子。

書評 - 笑談軟體工程：敏捷開發法的逆襲

圖片來源：天瓏網路書店

當初買這本書主要是看到書名中幾個令我感興趣的關鍵字，「軟體工程」、「敏捷開發」以及「Scrum」，其中最主要的是Scrum。Scrum這名詞聽了幾年了，不過對於詳細的操作還不是那麼了解。原本以為整本書的主題都是在講Srum的運作，但實際上Scrum只是此書八個part中的其中一個，但這並不讓我對這本書失望，反而在anobii上我給了這本書五顆星的評價。

作者Teddy的部落格其實我也注意過一陣子。他的寫作方式蠻幽默的，而且也飽讀詩書，每每都能引經據典。本書的寫作風格也讓我想起之前所讀的「Peopleware： 腦力密集產業的人才管理之道」。一本書切成幾個part，每個part分成幾個chapter，只是Peopleware一書主要談的是管理，而這本書主要是圍繞在軟體工程，但這兩本書有個共同點，就是點出在軟體開發這領域上所會遇到的五花八門問題，尤其是與人有關的問題。

這本書讀起來其實蠻輕鬆的，就如其書名"笑談"軟體工程一樣。對一些敏捷開發方法如重構、單元測試、自動化功能測試及持續整合也都有簡單的介紹但又不會講的太深入，以師父引進門的方式來分享作者自身實踐軟體工程的一些方法。對資淺或資深的工程師來說，我認為都可以學到或看到不少東西，而對我來說最興奮的莫過於作者推薦的不少好書了。

書評 - Developer's Guide to Collections in Microsoft .NET

圖片來源：天瓏網路書店

原本對此書抱著不少的期待，不過在讀完後有些小失望，在anobii上我給它3顆星。本以為會大量介紹.NET內建集合物件及最佳實務，但只介紹了一點丁，也不夠深入。本書雖有六百多頁，但用了大量的範例程式碼，且提供C#及VB.NET兩種語言，所以實際上讀起來並不會花太多時間，因為只要選擇需要的語言來看就可以了。

前三章一開始介紹了一些資料結構如Array、Linked List、Associative Array、Queue、Stack及Circular Buffer。這部份作者用範例的方式來實作出這些資料結構，如果對這部份有底子的人很快就可以翻完這三章，而光這三章就佔了兩百多頁，也就是這本書的三分之一了。

四五章則開始介紹一些.NET內建的(泛型)集合物件，如List<T>、LinkedList<T>、Queue<T>、Stack<T>、Dictionary<TKey, TValue>、BitArray、HashSet<T>、SortedList<TKey, TValue>及SortedDictionary<TKey, TValue>，這部份比較有看頭一點，尤其是一些Comparer型別的用法是蠻值得注意的，在做集合物件排序和資料比對時相當有幫助。

網址查詢字串的驗證與排序

在某個專案中和third-party廠商所開發的API做介接。對方提供的API是以Key Value Pair (KVP)來實作，所以當我們呼叫對方的API時是直接呼叫某個網址如http://thirdparty/api?key1=value1&key2=value2&key3=value3&VerificationCode=4a66f0dfc4234cf6972353fd169fdb08。VerificationCode是所謂的驗證碼，用來確認查詢字串在傳送過程中是否被修改過。它的計算方式是將查詢字串key1=value1&key2=value2&key3=value3先做排序後，加上某個只有我們和third-party知道的安全碼，再以特定的演算法做hash(如MD5)來取得此驗證碼。所以當對方收到API呼叫請求時，只要以相同的方式來計算出驗證碼便可知道查詢字串是否有偽造。

Parameter validation的利器 - Code Contracts

Code Contracts是微軟針對Design by Contract所提出的解決方案。數個月前我在Code Leader一書中也看到類似的東西，作者在書中是以Programming by Contract一詞來代替Design by Contract，提出的解決方案是微軟針對Design by Contract所設計出的程式語言，Spec#。

在寫code時很常需要檢查方法傳入的參數是否有效，如檢查字串是否為空、數值是否大於零或某特定值，如果不符的話就要丟出exception。例如以下程式碼片段

        private static int Add(int x, int y)
        {
            if (x < 0)
            {
                throw new ArgumentException("x cannot be less than 0");
            }

            if (y < 0)
            {
                throw new ArgumentException("y cannot be less than 0");
            }

            return x + y;
        }