看到書中第三章的標題，已經隱隱知道作者要講述的情節。看完全章節後，果然不出所料，同時產生強烈地共鳴。下面從三個方面來闡述自己對於軟體開發小步快跑的理解。
（一）開發方式中的小步快跑
在軟體開發中，選用傳統瀑布模型的開發方式越來越突顯它的弊端。現在更易為專案組所認同的是敏捷迭代模型的開發方式。迭代的特點就是典型的小步快跑，它將乙個專案化整為零，分為幾個衝刺階段，每個階段都只針對當前開發的那部分內容。在整個開發過程中，與客戶充分互動，同時不斷對客戶發現的問題及時修正。由於將完整的專案拆分成小階段，步伐比對較小、頻率快，加上溝通比較順暢，最後開發出來的產品往往比較容易得到客戶的認可。而反觀傳統瀑布模型的開發方式，步伐太大，節奏緩慢。為何這樣說呢？開始的需求階段與最後的測試驗收階段，與客戶互動較多，而中間階段則很少與客戶交流，及時通過互動來糾偏。出現需求與測試驗收兩頭重，中間輕的情況，步伐不可謂不大！由於中間環節與客戶的溝通不到位，造成最後開發的產品與客戶預期有相當大的差距。專案的最後階段就是不斷地修改**，苦不堪言，極大打擊專案組的積極性！因此也常常造成專案的延期，進展相當慢。這裡所說的情節與書中出現的可能會有一些差別，但是書中提到：在整整數月的時間，我們都無法知道，我們做得對還是不對。這一點與上文所述相同，所以不約而同地，小步快跑就成為大家普遍認同的開發方式。
（二）編碼工作中的小步快跑
相信很多人提到重構，都會自然而然地想到那本名著《重構——改善既有**的設計》。初寫**，很想快速寫出漂亮的**，拋棄新手的帽子。書的內容還沒有完全看完，就有了一種修改**、優化**的衝動。可到底應該大刀闊斧地重構，還是小步快跑地重構，相信看完下文你心中會有答案。開始接觸重構時，看到**中有不少地方需要「動手術」，就噼里啪啦一陣猛改。改的時候那個舒坦勁就別提了，可是因為沒經驗，大幅度修改的過程中沒有及時跑一跑**，看看結果是否一切ok。到最後滿心期待地執行**時，整個人就傻了，為何那麼多bug？！接下來的時間真的慘了，不斷改不斷出現bug，原來感覺有「臭味」的**執行得好好的，可是後來感覺「香氣四溢」的**卻怎麼也跑不起來！焦急、無助、困惑……回頭認真看書，細細品味。接下來，那個豪氣沖天的修改方式沒了，取而代之的是頻繁地小幅修改，並及時驗證修改的準確性，真**到小步快跑的好處。
（三）將小步快跑走得更徹底些
書中運用小步快跑的方式，通過一段不斷重構的**進行演示。對於作者給出的最終**，個人覺得可以進一步優化。對於三八婦女節、五一勞動節、情人節之類的各種節日，我認為應該單獨提出來成為乙個節日類，用於統一維護所有的節日。這樣以後增加新的節日時，只需對這個類單獨修改即可。使用這個類時，通過傳入date由該類自行判斷是否為節日，如果是節日則返回該節日的名稱。不知這樣是不是更合理些？
重構是我很感興趣的乙個話題，期盼拜讀作者的佳作！
談談我對bloom filter的理解。
我們都看過封神榜吧，每乙個神位都對應著乙個人。在西周時代，如果乙個人聲稱自己是神，那麼他必須可以通過封神榜的驗證，如果封神榜驗證了下這個人，發現神位上根本沒這號人，那麼這個人絕對不是神。但是封神榜的驗證方式是有漏洞的，那些企圖依靠神的名聲招搖撞騙的人之中，有些人發現了這個秘密，他們可以通過偽造自己的...
談談我對flexbox的理解
寫在開頭 關於flex，學了很久的前端了，偶爾也在用，尤其是當需要水平居中的時候，就用display flex，感覺非常好用。但是其實對於flex的理解並不是很到位，根本都不懂flex，所以正兒八經的來研究一下flexbox。flex布局模型不同於塊和內聯模型布局，塊和內聯模型的布局計算依賴於塊和內...
談談我對DI的理解
本文中di指依賴倒置。依賴的概念 baidu百科 依靠別人或事物而不能自立或自給。軟體開發中的依賴 依賴描述了兩個模型元素之間的關係，如果被依賴的模型元素發生變化就會影響到另乙個模型元素。di的概念 a.上層模組不應該依賴於下層模組，它們共同依賴於乙個抽象。b.抽象不能依賴於具象，具象依賴於抽象。例...