我國傳統(tǒng)文化上，要做成一件事，講究三個方面：明道，優(yōu)術，取勢。在軟件架構設計方面而言，也是類似的道理：遵循自然規(guī)律以明確大的方向，使用優(yōu)秀的實操戰(zhàn)術，再根據(jù)實際情況落地。
這是個快餐年代，幾乎所有人都只做一件事 -“取勢”。 幾乎沒有多少人會去理解一個Servlet的工作原理，去理解一次HTTP請求的完整流程，因為有超多框架幫你屏蔽了這里的細節(jié)。詢問一個人會什么技術，回答也往往是我會Hibernate、Spring、Ibatis、會PullToRefresh組件、會使用SDWebimage。不過這些框架（Framework）其實并不是軟件架構。軟件架構是一所有生命力的房子，而這些框架只是大一點的板磚。
因為筆者水平有限，這里只提一些普遍準則，也就是”正確的廢話“，以饗視聽。不會深入到實操戰(zhàn)術上，比如怎么用Spring實施MVC架構，怎么使用Maven管理依賴，Redis的常用操作，怎么搭建一個負載均衡的集群，如何使用阿里巴巴的Dubbo框架進行服務化等等。如果大家有興趣，可以自行搜索，有很多優(yōu)秀的文章可供參考。
不幸的“程序猿”和“程序媛”各有各的痛苦，幸福的程序員都是相似的。其實說幸福有點言過其實，下面就說說怎么讓他們不那么痛苦。
“At the bottom of every person's dependency, there is always pain, Discovering the pain and healing it is an essential step in ending dependency.” --Chris Prentiss
他們都在一個相對穩(wěn)定的軟件架構里編碼，自己的代碼不會依賴很多模塊，不會因為自己微小的改動造成全局的失敗。正如"1984"中的老大哥說的，Ignorance is strength（”對外界的“無知就是一種力量）. 任何一個模塊都不能有太強的存在感。
曾經(jīng)在一個大型互聯(lián)網(wǎng)公司里面，任何人只要用到一個核心模塊的功能，就必須依賴一個部署在某遠程服務器的庫，而且還有IP限制，只能把代碼部署到指定網(wǎng)段才能運行起來。導致基本上沒法在本地進行單元測試或者簡單調試。這個核心庫的存在感太強，就成了開發(fā)的瓶頸，嚴重的降低了生產(chǎn)力和碼農(nóng)的幸福程度。
在“風語者客服+”的架構中，每個碼農(nóng)都可以很方便的在本地把服務啟動起來，一分鐘up and running，隨便做一些改動就可以立竿見影的看到效果。這里要歸功于幾個東西：
1. Git代碼管理
在團隊作戰(zhàn)中，每個程序員可以取下來完整的最新代碼庫，也可以在本地分支上盡情揮毫潑墨，而不擔心影響別人的工作。也可以把本地修改先stash起來，review一下別人的代碼，再unstash恢復回來。要想提高團隊效率，代碼倉庫管理建議盡快遷移到Git上。
2. Maven、Gradle、Cocopods等依賴管理
Maven是一個管理依賴（Dependency）的工具，現(xiàn)在在Java社區(qū)應該是比較普及的，無法想象現(xiàn)在還有團隊直接拷貝jar包來管理依賴。雖然早期沒有Maven的時候，都是拷貝jar包這么過來的，碰到的問題也是顯而易見的，依賴的jar包作者改了某個bug，沒能及時傳導到調用方。多個調用方使用不一致的jar包，導致各種奇異bug。對應的在安卓社區(qū)，使用gradle的比較多，iOS的Objective-C開發(fā)中，多采用CocoaPods。
