架構腐化一詞我已經忘了從哪本書上看到的了，但是這個詞給我留下了非常深刻的印象。關鍵在於「腐」一詞，充分而又形象的描述了架構是怎樣一步一步從簡單清爽走向複雜汙穢的。請允許我用「汙穢」一詞來描述乙個糟糕的架構，因為糟糕的架構就像是一潭散發著臭味的淤泥，讓你不想靠近，一旦涉入其中就會難以自拔，苦不堪言。
我相信所有的開發者都不希望自己的參與專案是一潭淤泥，但是為什麼會出現這麼多糟糕的架構呢？難道是專案最初的設計者經驗不夠，又或者專案開發周期太趕？我認識事實並非如此。現在，軟體開發者的水平都普遍提高了，因為我們有前人那麼多經驗可以借鑑，連剛畢業的大學生也知道用mvc模式來搭建框架。難道是mvc模式太挫了，不夠用，實際上80%的專案用mvc模式足以應對。那到底是什麼原因導致了專案腐化呢？我認為有以下三個原因：
實際上，幾乎所有的軟體（尤其是商業軟體）都有其所屬的業務價值，理解你所開發的軟體的業務價值對專案的成功來說至關重要。我發現很多程式設計師對業務需求不屑一顧，而對那些所謂的非功能性需求盲目的崇拜和追捧，其實這是一種本末倒置的行為。
現實世界是乙個商業的世界，而商業世界則會充斥著各種各樣的業務邏輯。理解這些業務邏輯會極大地增加你的見識、拓寬你的視野。如果你是乙個在金融行業工作的程式設計師，那麼長時間在金融領域工作的精力將極大地提高你的市場競爭力。但是如果你不願意花時間去學習金融領域的知識，而是去盲目的追求最新的技術，那麼其實你是丟芝麻撿西瓜，浪費了這個行業帶個你的附加價值。我不是不鼓勵程式設計師瞎折騰，實際上我自己有時候也喜歡瞎折騰，倒騰一些新玩意，這視乎是程式設計師的一種天性。我的意思是說不要放棄了解自己所在行業/領域的知識視為不見，而盲目的追求其他的「高大上」的技術。
為什麼說理解專案的業務價值至關重要呢，那是因為只有理解了其業務價值你才能識別出來這個專案的核心領域所在，這樣這個專案才不會走偏。傳統的軟體開放流程中有乙個非常重要的角色存在，叫做「業務分析員」，他的工作在專案的概要設計和詳細設計解決十分重要。雖然我也沒見過有專職的人員幹這個，但是這卻是非常重要的乙個角色。他會幫你分析你的業務，和產品經理溝通，理解產品的真正意圖。在這個溝通過程中，你的領域模型也就逐漸的清晰起來了，哪些是核心哪些是支撐部分也就清楚了。
有些程式設計師在接到產品需求後立馬就開始工作了，吭哧吭哧地擼袖子上陣，我認為這是十分要不得的。接到產品需求的第一反應不是要想著我要建哪些表哪些字段，而是要多問問自己這個需求是幹啥的，產品經理真正的意圖是啥，為什麼要我來做，跟我的系統有啥關係。千萬不要盲從產品經理的話，實際上有些時候他們自己也不知道自己要幹啥，為啥要這麼幹。這個時候必要的交流是不可少的，隨著對話的深入，你和產品對真是的需求都會有著更深地認識。新人和實習生在這方面經驗往往不足，此時最好找乙個比較資深的程式設計師幫你梳理一下業務流程。
相反，如果你不知道你的系統的業務價值或者核心所在，什麼需求你都來著不拒，那麼恭喜你，你的系統正在腐化。當你在抱怨說「為什麼這個業務要放在我這裡」，「這個我有什麼關係」之類的話的時候就可以聞到一絲「腐化」的聞到。你可能會說專案工期緊、人手太少、需求太多之內的外部原因，所以臨時地先加到系統中搞一下。ok，這沒有任何問題。但是我還是要說，你知道你的系統的核心價值所在嗎？如果你的回答是yes，那麼恭喜你，你是一名合格的程式設計師了。否則，你可能需要學習一下技術之外的東西的了－那就是溝通。
軟體開發的頭號敵人就是複雜度。現在軟體開發是如此的困難，動不動就有十幾萬行**出現，但是現實世界就是如此的複雜，不會因為你採用某種架構或者奇淫巧技就能把**行數降下來。好的架構設計會將系統的複雜度控制在乙個合理的範圍之內，因為人所能駕馭的**行數最多也就幾十萬行，如果乙個系統的**行數達到百萬行，那麼這個系統就很危險了。現在微服務架構如此火爆，不得不說有這方面的原因。
如果你在設計乙個新系統，那麼我需要提醒你一定要控制好複雜度。乙個好的系統的核心域往往是簡單的、直觀的，其他人很快就能理解其核心的工作原理。如果一開始系統設計的十分複雜，那麼這個系統的擴充套件性就會很差，後續的維護將不可想象。但是是不是在設計之初就完全不考慮後續的變化了呢？我的建議是你只需要把你的核心領域模型建好，多問問自己系統最核心的價值是提供什麼服務的，照著這個方向去設計，那麼你的系統就不會走偏。靈活性和可擴充套件型往往只是領域模型的延伸，這是乙個水到渠成的過程。
非要給個度的話，我認為5%剛剛好。不要出現超過5%的跟你本次需求無關的概念和行為，而且這5%還是你能確定在不久的將來就會使用的擴充套件。
還是那句話，好的設計往往是簡單的，複雜是萬惡之源。
過度設計不好，完全不設計也不行，尤其是隨著敏捷開發的流行，持續交付優於提前設計的思想逐步流行。現在軟體交付速度是如此之快，很有可能剛剛設計好的系統，下個月就全變樣了。應對這種變化的唯一方法就是持續重構。
沒有任何設計能預料到未來的變化，**可能會發生變化。新的功能會持續的新增進來，老的功能也在持續的改變。而且每次迭代或者交付，都可能會對核心領域產生影響。千萬不要對這種影響視而不見，因為它在改變著你的領域模型。正確地方式是經常調整領域模型以適應新功能所帶來的變化，雖然每次調整的幅度可能很小，但是這卻能讓你的領域模型處於健康的工作狀態。沒有領域模型或者系統在一開始就是完美的，之所以它們能在後續的迭代過程中良好的工作離不開不斷地重構。
重構不是等到你的系統無藥可救的時候才想到的事，而是應該在其不斷開發過程中一直進行的工作。如果說持續交付提高了你系統的競爭力，那麼持續重構則是這種競爭力的有力保障！
以上三點是我認為架構腐化最致命的原因，很多思想**於ddd
、重構和敏捷開發
。linus torvalds曾經說過：
talk is cheap. show me the code.
我認為talk is not cheap, 好的思想和開發方式價值連城，想好了再做會提高你的工作效率，從而提公升你的生活品質。
架構腐化之謎摘錄
目前佔據主流的陣營有 人們喜歡簡潔。但這更多的看起來是乙個謊言 沒有多少團隊能夠自始至終保持簡潔。人們喜歡簡潔只是因為這個難以做到。並不是說人們不願意如此。很多人都知道軟體開發不比其他的勞動力密集型的行業 人越多，產量越大。人月神話 中已經提到，專案增加更多的人，在提公升工作產出的同時，也產生了混亂...
為什麼你會覺得微服務架構很彆扭
很多系統遷移到微服務架構之後，並沒有明顯感覺到微服務架構帶來的優勢，反而覺得帶來了更高的複雜度，王啟軍在 持續演進的cloud native 書中總結了七種微服務架構沒能發揮出固有優勢的原因，看看自己 中槍 了沒！微服務架構和傳統的架構方式思路完全不一樣。例如傳統方式實現高可用，更相信流程，更相信k...
激勵為什麼會失效
摘要 不是注重用外部的力量來激勵員工，而是要用認可和獎勵點燃員工的心中之火。點評 著名的調查公司sirota survey intelligence的一項大型調查表明，大約85 的公司的員工，在入職的時候都是情緒高漲，但是在工作6個月之後，熱情會急劇下降，並在以後的工作中會持續下降。也許正因為這個現...