原文首發(fā)于我的微信公眾號：GeekArtT.

將代碼分層，當(dāng)然是為了控制復(fù)雜度，讓你的管理井井有條。那為什么非得要建立多個不同的獨立文件夾，再創(chuàng)建不同的文件呢？

 

一個直接的考慮是，在同一個文件下，也就是同一個文本環(huán)境之下，當(dāng)然會有非常大的自由度去增添代碼，沒有任何的條款限制。但同樣是因為這樣的“自由”，它會讓管理處于失控。因為控制復(fù)雜度，就意味著將多個不確定性的東西固定下來，就需要有強制性的限制，而不是自由。有了更多的限制條件，才能讓你控制的主體按照你的思路去發(fā)展，去向同一個方向用力，而不是散沙一團(tuán)。這是一個經(jīng)典的因為有了更多的局限性，反而讓系統(tǒng)發(fā)揮出更強大的力量的例子。正如山路賽車，為了更快一點，就必須要用更小的馬力。

 

所以，為了讓你的“UI部分的代碼成一堆”，“數(shù)據(jù)連接的代碼成一堆”，“業(yè)務(wù)邏輯的代碼成一堆”，你必須給予這些部分強硬的限制，讓它們只能在特定的范圍內(nèi)出現(xiàn)。這就需要創(chuàng)建不同的文件夾，以及不同的源代碼文件。其背后的思維方式是：要用制度去控制組織，而不是依賴組織中每個成員的自身素質(zhì)；要用代碼去控制流程，而不是依靠腦海中的行為規(guī)范。

 

另一個需要提到的優(yōu)勢是，通過不同的文件創(chuàng)建以及不同文件夾的劃分，可以很好地解決名字沖突。每一個模塊都可能提供一些相同的功能，但卻需要不同的實現(xiàn)。如果你將所有這些“具備相同功能但需要不同實現(xiàn)”的函數(shù)放在同一個文本環(huán)境下，你將難以區(qū)分這些函數(shù)，并且會造成沖突。你當(dāng)然可以通過增添前綴的方式來解決沖突，但這樣會造成函數(shù)名的臃腫。但更為關(guān)鍵的是：如果你真的寫過稍微復(fù)雜一點的系統(tǒng)，你會發(fā)現(xiàn)在“數(shù)量龐大的一堆沒有分類”的文本中尋找一個代碼片段是件多么讓人焦躁的事情！你完全無