最近公司開始着手項目的重構，準確來說，公司半年前就已經開始準備重構。除了客觀因素外，只是有很多工作都是嘴皮子工作，或者寫文檔，畫藍圖去了。沒有真真正正地去做一些切實的事情。分析和設計固然重要，沒有落實，就像是很多零前面沒有1。
我本人是非常注重項目架構的，好的項目架構，無形中，凝聚了很多智慧，經得起段時間變遷和洗禮。可是，時常也會感覺到，這項目重構這樣的事情中，不同的項目情況，不同的公司團隊，總是會帶來不同的問題。這就帶來了技術思考之外的，我稱之爲理念思考。技術思考解決技術問題，理念思考解決人的思想問題。
我的從業經驗慢慢地告訴我，有的時候，理念思考上的煩惱和工作量，往往都非常非常，大於n多倍的技術思考。這裏面的原因很多。可能是好高騖遠，可能是追求形式，華麗的綵衣，也可能是設計過度，思考過度。有的時候，要是想着怎麼對接5年後的技術和業務。不如想着，先把手裏落後的3年的項目改到今年。一口喫個胖子，不光是難受，更加是不被接受的工作付出。
我聽說過，一些開發者說，這個項目是我一個人重構完成的，語氣當中充滿着自豪和驕傲。這是這的肯定的。反過來說，如果有幾個人和你合作，你能重構好嗎？要知道，想法過多，在IT開發中，往往都是一個阻礙。。人，尤其是程序員，是非常偏執的，不願意在主觀上接收別人的想法。而實際上，每個人，對於項目結構優化的思路，都不可能是百分之百完善的。
這個東西，先說到這裏吧。
今天要分享一個東西，這個東西應該很早就被移動開發圈子知道。
點擊鏈接：微信Android模塊化架構重構實踐
文章很長，講的很細，值的說到事，真的非常值的仔細看看。。我在這裏，提出來一些我個人感覺不錯的句子。也算是我的總結了。當然，我在意的這些句子。都是和技術無關的。
1，“君有疾在腠理，不治將恐深”
2，模塊邊界破壞、基礎工程中心化，都是代碼持續劣化的幫兇。
3，目前Android端App整體架設計上，除了聚焦在“大前端”之外，基本上都在“插件化/應用沙盒”上面下功夫。
4，不被監管的權利一定會發生腐敗” 。如果放到軟件開發的行當來說，就是“不被監管的代碼也一定會發生劣化”。所以代碼應該要接受“監管”。
5，在一個長期沒有改進的框架下，開發者的習慣可能會逐步變成跟隨式、保守式的開發。這大概可以被描述成“只要別人這樣做，我也這樣做，哪怕這麼樣的設計不好，但也不會錯”。經常能聽到有同學吐槽一些代碼，卻更少看到代碼在被改進。
6，讓他們可以放心參考。
7，代碼的邊界就像一堵牆，架構的劣化都是從這堵牆的瓦解開始的。
8，因爲代碼解耦從來不是問題，糾結的只是解耦行爲能不能讓人理解。我們要盡力避免的，應該是隨意拼湊和單純爲了類型解耦而解耦的情況。
9，用純粹的模塊化保持後續架構的靈活性和健壯性，重新強調依賴、強調應用狀態和生命週期、強化代碼的邊界。
最近也有看到另外一個東西。原文來自攜程的一個產品，這麼說的(當然，我是摘錄)。
... ...
當然，任何框架模式都不是全能的，MVCPI也存在它不足，如果有好的意見和建議，歡迎加入，一起討論推進框架模式的發展。
設計系統的組織，其產生的設計等同於組織之內、組織之間的溝通結構。
這些東西相信都是非常有益的。。如果看到這裏，你想着，"我們現在的項目，也要朝着這個方向去"... ... 。。。what's the fuck !! shit !!! 你們的項目是你一個人說的算嗎？你的項目有三四十五六十人的直接業務團隊嗎？你的項目有上億人的使用量嗎？你的項目會和哪怕微信這樣發展6年了嗎，也許，你的公司都不一定會生存6年，你的項目會向騰訊一下，一直被支持嗎？你的團隊會有年輕積極的正能量嗎？
so,如果你看了壯的，就想使勁喫，太沒腦子了。很多東西是可以學習的，不是讓你套用。