開發(fā)和架構(gòu)的界限難以捉摸。有些人告訴你它根本不存在，架構(gòu)只是開發(fā)者們所做的設(shè)計(jì)過程的簡(jiǎn)單擴(kuò)展。 另外一些人認(rèn)為這是一個(gè)鴻溝，它只能由那些做到高度抽象，而且不會(huì)陷入實(shí)現(xiàn)細(xì)節(jié)的開發(fā)者才能跨越。通常，在這兩個(gè)極端的觀點(diǎn)中間某處有個(gè)可操作的平衡點(diǎn)；不論如何，怎么從開發(fā)轉(zhuǎn)換為架構(gòu)師都是個(gè)有趣的問題。

　　經(jīng)常被用來區(qū)分軟件架構(gòu)和軟件設(shè)計(jì)開發(fā)的關(guān)鍵幾點(diǎn)包括 伸縮性和抽象程度的增加以及作出正確設(shè)計(jì)決策意義的增強(qiáng)。軟件架構(gòu)是通過一個(gè)全局的觀點(diǎn)，宏觀的視角來理解軟件系統(tǒng)作為一個(gè)整體如何工作。

　　即使這能夠幫助區(qū)分軟件開發(fā)和架構(gòu)，它并不能幫助理解某人如何從開發(fā)提升到架構(gòu)。 并且，它也不能幫助識(shí)別誰能夠成為一個(gè)好的軟件架構(gòu)師，如果你想雇人的話你如何去尋找他們以及你是否是一個(gè)軟件架構(gòu)師。

　　經(jīng)驗(yàn)可以判定但你需要更深入地了解

　　要成為一個(gè)軟件架構(gòu)師并不是一夜之間或者一個(gè)職位的提升就能簡(jiǎn)單達(dá)到的。 這是個(gè)職責(zé)，而不是頭銜。這是個(gè)進(jìn)化的過程，你將會(huì)逐步得到擔(dān)當(dāng)這個(gè)職責(zé)所需的經(jīng)驗(yàn)和信心。

　　當(dāng)你尋找架構(gòu)師時(shí)，需要考慮各方面的素質(zhì)，他們過去的經(jīng)驗(yàn)往往是他們有能力擔(dān)當(dāng)這個(gè)職責(zé)很好的判斷。由于軟件架構(gòu)師的職責(zé)是多種多樣的，所以你需要再深入了解他們?cè)诓煌I(lǐng)域的參與度，影響力，領(lǐng)導(dǎo)力和責(zé)任感。一般來說，在大多數(shù)項(xiàng)目中軟件架構(gòu)可分為兩個(gè)階段，架構(gòu)的定義，然后是它的交付。

　　軟件架構(gòu)的定義

　　架構(gòu)的定義過程看起來非常簡(jiǎn)單明了。 你需要做的是理解需求并設(shè)計(jì)一個(gè)系統(tǒng)來滿足需求。 但實(shí)際上并沒有那么簡(jiǎn)單，根據(jù)你不同的做法，軟件架構(gòu)的職責(zé)之間差距很大，以及如何認(rèn)真看待自己的職責(zé)而定。如下圖所示，這個(gè)職責(zé)的架構(gòu)定義部分，可以進(jìn)一步細(xì)分成不同的元素。

1. 管理非功能性需求：軟件項(xiàng)目經(jīng)常陷入問用戶要求是什么，什么是他們想要的功能，但很少問他們需要什么非功能性需求（或系統(tǒng)質(zhì)量）有時(shí)候，干系人會(huì)告訴我們，“這個(gè)系統(tǒng)必須很快”，但是這太主觀了。非功能性需求如果要滿足的話需要明確，可度量，可獲得以及可測(cè)試。大多數(shù)非功能性需求本質(zhì)上是技術(shù)層面的而且經(jīng)常對(duì)軟件架構(gòu)有很大的影響。理解非功能性要求是架構(gòu)師職責(zé)非常重要的一個(gè)部分，但假設(shè)這些需求是什么并不一定是對(duì)他們的挑戰(zhàn)。你見過多少系統(tǒng)真正需要24x7的運(yùn)行呢？
   
   

   NET技術(shù)：你是個(gè)軟件架構(gòu)師嗎？，轉(zhuǎn)載需保留來源！

   鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。