此文是本人今天在重讀bob大叔的《敏捷軟體開發》第六章後的乙個小小讀後感。
首先，bob先和同伴打個招呼，讓這次合作有個愉快的開頭。
然後是乙個極短的討論，他們確定需要寫乙個保齡球計分程式，順便畫了乙個簡單的類圖，把驗收測試單也畫了出來。
剩下的就是編碼，在編碼期間，他們在不停的尋找物件和方法的蛛絲馬跡，不是靠想，而是靠**和測試進行嘗試。物件總是在測試中建立，測試中修改，相對來說測試的修改就少了不少，不過在思考了實際使用後，測試也會做一些調整，構想物件不同使用方式，使得測試不停的增加，新增加的測試如果無法通過，又促使物件**的修改，如果物件**變得冗長，方法變了味道，發現了便重構，重構後往往會帶來物件和方法修改的跡象甚至建立新物件和新方法。如此反覆直到大家都覺得程式的意思很清楚，測試很全面且正常，**很美觀。在這個過程中他們會為對方的想法喝彩，但他們也會為不同意見而扯皮，但他們對這種問題的解決方法就是，誰有疑義誰寫**證明自己觀點。
以上就是這個實踐的濃縮，你發現什麼了沒？不錯，在這次實踐中，他們把物件和方法的搭建分布在工作的每個角落，他們雖然開始的時候畫了乙個類圖，但是他們從來不認為那就是框架的全部，很快他們用測試推翻了這個設計，並在測試中建立了新的物件和方法。思考、編寫、測試、交流貫穿全程。這個鮮活的例項讓我感受到敏捷開發人性化的魅力。那麼你呢？
巢狀事務的一次實踐
最近在乙個專案中，需要實現自動對賬功能，收銀機會定時對比本地和遠端的訂單，遠端發現缺少的，會自動補全。所謂補全，就是批量插入缺失的訂單。基於這個場景，就存在乙個細節的問題，因為插入訂單涉及兩個表，如果某些情況下，乙個表插入失敗，訂單插入事務需要回滾。但是不能回滾之前插入的訂單資料，顯然這裡就設計子事...
一次元件化的實踐
更新 1.mvvm 可以將網路層轉移到viewmodel 層中，這樣就不需要將網路層抽離了，因為本來就沒和 控制器耦合。2.每次使用蜂巢的時候 控制器一定要實現 服務的協議，不然蜂巢會崩，還很難找到原因 3.蜂巢方案 雖然分離了控制器業務的耦合，但是引入了protocol 協議的耦合。同時需要維護 ...
js方法佇列的一次實踐
場景 專案中有乙個需求，發布故事線，發布會呼叫乙個介面，改介面返回進度條的必要資訊，進度資訊由mqtt推送過來，在正常網路情況下，介面返回速度應該比mqtt推送先一步完成，但是在網路慢的情況下，介面就遲於mqtt推送的速度。mqtt會推送多條訊息過來，執行多次 這樣會造成進度條卡死的現象。解決辦法 ...