SAIKURON 13.Ned

話說最近正在讀《無瑕的程式碼》這本書，所以一直擺在手邊，三不五十就會瞄這本經典鉅作一下，不過最近眼花常會看錯書名... 當程式寫出來，功能完整，沒啥bug，自我感覺天下無敵的那一瞬間，就會看成「無敵」的程式碼 當不小心打開Open Source的專案原始碼時，一堆看不懂的程式碼在眼前，老鼠怎麼捲都捲不完，眼花撩亂的那一瞬間，就會看成「無窮」的程式碼 當看到某些函式訂了參數，傳進去卻沒用到，咒罵這分明是脫褲子放屁的那一瞬間，就會看成「無用」的程式碼 當看到某些大師的程式碼，想說來重構一下，以證明自己比大師更厲害，卻發覺完全沒地方下手，體會到大師果然厲害的那瞬間，就會看成「無缺」的程式碼 當看到某些程式碼模組交互呼叫，糾纏不清，你濃我濃時，想修個bug卻不知從何下手時，就會看成「無縫」的程式碼 當看到某些程式碼根本只是隨便寫寫，完全不考慮後續維護，魔術數字四散各地，變數名稱與流程邏輯完全對不上，改起來簡直想要跳樓，就會看成「無恥」的程式碼 當bug截止時間將到，知道錯誤在這段，卻完全沒有idea要怎麼改，就會看成「無望」的程式碼 當一直寫一樣的東西，絲毫沒有變化，感覺悶的要死時，就會看成「無趣」的程式碼 當看到某些程式碼內含一堆架構，實際上架構根本就沒做到什麼重要的事，完全是一個熱臉貼冷屁股的那一瞬間，就會看成「無感」的程式碼。 當程式碼架構設計的好，還貼心的附上完整的測試案例，要新增功能，要修bug都是一塊蛋糕，照著架構改好跑跑測試就搞定，感覺人生輕鬆愉快的那一瞬間，就會看成「無痛」的程式碼。 當看到好不容易重構後變得比較簡單的程式碼，一次又一次被加個阿紗布魯，天邊飛來的一朵邏輯的那一瞬間，就會看成「無力」的程式碼 當花了十年參透大師寫的那一行程式碼背後所隱含的大宇宙的奧秘的那一瞬間，就會看成「無極」的程式碼。 軟體進步到現在，開發測試部署全部都可以用程式碼控制，四輪傳動系統、行車主動安全系統，物聯網，OOXX什麼東西都會有程式碼存在，當我想到2XXX年還是有一堆人要寫程式碼的那一瞬間，就會看成「無限」的程式碼。 以上純屬嘴砲，我只是想表達這本書的中文標題，真的意義深遠...

我的BDD物語1 從開始使用TDD之後一年多，發覺不管是解Bug還是做Enhancement，沒有寫Test就會覺得全身不對勁，在這段期間，也看到了許多TDD進階到BDD的分享文章，像是 INTRODUCING BDD ，最有感的應該是這篇 WHAT’S IN A STORY? ，看了之後發覺原來寫User Story是很簡單的，有固定的格式，也可以很好的描述出系統的行為。之前看到那種厚重的文件裡面內含的Use Cases，我心想，到底這種文件誰會來維護，一定不是Developer...，不是Develper維護的結果就是文件跟不上code，基本上這種文件都要準備的很完整的形式，是給某些走 重裝 軟體流程的團隊，而我們寫code的時間都不夠了，哪有時間在那邊改一堆奇奇怪怪的Word、Excel、PDF。而以BDD的方式來作，只要寫出如下的Story: 就可以就寫Behavior Test，文件格式也很簡單，用普通文字檔就可以，也可以用Markdown之類的格式來呈現，在有需要與Product Owner或Feature Owner討論的時候就可以派的上用場，討論完馬上就可修改，寫Behavior Test時一想到其他Case也可以修改。 故事是這麼開始的 有了TDD的經驗與BDD的知識之後，我在開發N功能時就實際應用上去，N功能對我而言是有點莫名其妙的功能，感覺與我們系統的設計背道而馳，這部份我就不多說，總之，開了一次又一次的會，大概對實際需求有個譜，在還沒有開始寫Code之前，我就先寫出了一個又一個的User Story，其實撰寫User Story也沒辦法花太多時間，一開始大概一兩個下午斷斷續續就完成初版，由於系統裡還有很多面向，例如備份、升級、組態模板、事件、還有各式各樣的使用者行為，有些面向我也沒有實際接觸過，所以只能寫出User Story的Title。 接下來開始寫Code之後，我的方式是每個User Story對應一個Class，每個Scenario對應一個Test Method，每個Scenario都代表User的一個行為，當然也有系統因為狀態變化的行為。以TDD的方式來做，當然就是先把Test寫好，然後再去修改Production code裡面的內容，來滿足Test的結果。這個作法的好處在開發時我體會到幾項： 一邊寫會一邊思考...

最近有機會看RESTful API的設計，雖然自己沒有參與，但是也把握機會看了一遍。首先先從Http協定說起，Http協定不只用在傳輸Web的內容上，也有很多Client應用程式與Server溝通都使用Http協定，例如手機App，遊戲，甚至一些雲端的服務都是透過Http協定來提供服務。但是Http只是協定，至於要以什麼順序傳，傳什麼東西，其實都是自由的，所以也造成沒章法隨便亂寫的狀況，而REST風格是一個業界公認，我們自己也可以理解接受的一種解決方案。遵照REST的風格，做出來的架構因為Server不需要記錄執行狀態，所以天生就有較好的擴展性，簡單說，只要後端資料庫夠強，就可以一直水平擴充Web Server，透括負載分配進來Web Server的請求，就可讓支援使用者數量上到百萬。這就是無狀態設計屌的地方。 其實我家老大找到的這篇，就已經完整說明設計RESTful API各種要注意的地方： http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api 以下是個人簡單的筆記： 透過Http協定來提供服務有以下好處： Http協定已經是一個成熟穩定的傳輸協定，累積了業界的經驗，而且有許多的Http Server支援，不用自己再打造協定，只須選擇一種Http Server來使用，並把應用程式佈署進去。 Client端也有許多現成的Open Source實作，不需自行打造穩定可靠的Client端 協定都是以文字為主，理解與除錯較簡單 至於傳輸內容部份，應用程式相關資料，目前業界都是使用肉眼可讀的JSON，怕字串容量過大，各家http server都有現成的工具可壓縮。 安全部份有https可以使用，加密也不需自行處理，可以使用Open Source的Solution Http本身也支援Cache機制，善加利用對於處理大量讀取需求也會很有幫助。 REST：Representational State Transfer，含狀態傳輸，來自Roy Fielding博士的論文 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 是一種軟體架構風格，在目前的Web Service實現方...

來源： http://paulhammant.com/blog/branch_by_abstraction.html 接下來就看看Branch By Abstraction有多厲害，實際看下來，的確是一套很有用的方法，簡單來說，就是把整合的工分散到每日的開發中。但是要實行有一些現實的問題需要克服 當我要新加一個Feature，會改動3個Class，這3個Class可能所有Module都要參考，而且與其它Module的Code綁很緊，要抽成Abstraction要改動的地方也是會很多，根本就是翻了。 就算我做好抽象層，把所有Module參考到這三個Class的地方改為呼叫抽象層，這樣還是對Code有變動，也是有可能對產品造成衝擊。 如果這3個Class的修改連介面都換掉，整個Class改頭換面，煥然一新，原來的使用流程已經不在，就算有抽象層當緩衝，還是免不了對產品造成衝擊。 這些現實的問題，我想是可以克服的，第一就是要有完整的Test，Unit Test，Integration Test，UI Test，但是如果Test不夠完整，可以使用這招嗎？我想答案是肯定的，但是要邊做邊補Test。而沒有任何Feature Branch，大家都只看Trunk，也就是mainline，這件事對目前的我而言，簡直就是美麗的夢境！我自己參與的產品就有遇到這種狀況，目前是分支一個Branch來做，如果用Branch By Abstraction，新的東西就可以不用等好幾個版本之後才進mainline，也不用擔心如果合併回mainline，到底會是怎麼樣的地獄。如果我有機會參與決策，我一定直接就這麼搞。 另一點作者提到除了Release之外，完全沒有其它Branch，這點我還是有點存疑，除非有一套機制讓Developer拿著Commit去取得認證，保證不會Break掉任何東西。不然Developer自己一個人做測試還是有限，如何保證不Break mainline？如果一個產品的開發編制如下： 100個Developer 分成15個Team，有的Team人多，有的Team人少 25個Component，從Web UI，Mobile UI，Database，Domain，Infranstructure..... 有跨Component，跨Team修...

原文：  http://paulhammant.com/2013/04/05/what-is-trunk-based-development/   讀過了Perforce官方的mainline model的文件，又看到Google與Facebook都使用TBD，以及我自己在開發上遇到的問題，讓我想看看TBD到底如何可以幫助我們解決這些工程上的問題，看起來作者非常反對feature branch，而我自己親身經歷的感受也的確，要開feature branch，除非能做到Perforce官方推薦的經營方式，不然不只Merge會有災難，開發時也是災難連連。以人性角度來說，假設我做componentA，如果有10個feature branch都有componentA，那每個branch有問題我都要去看，我修了一個componentA的問題，由於每個branch分支出去的時間點不同，其它branch有的可能有，有的可能沒有這個問題，那我怎辦，只能等著人家來報問題，那我的時間很多都花在解這些Branch的問題上。如果採用的是TBD的概念，我只要保證trunk沒問題就可以了。或許在code撰寫方式上需要花很多工，但是我只需一次工，也可以將焦點集中在一個地方。對於我這種普通人，這是比較人性化的工作方式。 甚麼是TBD 一個軟體開發的分支模型，也被稱作mainline 同一個產品開發的所有人員共享一個Repository，有一個trunk，單一Developer或是Developer團隊可以有自己的private branch，所有修改最後都會回到主幹 只有在Release時才會有官方的分支，一般Developer不能對Release Branch作動作，只有Release Engineer可以更動Release Branch，當Release Branch完成它的任務，就會被砍掉。 Google與Facebook都採用這種分支模型 有需要Release才Branch Release之後的branch，就不會有大的更動，只有Release Engineer會進行將挑選Commit合併到Release Branch的動作 多一個Release Engineer的帽子 Bug先在trunk修好，之後把Commit合...