|
|
開發和架構的界限難以捉摸。有些人告訴你它根本不存在，架構只是開發者們所做的設計過程的簡單擴展。 另外一些人認為這是一個鴻溝，它只能由那些做到高度抽象，而且不會陷入實現細節的開發者才能跨越。通常，在這兩個極端的觀點中間某處有個可操作的平衡點；不論如何，怎么從開發轉換為架構師都是個有趣的問題。
經常被用來區分軟件架構和軟件設計開發的關鍵幾點包括 伸縮性和抽象程度的增加以及作出正確設計決策意義的增強。軟件架構是通過一個全局的觀點，宏觀的視角來理解軟件系統作為一個整體如何工作。
即使這能夠幫助區分軟件開發和架構，它并不能幫助理解某人如何從開發提升到架構。 并且，它也不能幫助識別誰能夠成為一個好的軟件架構師，如果你想雇人的話你如何去尋找他們以及你是否是一個軟件架構師。
經驗可以判定但你需要更深入地了解
要成為一個軟件架構師并不是一夜之間或者一個職位的提升就能簡單達到的。 這是個職責，而不是頭銜。這是個進化的過程，你將會逐步得到擔當這個職責所需的經驗和信心。
當你尋找架構師時，需要考慮各方面的素質，他們過去的經驗往往是他們有能力擔當這個職責很好的判斷。由于軟件架構師的職責是多種多樣的，所以你需要再深入了解他們在不同領域的參與度，影響力，領導力和責任感。一般來說，在大多數項目中軟件架構可分為兩個階段，架構的定義，然后是它的交付。
軟件架構的定義
架構的定義過程看起來非常簡單明了。 你需要做的是理解需求并設計一個系統來滿足需求。 但實際上并沒有那么簡單，根據你不同的做法，軟件架構的職責之間差距很大，以及如何認真看待自己的職責而定。如下圖所示，這個職責的架構定義部分，可以進一步細分成不同的元素。
- 管理非功能性需求：軟件項目經常陷入問用戶要求是什么，什么是他們想要的功能，但很少問他們需要什么非功能性需求（或系統質量）有時候，干系人會告訴我們，“這個系統必須很快”，但是這太主觀了。非功能性需求如果要滿足的話需要明確，可度量，可獲得以及可測試。大多數非功能性需求本質上是技術層面的而且經常對軟件架構有很大的影響。理解非功能性要求是架構師職責非常重要的一個部分，但假設這些需求是什么并不一定是對他們的挑戰。你見過多少系統真正需要24x7的運行呢？
NET技術：你是個軟件架構師嗎？，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
