架構爲何會腐化

架構腐化一詞我已經忘了從哪本書上看到的了，可是這個詞給我留下了很是深入的印象。關鍵在於「腐」一詞，充分而又形象的描述了架構是怎樣一步一步從簡單清爽走向複雜污穢的。請容許我用「污穢」一詞來描述一個糟糕的架構，由於糟糕的架構就像是一潭散發着臭味的淤泥，讓你不想靠近，一旦涉入其中就會難以自拔，苦不堪言。

我相信全部的開發者都不但願本身的參與項目是一潭淤泥，可是爲何會出現這麼多糟糕的架構呢？難道是項目最初的設計者經驗不夠，又或者項目開發週期太趕？我認識事實並不是如此。如今，軟件開發者的水平都廣泛提升了，由於咱們有前人那麼多經驗能夠借鑑，連剛畢業的大學生也知道用MVC模式來搭建框架。難道是MVC模式太挫了，不夠用，實際上80%的項目用MVC模式足以應對。那究竟是什麼緣由致使了項目腐化呢？我認爲有如下三個緣由：

 

1. 不理解項目的業務價值

實際上，幾乎全部的軟件（尤爲是商業軟件）都有其所屬的業務價值，理解你所開發的軟件的業務價值對項目的成功來講相當重要。我發現不少程序員對業務需求不屑一顧，而對那些所謂的非功能性需求盲目的崇拜和追捧，其實這是一種本末倒置的行爲。

現實世界是一個商業的世界，而商業世界則會充斥着各類各樣的業務邏輯。理解這些業務邏輯會極大地增長你的見識、拓寬你的視野。若是你是一個在金融行業工做的程序員，那麼長時間在金融領域工做的精力將極大地提升你的市場競爭力。可是若是你不肯意花時間去學習金融領域的知識，而是去盲目的追求最新的技術，那麼其實你是丟芝麻撿西瓜，浪費了這個行業帶個你的附加價值。我不是不鼓勵程序員瞎折騰，實際上我本身有時候也喜歡瞎折騰，倒騰一些新玩意，這視乎是程序員的一種天性。個人意思是說不要放棄瞭解本身所在行業/領域的知識視爲不見，而盲目的追求其餘的「高大上」的技術。

爲何說理解項目的業務價值相當重要呢，那是由於只有理解了其業務價值你才能識別出來這個項目的核心領域所在，這樣這個項目纔不會走偏。傳統的軟件開放流程中有一個很是重要的角色存在，叫作「業務分析員」，他的工做在項目的概要設計和詳細設計解決十分重要。雖然我也沒見過有專職的人員幹這個，可是這倒是很是重要的一個角色。他會幫你分析你的業務，和產品經理溝通，理解產品的真正意圖。在這個溝經過程中，你的領域模型也就逐漸的清晰起來了，哪些是核心哪些是支撐部分也就清楚了。

有些程序員在接到產品需求後立馬就開始工做了，吭哧吭哧地擼袖子上陣，我認爲這是十分要不得的。接到產品需求的第一反應不是要想着我要建哪些表哪些字段，而是要多問問本身這個需求是幹啥的，產品經理真正的意圖是啥，爲何要我來作，跟個人系統有啥關係。千萬不要盲從產品經理的話，實際上有些時候他們本身也不知道本身要幹啥，爲啥要這麼幹。這個時候必要的交流是不可少的，隨着對話的深刻，你和產品對真是的需求都會有着更深地認識。新人和實習生在這方面經驗每每不足，此時最好找一個比較資深的程序員幫你梳理一下業務流程。

相反，若是你不知道你的系統的業務價值或者核心所在，什麼需求你都來着不拒，那麼恭喜你，你的系統正在腐化。當你在抱怨說「爲何這個業務要放在我這裏」，「這個我有什麼關係」之類的話的時候就能夠聞到一絲「腐化」的聞到。你可能會說項目工期緊、人手太少、需求太多以內的外部緣由，因此臨時地先加到系統中搞一下。Ok，這沒有任何問題。可是我仍是要說，你知道你的系統的核心價值所在嗎？若是你的回答是Yes，那麼恭喜你，你是一名合格的程序員了。不然，你可能須要學習一下技術以外的東西的了－那就是溝通。

 

2. 過分設計

軟件開發的頭號敵人就是複雜度。如今軟件開發是如此的困難，動不動就有十幾萬行代碼出現，可是現實世界就是如此的複雜，不會由於你採用某種架構或者奇淫巧技就能把代碼行數降下來。好的架構設計會將系統的複雜度控制在一個合理的範圍以內，由於人所能駕馭的代碼行數最多也就幾十萬行，若是一個系統的代碼行數達到百萬行，那麼這個系統就很危險了。如今微服務架構如此火爆，不得不說有這方面的緣由。

若是你在設計一個新系統，那麼我須要提醒你必定要控制好複雜度。一個好的系統的核心域每每是簡單的、直觀的，其餘人很快就能理解其核心的工做原理。若是一開始系統設計的十分複雜，那麼這個系統的擴展性就會不好，後續的維護將不可想象。可是是否是在設計之初就徹底不考慮後續的變化了呢？個人建議是你只須要把你的核心領域模型建好，多問問本身系統最核心的價值是提供什麼服務的，照着這個方向去設計，那麼你的系統就不會走偏。靈活性和可擴展型每每只是領域模型的延伸，這是一個水到渠成的過程。

非要給個度的話，我認爲5%剛恰好。不要出現超過5%的跟你本次需求無關的概念和行爲，並且這5%仍是你能肯定在不久的未來就會使用的擴展。

仍是那句話，好的設計每每是簡單的，複雜是萬惡之源。

 

3. 懶於重構

過分設計很差，徹底不設計也不行，尤爲是隨着敏捷開發的流行，持續交付優於提早設計的思想逐步流行。如今軟件交付速度是如此之快，頗有可能剛剛設計好的系統，下個月就全變樣了。應對這種變化的惟一方法就是持續重構。

沒有任何設計能預料到將來的變化，代碼可能會發生變化。新的功能會持續的添加進來，老的功能也在持續的改變。並且每次迭代或者交付，均可能會對核心領域產生影響。千萬不要對這種影響視而不見，由於它在改變着你的領域模型。正確地方式是常常調整領域模型以適應新功能所帶來的變化，雖然每次調整的幅度可能很小，可是這卻能讓你的領域模型處於健康的工做狀態。沒有領域模型或者系統在一開始就是完美的，之因此它們能在後續的迭代過程當中良好的工做離不開不斷地重構。

重構不是等到你的系統無藥可救的時候纔想到的事，而是應該在其不斷開發過程當中一直進行的工做。若是說持續交付提升了你係統的競爭力，那麼持續重構則是這種競爭力的有力保障！

以上三點是我認爲架構腐化最致命的緣由，不少思想來源於DDD、重構和敏捷開發。linus torvalds曾經說過：

Talk is cheap. Show me the code.

我認爲Talk is not cheap, 好的思想和開發方式價值連城，想好了再作會提升你的工做效率，從而提高你的生活品質。

本文來自網易雲社區，經做者蔣文康受權發佈。

原文地址：架構爲何會腐化

更多網易研發、產品、運營經驗分享請訪問網易雲社區。