我們部門是乙個基礎平台研發部門，主要為其他各部門提供技術介面和服務支援。
也正是由於這個特性，部門內正在考慮基於wcf搭建一套服務平台。
部門內提倡敏捷開發，談談我自己對敏捷的簡單理解。
一、明確需求
比如我們每天都要為別的部門提供很多介面，在開發過程中逐漸發現我們其實做了很多重複性的工作。
同時大量的技術介面（webservices呼叫、post呼叫）非常分散，難以管理。針對這種情況，我們迫切的需要一套統一的服務平台。
我們的目的就是能夠提供各種部門之間甚至是公司對外合作的技術介面支援。具體這個平台叫什麼，都包括什麼，可能還不是很明確。
二、合理的拆分需求
我們的目的很明確，所以我們決定對目前的需求進行分析。通過和各部門同事交流我們對目前存在的需求做了分析。一是從業務上拆分，我們可以
得到很多子系統。二是從技術上考慮，我們理出一些通用的基礎的功能以及支援業務擴充套件的功能。這樣呈現在我們面前的就是乙個個經過組合的子系統。
雖然目前的這個模式還是沒有名字，不過我們已經有了進行下去的勇氣。
三、迎接變化
在我們了解需求的過程中，部門的同事都會提到兩個字「目前」。「這是我們目前的工作。」，「這是我們目前存在的問題」。
沒錯，沒人敢**未來。我們也沒打算做一勞永逸的系統。但我們該如果應對變化呢？
了解變化點，我們做不到**未來。但我們可以盡力去掌握哪些地方有可能變，哪些地方會經常變。甚至能分析出他會朝著那個趨勢變。
一、「並列式」開發
將開發團隊分割成小組，不同的子系統交由各個小組負責開發。大家可以同年同月同日開工，不一定非得同年同月同日完成。總比一條線的「瀑布」要快的多。
二、關注**，以人為本
不必在開發的每乙個階段整理無窮盡的文件。整齊的**更能體現程式設計師的智慧型。可以沒有詳細設計，這樣其實更不害怕變化。
沒有計畫變化也就無所謂變化了。
三、迭代
這是迭代法的解釋：迭代法也稱輾轉法，是一種不斷用變數的舊值遞推新值的過程,跟迭代法相對應的是直接法（或者稱為一次解法），即一次性解決問題。
敏捷中鼓勵迭代，週期性的停下來歇一歇，看看過去幾天寫的東西，整理整理思路。其實這是我們在自己尋找變化。所以說敏捷的核心思想是適應變化！
總
這是我對敏捷的乙個很簡單的認識，期待您的高見！
談談我對bloom filter的理解。
我們都看過封神榜吧，每乙個神位都對應著乙個人。在西周時代，如果乙個人聲稱自己是神，那麼他必須可以通過封神榜的驗證，如果封神榜驗證了下這個人，發現神位上根本沒這號人，那麼這個人絕對不是神。但是封神榜的驗證方式是有漏洞的，那些企圖依靠神的名聲招搖撞騙的人之中，有些人發現了這個秘密，他們可以通過偽造自己的...
談談我對flexbox的理解
寫在開頭 關於flex，學了很久的前端了，偶爾也在用，尤其是當需要水平居中的時候，就用display flex，感覺非常好用。但是其實對於flex的理解並不是很到位，根本都不懂flex，所以正兒八經的來研究一下flexbox。flex布局模型不同於塊和內聯模型布局，塊和內聯模型的布局計算依賴於塊和內...
談談我對DI的理解
本文中di指依賴倒置。依賴的概念 baidu百科 依靠別人或事物而不能自立或自給。軟體開發中的依賴 依賴描述了兩個模型元素之間的關係，如果被依賴的模型元素發生變化就會影響到另乙個模型元素。di的概念 a.上層模組不應該依賴於下層模組，它們共同依賴於乙個抽象。b.抽象不能依賴於具象，具象依賴於抽象。例...