昨天看到博客園的一篇新聞《程序員的回歸式進(jìn)化》，該新聞非常有意思，展示了同一段“Hello World”代碼，一個1年編程經(jīng)驗、一個2年編程經(jīng)驗、一個3年編程經(jīng)驗、一個5年編程經(jīng)驗和一個10年編程經(jīng)驗的不同寫法。這些寫法中，讓人啼笑皆非的是5年工作經(jīng)驗的程序員編寫的代碼看起來如此的復(fù)雜、如此的有技術(shù)含量，而10年工作經(jīng)驗的程序員編寫的代碼竟然和1年工作經(jīng)驗的程序員是一樣的（除了注釋，這是升華），真是有點諷刺，呵呵～～。

不過，笑過之后，還是讓我忍不住陷入沉思。本人已經(jīng)寫了11年的C#代碼，寫了3年的Java代碼，還使用過匯編語言、C語言、Delphi、PowerBuilder、C++、ASP、PHP、C++ Builder等寫過不少代碼，經(jīng)歷的項目和產(chǎn)品也不算少了。我一直在追求如何使軟件開發(fā)變得更為簡單，這種簡單不僅僅是對于我自己，更是對于整個團(tuán)隊。

企業(yè)級軟件天生就是復(fù)雜的，為什么呢？如果一個軟件市場不錯的話，那么這個軟件總是會不斷的進(jìn)行演化，代碼數(shù)量總是在不停的增加。以Spring為例，0.91版本發(fā)布時只有1萬多點代碼，1.0發(fā)布時有2萬多代碼，1.2發(fā)布時有4萬多，2.0發(fā)布時有6萬多，2.5發(fā)布時有7萬行代碼（以上數(shù)據(jù)參考《Java應(yīng)用架構(gòu)設(shè)計》），代碼越多意味著越復(fù)雜。如果這些代碼中，還存在技術(shù)債、設(shè)計腐化、循環(huán)依賴等各種內(nèi)在的問題，那你想想看，如何使其回歸簡單？如果你加入一家公司，不幸的要去維護(hù)一個現(xiàn)有的系統(tǒng)，你如何回歸簡單？千萬別告訴我，你要重新編寫一套，這只是簡單的技術(shù)思維而已！

回過頭來，我們再看看那個5年經(jīng)驗的代碼。其實該程序員的寫法沒有錯，他已經(jīng)學(xué)會了如何使用DI進(jìn)行解耦合了，猜得不錯的話，他也是學(xué)會了設(shè)計模式，甚至掌握了一些OOP的設(shè)計原則。但是如果整個應(yīng)用系統(tǒng)都充斥了這樣的代碼，那我估計誰看誰發(fā)瘋！

那么這個懂DI、懂設(shè)計模式、懂OOP設(shè)計原則的有經(jīng)驗的程序員犯啥錯了？很簡單，我覺得他什么錯也沒有犯，他只是依然缺乏經(jīng)驗而已。

拋開團(tuán)隊管理和協(xié)作層面，我們單從技術(shù)層面來考慮，想要使應(yīng)用系統(tǒng)的開發(fā)變得簡單，有效的方法就是化整為零，將復(fù)雜大系統(tǒng)拆分成小的、簡單的、能夠組合的“代碼塊”，簡化系統(tǒng)開發(fā)并間接提高軟件系統(tǒng)的可維護(hù)性和可擴(kuò)展性。那問題是，這個“代碼塊”應(yīng)該是怎樣的粒度？下圖是軟件系統(tǒng)“自上而下”架構(gòu)圖（該圖參照《Java應(yīng)用架構(gòu)設(shè)計》），服務(wù)/子系統(tǒng)的粒度大，類的粒度小，系統(tǒng)的展現(xiàn)層粒度一般比較大，而數(shù)據(jù)訪問層粒度小。粒度越小，系統(tǒng)越抽象，越靈活；粒度越大，系統(tǒng)越簡單，可復(fù)用性越低，擴(kuò)展性越差。

想要使系統(tǒng)開發(fā)變得簡單，選擇“模塊”作為開發(fā)、復(fù)用粒度較為合適，模塊符合高內(nèi)聚、低耦合，在模塊內(nèi)部，我們傾向于使用1年工作經(jīng)驗或者10年工作經(jīng)驗的代碼，模塊內(nèi)部依賴關(guān)系較少，較為清晰，不宜在內(nèi)部搞太多的抽象。在我們的實踐過程中，模塊內(nèi)部不會使用IoC，也不太提倡使用太多抽象，會使用非常直接、簡單的編碼規(guī)則，使1年經(jīng)驗的開發(fā)人員能夠編寫模塊業(yè)務(wù)邏輯。那么5年工作經(jīng)驗的那些代碼適合在哪使用呢？

我的答案就是“模塊間的邊界”。通過對模塊間的邊界使用OOP的SOLID原則，能夠更大提高模塊的復(fù)用性和擴(kuò)展性，同時還能夠保持模塊內(nèi)部的簡單，這或許就是在技術(shù)層面回歸簡單的一種較好的方法了！

企業(yè)級軟件系統(tǒng)的復(fù)雜，不僅僅是技術(shù)層面，相反，管理與團(tuán)隊協(xié)作更容易影響系統(tǒng)的成敗。一個復(fù)雜軟件系統(tǒng)通常都是由團(tuán)隊協(xié)作來實現(xiàn)的，一個完整的團(tuán)隊通常有高級工程師、中級工程師和初級工程師，高級工程師負(fù)責(zé)架構(gòu)和設(shè)計、中級工程師負(fù)責(zé)編碼、初級工程師僅是入門。有效的解決三種層次工程師的協(xié)作，盡量減少交互、協(xié)作、學(xué)習(xí)的成本，能影響后續(xù)的維護(hù)成本。在我看來，良好的協(xié)作模型應(yīng)該促使三者的工作更加的Focus，專注于自己開發(fā)的業(yè)務(wù)邏輯。同樣的，模塊化也能夠很好解決三者的協(xié)作。一方面，通過模塊化，我們可以消除軟件架構(gòu)（或者成為統(tǒng)一架構(gòu)）；另一方面，高級工程師負(fù)責(zé)框架類模塊、中級工程師負(fù)責(zé)業(yè)務(wù)類模塊、初級工程師快速入門協(xié)助開發(fā)，三者可以進(jìn)行并行開發(fā)，而且代碼互相隔離，互不影響。從這個角度看，初級工程師的入門速度也將極大提高。

因此，回歸簡單的一個好方法就是：（1）化整為零，將系統(tǒng)進(jìn)行模塊化劃分；（2）在模塊內(nèi)部保持簡單，使用1年或者10年經(jīng)驗代碼，在模塊間交互部分的代碼使用5年經(jīng)驗的編碼更是，應(yīng)用OOP的SOLID、設(shè)計模式、SOA等抽象技術(shù)，提升模塊的可復(fù)用行和可擴(kuò)展性。