應該有很多人已經知道破窗效應【注1】這個社會學 （犯罪學）的詞語，破窗效應最先由社會學家James Q. Wilson和George L. Kelling在一篇名為《Broken Windows》的文章中提出【注2】：
“一個房子如果窗戶破了，沒有人去修補，隔不久，其它的窗戶也會莫名其妙地被人打破;一面墻，如果出現一些涂鴉沒有被清洗掉，很快 的，墻上就布滿了亂七八糟、不堪入目的東西;一個很干凈的地方，人們不好意思丟垃圾，但是一旦地上有垃圾出現之后，人就會毫不猶疑地拋，絲毫不覺羞愧。”
我們一直在喊敏捷開發，其實敏捷開發的一個很重要的目的就是消除浪費，防止破窗效應的發生。事情太難，就讓它簡單，更簡單。流程太重，就讓它輕點，更輕點。盡量掃清開發的障 礙，消滅破窗形成的環境。下面我會從軟件構建的很多方面來描述如何防止“軟件開發中的破窗”。
臟代碼
如果代碼不整潔，后來人就很難看懂，人們往往會對難以看懂的代碼失去耐心，不愿意進一步了解。如果不能進一步了解一部分代碼，也就難以改進它，這樣 帶來的一個后果可能有兩點：1、這段代碼被拋棄，然后重新編寫。2、直接復制這段代碼在別的地方使用。對于第一點，會帶來軟件開發中的浪費，而且再次編寫 也不可能就能一部到位的編寫正確，可能會引入新的bug。對于第二點，大家都知道重復代碼是設計走向腐化的根源之一。
如果我們在編寫代碼時能不斷的應用一些原則，確保我們的代碼易懂，自描述。在開發新特性時還不斷的使用重構手段，讓我們的設計保持一個良好的狀態。 我們就能防止窗戶被繼續打破。
測試
沒有測試，或者混亂的測試代碼都是破窗滋生的環境。
沒有測試
沒有測試時，當我們想對一塊代碼進行重構，我們就像沒有帶保險繩走鋼絲，步履維艱，生怕一下子失去平衡，掉下懸崖。這樣在我們的心中就產生了懼怕重 構的陰影，久而久之，我們就不去重構。最后帶來的結果就跟上面一段說的一樣，設計不斷的腐化，然后就失去了控制。
如果有了單元測試，有了驗收測試，當我們每做一下重構時，我們都可以從測試快速獲得反饋，每當紅條亮起時，我們知道我們破壞了一些已有的功能，我們 停下來去修復，當綠條亮起時，我們知道現在處于安全狀態，可以安心的繼續重構。一切都在我們的掌控之中，我們會喜歡上重構。
混亂的測試代碼
有很多人覺得測試代碼不是交付給用戶的產品代碼，可以區別對待，我們不需要花那么多時間琢磨變量命名，方法命名，我們也不需要關注重復的代碼。但 是……
混亂的測試代碼跟沒有測試是一樣的，甚至比沒有測試更糟糕。我們以為我們有測試，但測試卻給我們虛假的報告，當我們發現我們的重構破壞如此之深時， 已經為時已晚。即使測試能給出真實的報告，但如果測試代碼混亂，那么添加新的測試就非常困難，我們就會越來越懼怕添加新的測試。而且隨著產品代碼的演進， 測試代碼也需要伴隨著演進，測試代碼越混亂，我們就越難以修改測試，讓它反應出現在產品代碼的狀態。終于到了一天，大家決定拋棄測試，如是我們又回到了沒 有測試作保障的日子。
實際上，從某種程度上測試代碼的整潔程度比產品代碼的整潔程度更重要，因為有了好的測試我們可以無憂無慮的重構我們的代碼，即使現在我們的產品代碼 很糟糕也不怕，因為有了測試的保證，我們知道我們可以重構過去，如果我們只有混亂的測試代碼，我們那一線重構的希望都沒有了。
難以測試
可測試性是衡量代碼的一項準則。既然是準則一般都很難達到，如果代碼難以添加測試，在嘗試幾次之后，我們一般都會放棄編寫測試的想法。當我們嘗試對 一段代碼編寫測試時發現，這塊代碼鐵板一塊，與太多的其他類耦合，需要傳入很多重型對象的參數，比如與設備交互的代碼，與數據庫交互的代碼相耦合，這些重 型對象很難模擬或插樁。沒有辦法，在進度的壓力下我們只有放棄添加測試的想法了，那么如上面一樣，代碼就像草原上奔跑的野獸，失去了控制。
編寫可測試性的代碼是困難的，要將糟糕的代碼改進成可測的代碼尤其困難。但有一個訣竅，我們可以先編寫測試，用測試驅動出我們的產品代碼，這樣一開 始我們就獲得了一個個測試套件，將我們的產品代碼穩穩的固定在那里，就像走鋼絲時的保險繩；不僅如此，我們還獲得了可測試性的代碼。
測試運行太慢
實際上測試運行太慢是一種信號，該信號告訴我們耦合的太緊了。運行一個測試，需要編譯加載很多模塊。如果運行一個測試需要20分鐘，你希望頻繁的運 行測試么？如果運行一套測試需要10個小時，你希望測試多久運行一次？測試運行太慢就是第一個被打破的窗戶，如果不趕快修補，后面會有更多的窗戶被打破。
測試運行太慢，我們就不會頻繁的運行測試，測試也就不能提供立即的反饋，這樣測試的作用就大打折扣了。上面主要從代碼實踐方面來闡釋編碼中的破窗和如何防止破窗，其實在軟件開發的很多方面都存在類似的情況。
源代碼管理
有很多團隊因為各種各樣的原因采用了難以使用的源代碼管理工具，或者完全因為廠商對管理層的廣告宣傳，采用了一個無比重型，好看但不中用的工具。在 經受一兩次工具的折磨之后，團隊成員就會產生懼怕的心理，盡量的推遲提交代碼。提交代碼需要足夠的頻繁，甚至一次有意義的重命名都可以作為一次提交，這樣 在代碼復查的時候光閱讀提交代碼的注釋就能演示出代碼的演化過程。而且，如果每一次成功都有保存，這樣在犯錯的時候我們有機會后悔，我們有機會回滾到一個 成功的狀態。人的大腦雖然非常聰明，但也非常易于出錯，特別是在疲勞的時候，如果我們小步前進，小步提交，我們就能停在任何地方。你還記不記得那種必須到 某個時候才能保存當前狀態的電腦游戲？
有的時候并不是工具難以使用，而是環境使然。在分布式的團隊里，有可能網絡不穩定，遠程源代碼倉庫經常不可訪問，或者在提交代碼時需要連上VPN， 然后再提交，久而久之也會讓團隊成員懶于提交代碼。這樣我們就應該采用分布式的源代碼管理工具，比如Git。
難以集成
代碼寫完了并不是開發任務的結束。你還記不記得多少次為了集成產品，解決幾個模塊之間的沖突而加班加點。敏捷強調及時的反饋，持續的交付。如果集成 一次產品需要幾天時間，我們如何做到及時反饋呢？如果集成太困難，大家都會懼怕集成，就會盡量的避免集成，但產品最終是要集成的，所以到了最后期限的時 候，大家都在加班加點，但卻不是寫代碼，而是為了集成。
如果集成太困難，我們為什么不持續的集成呢？所有團隊成員都工作在同樣的分支上。持續集成服務器不斷的簽出最新的代碼，運行各種各樣的測試，最后構 建出可用的軟件出來。只要需要，任何時候我們都可以提供可以工作的軟件。
可視化
可視化是管理中的鐵三角之一。很多管理人員喜歡使用各種各樣絢麗的工具繪制出絢麗的圖表。比如使用Project做出精確到天的人員計劃，使用 PowerPoint做出產品的宏偉藍圖。好像將這些做出來，然后發給大家就有一種這個項目都在我的控制之內的感覺一樣。其實不管怎么優秀的軟件工具還是 比不上紙和筆。軟件打開需要時間，隨著軟件更新換代，軟件體積越來越大，打開一個龐大的Project文件甚至需要一兩分鐘的時間，而且文檔埋藏在電腦文 件系統的深處。找到文檔，打開，幾分鐘就已經過去了，別看這幾分鐘，久而久之我們就不想再去看這些東西了，我們以為這些東西都裝在了我們的腦中，但實際卻 沒有。花了很多精力編寫的需求文檔，最后成了一紙空文，當發現與需求不符的時候已經晚了。要防止這種事情的發現，我們就不要打破第一扇窗。
雖然到了二十一世紀，豐田公司還是在很多方面采用原始的看板。軟件開發中也是一樣，拋棄那些精美的軟件吧，將計劃，進度，用戶故事用最簡單的紙和筆 繪制，然后貼在開發人員抬頭就可見的墻上。不需要畫的多精美，因為越精美就越不想去修改，但軟件開發中永恒不變的是變化，我們必須隨需而變。
笨重的流程
有的公司給開發、測試、部署規定了嚴格的流程。開發人員想將產品功能部署到測試環境都需要與很多相關人員交互，提交申請單，然后才能由專人將剛剛修 改的一行代碼部署到測試環境中，進行測試。首先不說這個過程中有多少等待，多少浪費。光這笨重的流程就讓大家望而卻步，進而導致懼怕修改，連好的改進都會 受到抵制。
后記
軟件開發的方方面面就像一扇扇窗戶，不要打破第一扇窗戶，打破了也要趕快去修補，不然軟件就會隨著窗戶一樣，一扇扇的被打破，慢慢的腐化下去。
日本的豐田公司，在遠遠落后于福特和通用之后，采用5S的精益思想【注3】，成為后起之秀，而這5S（整理、整頓、清掃、清潔和素養）最終的目的就是 防止破窗效應。
注1： 經濟學上還有一個破窗謬論，但與此文沒有關系。
注2 ： 要了解破窗效應更多細節可以參見wiki：http://en.wikipedia.org/wiki/Broken_windows_theory
注3： 精益思想(Lean)是MIT對豐田生產方式(TPS)進行研究后的產物。關于豐田5S和精益思想（Lean）可以參看豐田的相關著作。