大家好，今天我跟大家聊一聊，對(duì)于一個(gè)編碼人員你如何逐步的具備軟件架構(gòu)設(shè)計(jì)的這么一個(gè)能力。因?yàn)榻?jīng)常我也收到很多朋友給我發(fā)的私信，詢問我如何從一個(gè)編碼人員快速的形成成長為一個(gè)軟件架構(gòu)師？

—1—

實(shí)際上我們可以看到，你從軟件編碼到能夠做設(shè)計(jì)到能做軟件架構(gòu)。它一定是有一個(gè)三到五年的周期的積累，對(duì)于這個(gè)過程沒有速成。而你要從軟件編碼轉(zhuǎn)到能夠做軟件架構(gòu)，我個(gè)人的核心的理解包括。

第一個(gè)點(diǎn)，你仍然需要大量編碼過程實(shí)踐。

因?yàn)槟憬佑|的項(xiàng)目多了，參與的編碼多了，做的功能模塊的開發(fā)多了，自然而然你在大量的積累后才會(huì)去考慮我如何去做歸類如何去做抽象。你沒有大大量的量的這個(gè)積累，你連素材都不夠，你怎么樣去做抽象？

第二個(gè)點(diǎn)，在編碼階段就需要培養(yǎng)設(shè)計(jì)意識(shí)。

在編碼階段你就要去培養(yǎng)我們常說的一些設(shè)計(jì)的意識(shí)和設(shè)計(jì)的思維。

因?yàn)槲医?jīng)常觀察到有一些開發(fā)人員，他當(dāng)他拿到一個(gè)功能需求的時(shí)候，其實(shí)這個(gè)功能怎么實(shí)現(xiàn)？

這個(gè)時(shí)候在他腦袋里面完全還是一團(tuán)漿糊的時(shí)候，你就會(huì)發(fā)現(xiàn)他已經(jīng)動(dòng)手寫 再寫代碼了。因此往往就是他想到哪里寫到哪里。如果在這種方式下面你就即使工作再久也很難去實(shí)現(xiàn)和提升你的設(shè)計(jì)能力。

你具備的一些設(shè)計(jì)思維并不是說你一定要用什么標(biāo)準(zhǔn)的UL建模工具，去做了完整的建模才叫設(shè)計(jì)工作。

當(dāng)你接到一個(gè)功能需求以后，你自己能不能在白紙上面用筆畫一畫，整個(gè)實(shí)現(xiàn)的流程，實(shí)現(xiàn)的核心的邏輯，究竟會(huì)涉及到哪一些關(guān)鍵的類？你完全可以提前把這些事情想清楚后再開始動(dòng)手去寫代碼。

比如原來我在早期參與工作的時(shí)候，更多的就是什么呢？

當(dāng)一個(gè)大的功能需求來的時(shí)候我們一般先應(yīng)該把相應(yīng)的類規(guī)劃好，類里面的核心的方法規(guī)劃好。然后才下一步的動(dòng)作才是開始寫具體的實(shí)現(xiàn)的代碼。這些都是可以參考的方法。

第三個(gè)點(diǎn) 我一直堅(jiān)持的觀點(diǎn)就是源代碼就是設(shè)計(jì)。

并不是說你實(shí)際輸出的代碼要寫多少注釋。寫的好的代碼應(yīng)該具備自解釋性，小到一個(gè)常量和變量的命名，本身就應(yīng)該有明確的含義。

所以我們?cè)趯懘a的時(shí)候你一定要去注意整個(gè)代碼的邏輯是不是清楚，它的可讀性究竟怎么樣？這個(gè)代碼轉(zhuǎn)給別人去做維護(hù)的時(shí)候別人是不是很通俗易懂？你對(duì)于大的方法函數(shù)是不是進(jìn)行了相應(yīng)的一些拆分？你涉及到的一些共性的方法是不是提取為公用的方法或者是函數(shù)？該抽象的一些關(guān)鍵接口是不是做了抽象？整個(gè)代碼你是簡單的實(shí)現(xiàn)了基礎(chǔ)的功能還是你足夠的考慮了這個(gè)代碼它本身應(yīng)該有的健壯性和可靠性？該做的異常捕捉你都做了處理？該記錄的日志是否都做了記錄？代碼實(shí)現(xiàn)該考慮的擴(kuò)展性是否都做了考慮？

這些東西不是說你到了設(shè)計(jì)階段才能做。實(shí)際在你編碼階段，你編碼多了以后 你自然而然就應(yīng)該去考慮這些問題。因?yàn)榫幊趟季S的本質(zhì)它就是一種抽象和復(fù)用的思維。這些能力完完全全可以在你編碼階段去做積累。

—2—

第一個(gè)階段完了以后 過渡到我們講的第二個(gè)階段。在第二個(gè)階段你要去培養(yǎng)你架構(gòu)設(shè)計(jì)的能力的時(shí)候，這個(gè)時(shí)候就有幾個(gè)關(guān)鍵點(diǎn)了。

第一個(gè)點(diǎn)?掌握形式化進(jìn)行架構(gòu)設(shè)計(jì)的通用方法

你需要具備一些我們常說的形式化進(jìn)行架構(gòu)設(shè)計(jì)的一些通用方法。

比如說我們常說的基于UML的面向?qū)ο蟮姆治鲈O(shè)計(jì)。你知道怎么基于4+1架構(gòu)視圖的思想，通過用例圖，類關(guān)系圖，活動(dòng)圖和序列圖等去描述核心的架構(gòu)運(yùn)行機(jī)制。這一些基礎(chǔ)的理論知識(shí)你仍然需要去學(xué)習(xí)。

第二個(gè)點(diǎn) 重構(gòu)加設(shè)計(jì)模式學(xué)習(xí)

第二個(gè)點(diǎn)就是結(jié)合你原來大量的編碼的一些經(jīng)驗(yàn)，我個(gè)人更加推薦的就是重構(gòu)加設(shè)計(jì)模式兩個(gè)內(nèi)容一起來看。

你不要單獨(dú)去看設(shè)計(jì)模式。因?yàn)樵O(shè)計(jì)模式本身也是前人大量實(shí)踐總結(jié)出來的一種應(yīng)對(duì)軟件可擴(kuò)展和變化的方法。所以更多的你還是應(yīng)該去看類似于軟件重構(gòu)的書。

你去學(xué)習(xí)軟件重構(gòu)的過程中你自然而然就會(huì)涉及到相應(yīng)的一些設(shè)計(jì)模式的思想。讓你逐漸的知道你整個(gè)軟件架構(gòu)的搭建怎么樣，做到更加可復(fù)用和更加可擴(kuò)展。

第三個(gè)點(diǎn) 培養(yǎng)你的架構(gòu)思維?

對(duì)于架構(gòu)簡單一句話來講軟件架構(gòu)它就是分而治之的藝術(shù)。

在整個(gè)分而治之的過程中你可以看得到，當(dāng)我們面對(duì)一個(gè)復(fù)雜的業(yè)務(wù)需求和業(yè)務(wù)場景進(jìn)來的時(shí)候，我們首先要具備大拆小的能力，將復(fù)雜的東西進(jìn)行分解，把它拆分為多個(gè)組件或者是多個(gè)子系統(tǒng)。

在拆解了以后，你還要去設(shè)計(jì)每個(gè)組件或者是子系統(tǒng)，它應(yīng)該暴露對(duì)外的接口。因?yàn)榻M件和組件之間只有通過接口去協(xié)同起來，最終才能夠滿足你最終的需求和業(yè)務(wù)流程。

分解只是第一步，更加重要的是在分解以后，你還要能夠把各個(gè)組件最終再集成回去，形成一個(gè)完整的整體，這個(gè)就是核心的架構(gòu)設(shè)計(jì)的思想。當(dāng)然在整個(gè)架構(gòu)設(shè)計(jì)的過程中，你同時(shí)還要去考慮抽象和復(fù)用，考慮有哪一些共性的能力可以把它抽象為獨(dú)立的業(yè)務(wù)組件或者是技術(shù)組件。

當(dāng)你具備了我剛才說的三方面的知識(shí)的積累的時(shí)候仍然是需要你有很多項(xiàng)目實(shí)踐的機(jī)會(huì)，在項(xiàng)目的實(shí)踐的過程中不斷的去完善你的架構(gòu)設(shè)計(jì)的技能。

所以架構(gòu)設(shè)計(jì)的東西絕對(duì)也不是簡單的你看過 一兩本類似于軟件架構(gòu)的書領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的書，你就能夠具備完整的架構(gòu)設(shè)計(jì)能力，更多的仍然是你去參與大量的架構(gòu)設(shè)計(jì)實(shí)踐，在實(shí)踐完以后才能夠回答你最終架構(gòu)設(shè)計(jì)的輸出是不是能夠真正的上線，真正的滿足業(yè)務(wù)系統(tǒng)的需求，同時(shí)在系統(tǒng)上線以后你還可以逐漸的去完善你原來架構(gòu)設(shè)計(jì)中出現(xiàn)的類似于集成的問題，類似于性能的問題 類似于可擴(kuò)展性的問題。

個(gè)人架構(gòu)設(shè)計(jì)的能力的提升就是不斷的迭代你原來架構(gòu)設(shè)計(jì)不足的地方，從而才能夠形成一個(gè)完整的架構(gòu)知識(shí)體系。