在過去30天中，我們實際透過逐步完成Api的功能，熟悉Asp.Net MVC的結構和擴充的方法，也實際發行到Azure上，並透過Azure所提供的服務來完成我們的工作，也介紹了如何監控和管理線上網站的狀態，其實這些方法並不僅僅能用在Api系統上，有絕大部分的經驗就算是使用在一般網站站台的開發上也是沒有問題的，大家可以依據自己的需求來套用到自己的系統開發之中，今天也將向大家分享在這30天的文章分享的一些心得總結。
※使用Gitflow作為開發流程控制
在這30天的文章分享之中，每天在文章中所Demo的程式碼其實也是當天所產出的，進度非常的刺激，除了是第一次完全採用Git當作版本控制系統之外，還選擇使用Gitflow這套開發流程來幫助開發。

在最早期開始工作時，所使用的版本控制系統為CVS和SVN，在其中也有用過VSS。認識git之前其實都還沒有什麼branch的觀念，而使用git之前最痛苦的時候就是有多個版本要簽入同一支程式碼，但是不是同時要Release，常常會造成最後版本錯亂，真是相當的可怕。而使用Git之後也慢慢的愛上了它，讓我可以更放心的新增分支去做修改，確認無誤在Merge回要Deploy的分支即可。

這次我還使用了gitflow這套工具，在經歷過剛開始的不熟悉之後，也愛上的Gitflow，因為它就是一套開發流程的原則，讓我很清楚的知道我甚麼時候應該將分支合併回主幹(master)，而我在撰寫新功能時隨時都可以很輕鬆的作破壞性的嘗試，若嘗試失敗也只要切回原本的brance就可以馬上還原為一個乾淨的環境，這對快速開發來說幫助相當的大，非常推薦給大家使用。

※DI Framework的導入
大家可以看到我在文章一開始的時候就介紹了如何使用DI Framework來當作系統的核心，透過它來幫助我們初始化各個實體，對大部分人來說DI Framework在系統開發上來說是較為困難而且複雜的，是不是有這個必要性，但我覺得系統在開發最重要的一件事情就是在一開始建立好對的原則，而且透過它我可以讓系統程式碼的可維護性大大提高。

使用DI Framework的好處是，讓Class之間的互相引用要盡量透過介面，不要直接參考實體，若是使用DI Framework，我們可以透過DI Framework來自動注入對應的實體，如果沒有選擇使用DI Framework，也不要直接用new instance的方式，而是盡量使用Factory Pattern來初始化實體。

這些方法可以讓Class之間的耦合性降低，因為所有的引用都是透過介面，所以當我們要修改或升級其中某一個Class的功能時，也不會因為Class之間關連過多而難以著手。除此之外也方便單元測試的進行，因為我們可以透過介面來Mock各種情形，減少Side Effect的產生，撰寫單元測試所省下來的成本絕對比想像中的還要高。

※模組化的程式碼
透過這段時間的開發，大家可以發現我們在Api中的程式碼邏輯都是一小塊一小塊區分開來的，而每一塊都有自己的職責和功用，這是因為在開發時期遵循了關注點分離(Seperated of Concern)的精神，也符合了OO中的單一職責原則，讓每一個Class都只實現自己主要負責的工作，不會包含過多的其他資訊，而每一個功能群組的Class也會分類在同一區之中，這樣子可以讓我們在進行開發或是單元測試是不會面對過多的雜訊干擾，而是可以專注在自己想要完成的功能上面，雖然程式碼的數量變多了，但是由於分類和存放的位子都有一定的規則在，只要習慣後在維護上反而更加的快速，因為修改時不會一次要面對四五種邏輯在一個Function之中，而是一次只要把一件事情做好就OK了！

如果我們在開發時讓程式碼專注在單一功能上，其實也無形的讓程式的可重用性變得更高，相信大家都在實際開發時遇過這種狀況，我們有一個功能可能會用到某一個Class的80%程式碼，但另外20%的實在是不需要，有些人會選擇是再寫一個新的Class然後有80%的程式碼重複，亦或是增加一個參數，然後再用if來避開，但這兩種做法都是不太好的，可能會增加維護時的困難性，相反的如果我們可以修改原本Class的邏輯切成更小的單元，那麼就可以讓同一隻Class使用在更多地方，但如果一次就將程式碼切為過於零碎就是一種過度設計了。

我們應該依照敏捷開發的精神，在遵循基本OO原則的前提下快速開發，並同時撰寫單元測試，配合版本控制系統與CI Server來管理發行程式。而當有需求異動時，我們才會調整不合理的地方，並讓測試通過，透過CI Server的自動化建置和測試確保程式都處在Avaliable的狀態，就像Ruddy老師曾經說過敏捷開發的精神是擁抱改變，不要害怕變化，而是透過完善的機制讓我們能夠快速因應變化！

※善用Open Source的Library
在這一系列的文章中，可以看到我選擇使用了Open Source的Library來完成功能，尤其現在Open Source的社群非常活躍，我們不一定每次都需要重新造輪子，可以選擇使用功能相對完善的Open Source Library，讓我們在開發時節省大量的時間。

很多人可能會擔心使用外部的Library似乎不如自己開發的可靠，但其實活躍的Library使用者可能是成千上萬人，遇到問題時也可以很輕易的在網路上找到答案，如果真的有使用上的問題，擁有熱血工程師靈魂的你正式一展長才的好機會，還能將它修正並且回饋給社群，為Open Source Library貢獻自己的一份力量，讓這些Library更加完善，也是一種工程師的浪漫。當然切記使用Open Source Library時也不可忽略授權的問題囉！

※本日小結
其實這30天過得很刺激，在這系列之前所做的準備是有一個Api的構思與雛形，想像了大概30天要寫的題目就開始動筆了，接下來30天果不其然就是每天都在實驗想法是否可行，以及如何實現到自己的Api中(幸好有Git!)，同樣的事情卻又不能因為完成當天的進度也休息，因為明天的程式碼也都還沒驗證過需要擔心(就像是熱血的趕了30天專案)

但這30天也是有很大的收穫，不但好好的磨練了自己與Git Flow的熟悉度，也和Azure有了初步的認識，對於自己的學習成長有很大的幫助，今年要反省的老毛病是對於文章的撰寫還是不夠熟練和流暢(寫一天不會感覺，寫了三十天自己都會搖頭XD)，以及在內容性的完整度上還需要再努力，尤其是細節不可以太過於鬆散而忽略，希望自己能夠在努力加油囉！

今天是最後一篇了，希望這些文章能夠對大家有幫助，也歡迎大家一起討論囉^_^