看到一篇關於代碼簡潔性的文章，感覺作者在追求代碼優質完美上有很深功力，我工作中會遇到很多精簡代碼，主要是利用一些c#新特性和一些重構思想，作者能如此清晰地寫清楚代碼簡潔的效果來，讓小弟很佩服。以下是其文章內容，博客出處是http://michael.nona.name/archives/2000-lines-of-code/
早在寫《架構腐化之謎》的時候，我就意識到，造成架構腐化的根本原因是系統複雜度變大的必然趨勢以及人類遺忘的天性。延緩項目腐化最好的方法，是根本不給腐化的機會。生活中，自然通風、陽光透亮、傢俱擺放合理的、不留死角的房間出現蟲子的可能性很低；代碼也一樣，一份簡單、符合直覺的代碼，放在複雜度完全可控的代碼庫中，能夠極大的降低學習的門檻以及避免腐化的可能。
包括自己在內，很多人當然以爲這只是美好的想法。絕大多數開發者僅僅能嚐到項目早期的甜頭，在後期則進入了愈發沉重的深淵。對於文中所說的似乎只是一個遙不可及的想法。爲了證明這個是否真的可行，從去年10月開始，我在自己的產品中進行了一個嘗試：在保持功能正常增長的前提下，項目總體功能代碼不超過2000行。
現在是什麼情況呢？從去年10月到現在，git統計數據如下
414 files changed, 42824 insertions(+), 698 deletions(-)
430次總共提交
Code LOC: 1568 Test LOC: 799 Code to Test Ratio: 1:0.5
功能代碼總共不超過1600行代碼（當然未包含大量的CoffeeScript以及HTML/Sass代碼），完成了大部分的核心業務邏輯。未來可見的功能也應該能夠在400多行的空間裏完成。系統中也存在不少能夠提取爲獨立Gem的地方，可以繼續進行隔離簡化。
應該說得益於Ruby簡潔的語法，以及在rubygems社區提供的各種高質量的gem，讓以前不可想象的麻煩變得幾行代碼就能搞定。
我們得到了什麼好處？今天新加入了一名程序員，花了點時間介紹產品背景之後，在不到2個小時的時間裏，就完成了一個典型的功能。並且還順帶修正了一些代碼上的Bug。
Rails固然是特例。但推廣到其他的語言，只要遵循以下原則，應該是毫無問題的：
- Don't Repeat Yourself - 絕對不要重新發明輪子。github上fork數量多的項目基本上已經相當成熟了。即便有問題，fork, fix, pull request的響應時間比以往任何一種方式都要迅速，還能回饋社區。
- 遵循約定，遵循約定。在某個時候總忍不住自己寫了類似於get 'cities/edit'在routes.rb中，但隨着類似的代碼越加越多，最終索性就變成了resources :cities. Rails是經過許多工程實踐的框架，其中的最佳實踐很多時候是經過驗證的。對於其他技術框架也應該一樣。有時候發現了異常情況，不要爲這種異常情況特殊處理，約定化也許是更好的方案。
- 隔離，隔離。凡是與核心業務無關的功能代碼，在找不到開源替代的時候，想辦法將其通用化。比如我們用到了解析openflights的機場數據。這部分與核心業務毫無關係，將其隔離爲Gem，再引用，能夠減少無關代碼干擾，形成知識分界，對於專注瞭解系統有莫大好處。
- 警惕未經使用的功能、代碼、註釋、甚至數據庫字段。保持代碼庫總在最精簡的狀態下。
這個產品已經上線。在可見的未來，2000行的界限還是夠用的。等到超過的那一天，我再寫寫看看。也許那一天可能永遠都不會到來。