<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    posts - 176, comments - 240, trackbacks - 0, articles - 7

    架構師此在何為

    Posted on 2007-11-18 21:50 canonical 閱讀(454) 評論(1)  編輯  收藏 所屬分類: 雜感
       由于各個公司的領域,規模,人員配備等差異很大,形形色色的公司中頂著架構師頭銜的諸般人等所從事工作的內容以及所承擔的責任也是大相徑庭。務虛者有之,務實者也有之, 難以一概而論。甚至關于架構一詞的具體含義在不同語境下也是很難達成共識的。然而作為架構師,他應該做什么,能夠做什么,卻是我在自己的職業生涯中需要加以回答的問題。
        軟件公司中的工作大致分為銷售,技術,財務,打雜這幾類。架構師所從事的工作大致上屬于技術這一攤,應該是一種高度專業化的技術工作。在我看來,一般所謂架構師的工作主要是負責設計規范整個軟件項目/產品/產品線的整體結構,他所擺弄的是各種相關的技術元素。雖然作為公司的技術利益的代表者,架構師會在某種程度上參與到公司的商業活動中(在某些巨型公司中,架構師甚至可以通過標準規范對整個產業結構施加影響),但是他更多的是接收商業需求將其轉化為技術約束,而很少是商業目標的制定者。業務架構方面的設計更理想的是由業務專家進行,這個工作多半只需要技術的常識,而不需要對于技術本身的深刻洞察。在另一方面,雖然架構師對于技術實現所需的技術/人力等資源需求會提出自己的估算和建議,但是他一般并不具備相應的手段和責任來具體管理整個實現過程。因此在我看來架構師的管理職責并不是很大。當然,有些架構師會更加接近商業和管理而遠離技術,將他們稱之為"資深架構師"可能更加合適。在某些大型系統的建設過程中,總體設計人員可以只負責收集各個子系統的技術要求,匯總后制定整體技術規范,所起的作用類似于協調人員,在這種情況下倒是對技術要求較低而對管理素質要求較高了。
        關于架構的一個有趣的事實是,技術架構本身其實很少存在設計問題。大部分問題只在于業務問題如何分解到既定的技術架構上,一般的技術架構也只是現有技術元素的簡單組合而已。所謂的架構設計工作并不是在真正的系統全景下進行,它往往是基于已有經驗所作的短暫延伸,是對業內其他類似結構的復制變形。我們所面臨的大量問題是選型問題,不是創造性問題,而是選擇性問題。架構師最富技巧性的工作不是現在確定什么,做出選擇,而是確定現在可以不確定什么,可以將哪些選擇延遲。
        在一般人看來,架構師對于系統成敗必然起著關鍵性作用,否則他們憑什么屬于“活少錢多”的那伙人呢。但真實情況是,商業上的成敗很少是由技術架構直接決定的。因為技術開放和快速傳播等原因造成了技術的趨同性,在技術層面上,大多數公司很難依靠技術形成差異化優勢。競爭優勢主要來源于業務理解和與用戶的接觸性,來自于歷史形成的業務格局。而在中國這樣一個營銷制導的商業世界中,架構師的工作更難說是在構造某種與眾不同的東西。只有少數大公司依靠把握標準才形成技術的話語權,大部分人不過是在技術的大潮中隨波逐流罷了。“不求有功,但求無過”應該是架構師基本的工作精神。技術失敗最常見的原因除了不夠專業以外(在中國,“專業”的標準也許是不同的),就是過于自信,試圖去創造些新的結構,或者試圖全面應用某種不熟悉的技術。架構建設應該是一個逐步改進的過程,不要激進盲動。
        國內的架構師多數是從高級程序員發展而來,在工作期間多半是學習掌握外部知識,以掌握知識的細節程度和廣度為優先。因為總是在別人搭好的平臺上活動,即使是參與過眾多大型系統的建設,對于系統整體結構一般也沒有提煉出自己的認識觀點。而有些大學設置了專業,宣傳培養架構師,但是實際上缺乏系統的實踐訓練,學生所學到的多半是高舉高打的套路,在實戰中的表現往往更差。掌握技術細節和自主的整體性思考對于架構師而言都是不可或缺的。
        雖然創新的技術未必是商業中核心的元素,但是真正的創造性仍然是每一個設計師的希冀。作為一名實踐者,我們都在某種程度上期望超越所經歷的偶然,達到某種普遍的真理,在外部的物質世界中留下自己的精神烙印。在這種意義下,架構師的工作便不是簡單的技術背景或者技術理解可以涵蓋的了。我相信,在業務層和基礎技術設施之間存在著物理性的厚重的通用技術層,其中存在著大量的結構規律等待我們的探索,這也正是Witrix平臺一直努力的方向。


    Feedback

    # re: 架構師此在何為  回復  更多評論   

    2007-12-07 15:43 by 楊一
    您說的很有道理,但是業務需求千變萬化。2/8原則是否適用呢?小弟曾經實現過一個自動實現增刪改查的框架系統來管理基礎數據,然后集成了一個嵌入式的工作流引擎來管理接插業務。
    我想正如ORM彌合了JDBC的行集策略和對象之間的鴻溝一樣,在業務和技術之間,也學也存在著彌合的方法。其中的取舍,如果給技術的便宜多一些,則給業務的靈活性少一些。我們想把事情變得簡單,但到最后可能事情比最初還要復雜。
    主站蜘蛛池模板: 日韩成人在线免费视频| 免费在线观看视频网站| 美女视频黄频a免费观看| 又粗又长又爽又长黄免费视频| 女bbbbxxxx另类亚洲| 久草免费福利视频| 成年免费大片黄在线观看岛国| 免费日本黄色网址| 精品无码一区二区三区亚洲桃色| 亚洲人妖女同在线播放| 美女18一级毛片免费看| AV无码免费永久在线观看| 亚洲欧洲∨国产一区二区三区| 亚洲一卡2卡4卡5卡6卡在线99| 一区二区三区AV高清免费波多| 亚洲性久久久影院| 亚洲一区中文字幕| 日韩中文字幕免费| 全黄A免费一级毛片| 国产成人A在线观看视频免费| 亚洲成av人片天堂网| 苍井空亚洲精品AA片在线播放| 亚洲不卡AV影片在线播放| 久久精品国产亚洲AV电影| 成人影片麻豆国产影片免费观看 | 国产亚洲一区二区三区在线观看| 亚洲精华国产精华精华液 | 特级毛片免费观看视频| 中文字幕亚洲综合久久男男| 国产亚洲精品91| 亚洲精品成人无限看| 国产乱码免费卡1卡二卡3卡| 日韩亚洲人成在线综合| 亚洲精品高清无码视频| 真人做人试看60分钟免费视频 | 中文字幕免费观看全部电影| 香蕉视频在线观看免费国产婷婷| 亚洲成a人片77777群色| 青青草无码免费一二三区| 久久久久久久尹人综合网亚洲| 国产精品视频免费观看|