優(yōu)秀系統(tǒng)架構(gòu)設(shè)計(jì)師需要具備的條件

1、優(yōu)秀系統(tǒng)架構(gòu)設(shè)計(jì)師需要具備的條件優(yōu)秀系統(tǒng)架構(gòu)設(shè)計(jì)師需要具備的條件系統(tǒng)架構(gòu)師在軟件開發(fā)的活動(dòng)中起到了綱領(lǐng)性的作用，就像建筑 設(shè)計(jì)師一樣，從大的方向來給軟件定一個(gè)基調(diào)。軟件開發(fā)中碰到的 很 多問題，歸咎起來都可能和當(dāng)初的架構(gòu)設(shè)計(jì)有關(guān)，所以架構(gòu)師要 想不 成為眾矢之的，也不是容易的事情。各個(gè)行業(yè)甚至同一行業(yè)不同主攻方向的 team 都需要不同的架構(gòu) 師， 比方做soA勺很多架構(gòu)師實(shí)際上的職責(zé)是向用戶推銷自己的產(chǎn)品，即使有時(shí)采用其他方案更適合企業(yè)的情況，出于宣傳本公司產(chǎn) 品的需要， 也要貶低一番。當(dāng)然利益對(duì)架構(gòu)的影響不可防止，其他 行業(yè)也存在類 似的'情況。但是soA勺架構(gòu)師更多做的是把自己公

2、司的產(chǎn)品套用在客戶身上。當(dāng)架構(gòu)師是在設(shè)計(jì)自己公司的產(chǎn)品時(shí)，相 對(duì)來說會(huì)客觀一 些，從功能，性能，穩(wěn)定性，擴(kuò)展性，市場接受程 度和本錢等幾方面 來權(quán)衡。如果一個(gè)架構(gòu)師負(fù)責(zé)的僅僅是一個(gè)小的模塊，或者是一個(gè)小的應(yīng) 用程序，那么他所能施展的空間不太多， 包括操作系統(tǒng)， 硬件，驅(qū) 動(dòng)， 其他模塊的接口等都是已經(jīng)確定的了，甚至自己的模塊需要哪 些接口 暴露給別人也都是定義好的了，那么這個(gè)架構(gòu)師該做些什么呢?從別的程序或者系統(tǒng)來看，這個(gè)應(yīng)用程序至少要具備以下幾個(gè)條 件才能算 是合格的：1、 完成此應(yīng)用程序的基木功能。如果這是一個(gè)通信程序客戶端,那么它至少應(yīng)該完成客戶端所具有的功能，通過所有的測試用例。 不

3、同的功能是需要不同的組成架構(gòu)的，從降低復(fù)雜度和提高可維護(hù)性的角度來考慮對(duì)系統(tǒng)進(jìn)行解構(gòu)，往往是最直觀的做法。2、健壯性。這個(gè)程序不應(yīng)該輕易的 crash, 如果是界面程序， 在 而對(duì)異常情況的時(shí)候采取柔和的方式來通知用戶。如果是被別的 程序 所使用的庫，保持健壯性更是非常重要。作為架構(gòu)師，應(yīng)該采 取一定 的措施來保證模塊的正確工作，至少應(yīng)該保證在出錯(cuò)的情況 下能夠比 較容易的區(qū)分是否是本模塊造成的。 也許有人說這是 design 和 program 的事情，但是架構(gòu)師如果不在綱領(lǐng)上制定策略和 要求，實(shí)現(xiàn)上也是很 難操作的。3、低的資源消耗。我碰到很多軟件架構(gòu)，在架構(gòu)文檔里看時(shí)非常華美，用了很多模

4、式，一個(gè)普通的應(yīng)用要拆分成多個(gè)進(jìn)程，再用 MVC 別離各個(gè)模塊，加上一大堆監(jiān)測器適配器過濾器等，可以說模 式是能 帶來一些好處的，但是往往代價(jià)是更多的資源消耗，內(nèi)存占 的多了， 性能下降了，邏輯變得更復(fù)雜了。作為架構(gòu)師一定要權(quán)衡 , 而不是為 了表達(dá)自己的知識(shí)能力。最好的情況是，能夠給出在各種 usecase 下 模塊或應(yīng)用對(duì)資源的消耗程度，比方會(huì)占用多少內(nèi)存， 某個(gè)接口需要 多長時(shí)間等。因?yàn)楝F(xiàn)在的接口定義一般都只是定義使 用方式，包括函 數(shù)名和參數(shù)列表，至于使用時(shí)的代價(jià)由于沒有說明 , 往往成為模塊使 用者和提供者之間爭論的焦點(diǎn)。從程序員的角度來講， 可維護(hù)性往往更為重要， 因?yàn)榫S護(hù)的階段

5、比 開發(fā)的階段更長，而對(duì)的壓力也更大，而且由于各種各樣的原因 , 經(jīng) 常要一個(gè)新手來維護(hù)這個(gè)程序，如何讓新手很容易的理解它并且 馬上 具備解決問題的能力，對(duì)架構(gòu)師來說也不是一件可以推卸的責(zé) 任，采 用常見的設(shè)計(jì)模式，制定或采用通用的代碼風(fēng)格，完善相關(guān) 的文檔等 等，都是好的 practiceo對(duì)于那些高層次的架構(gòu)師來說，因?yàn)槊鎸?duì)的是由很多模塊應(yīng)用組 成的系統(tǒng)，他所要處理的實(shí)際上如何協(xié)調(diào)各模塊關(guān)系，保證整個(gè)系 統(tǒng) 的功能性能和穩(wěn)定性，至少他應(yīng)該了解各個(gè)應(yīng)用所具備的功能， 基于 此來制定各個(gè)模塊之間的接口。在必要的時(shí)候，要去掉那些作 用不大 但影響整個(gè)系統(tǒng)性能和穩(wěn)定性的模塊，對(duì)各個(gè)模塊的可選功 能也要做 一定的限制，不能允許其無限制的膨脹。架構(gòu)師也往往面 臨著