熱門:瘦小腿瘦小腿瘦小腿

  1. 首頁
  2. 科技日報
  3. 網路

如何成為一名優秀的架構師?

  • 小白兔

  • 2018-10-21 17:25:58

【CSDN編者按】眾所周知,架構師的角色,更偏向於策劃、而非指揮,塑造、而非支配,其存在的意義,在於引導大家討論、而非自己主宰一切。

但是,具體應該如何執行呢?本文作者整理了 30 個公認的架構原則,來幫助大家解決此問題。也許有的原則,你從未聽說,但你看完就能快速學會。

相信你學會了,工作起來也會事半功倍,或許還可幫你避免,很多無用的加班!

想一下軟體架構的評審過程:一位架構師參與進來,俯視一切然後指指點點,高談闊論。他發表的評論要麼過於粗淺,要麼嚴重脫離實際。

大家對其意見要麼極度沉默,要麼強烈反對。這對團隊幾乎沒有任何幫助。程式設計師和架構師都對這樣的架構評審望而生畏。

軟體架構師的角色應當像園丁而非指揮官。前者的職責主要是塑造、策劃並清除雜草,而後者主要任務是發號施令。

在 WSO2,我參與架構評審的時間已長達八年之久。WSO2 的產品非常豐富,比如 WSO2 ESB 、WSO2 API Manager 以及 WSO2 SP 都人盡皆知。在過去八年中,我們對許多產品和功能進行了討論、設計、改進和重新設計。

我們在設計軟體的過程中,把握的一個關鍵點是:軟體架構並非由架構師負責設計。我們的架構不是由架構師制定,然後交給其他人來實施。

相反,架構的設計任務由真正編寫程式碼的團隊負責。架構師負責對工程師設計的架構進行修復、完策劃和改進。我們的架構團隊是指導員和把關人,而非獨裁者。

在短期內,由一位架構師來制定架構的確既快捷又實惠。但是,從長遠來看,我們會組建一個團隊,讓他們自己不斷思考、改善架構,並從他們的錯誤中來提升自己。

當我們專注於團隊時,他們自然會隨著時間的推移而變得更好。架構團隊的首要任務是:儘可能保證架構容易執行。

此外,架構評審也存在缺陷。就像 Paul (@pzfreo)描述的架構評審那樣:架構師參與進來,聽一會,發表一點評論然後就走了。

作為一名架構師,你對架構發表自己的看法和意見無可厚非。但是,如果你不夠投入和細心,你的意見可能會讓團隊感到困惑,團隊就無法確定正確的做法到底是什麼。

接下來我會將30個架構原則一一列出,其中一些原則是眾所周知的,而有些則源於我的個人經驗和心血。

基本原則

原則1:KISS(保持簡單)原則 ,儘可能讓一切變得簡單。該原則鼓勵我們用最簡單的解決方案來完成工作。

原則2:YAGNI(你不需要它)原則 ,只在需要時構建。

原則3:先學會爬,然後再學會走,最後學會跑。換句話說,先保證能夠正常執行,然後優化它使其更好,最後逐漸讓它變得完美。使用迭代開發,採用敏捷開發模式。為每個功能制定一個開發週期(最多2周),然後不斷迭代。

原則4:自動化測試是構建穩定、高質量產品的唯一方法。通過自動化測試提升創造力,所有一切都可以自動化!在設計時應當好好考慮自動化。

原則5:注重投資回報率(ROI)並將最多的注意力放在最重要的地方。

原則6:瞭解使用者並相應地平衡資源。大多數產品都有數千個終端使用者,大致需要20個開發人員和100個 DevOp 人員。不要花費數月的時間來構建一個不太可能使用 DevOp 的使用者介面(他們更喜歡指令碼!)。這是原則5的特例。

原則7:功能的設計和測試儘可能獨立。如果在設計時考慮到這一點,長遠來看,它將省去很多麻煩,否則只有一切構建完成時你才可以開始測試整個系統。此外,遵循這個原則,版本釋出也會更加順利。

原則8:警惕搜尋引擎中花裡胡哨的架構方案。我們天生都喜歡令人奪目的設計。如果你按奈不住, 就可能把太多根本不需要的功能和解決方案引入到你的架構中。

選擇功能

原則9:想要準確知道使用者如何使用我們的產品是很難的。所以我們要推行MVP(最小可行產品)。該理念的核心在於:先制定一些用例,完成用例所涉及的相關功能,立即釋出產品,然後根據反饋和經驗對產品進行優化。

原則10:儘可能減少功能,如有疑問則將其刪除。許多功能可能從未使用,你只需為其留一個擴充套件介面即可。

原則11:聽取客戶的意見,看他們想要什麼功能。

原則12:當客戶要求的功能影響到其他模組時,要勇於和客戶辯論。從大局出發,嘗試找到另一種方法來處理問題。就像 Fords 所說的那樣“每當我問顧客需要什麼的時候,他們總是會說需要跑得更快的馬”。請記住,你才是專家。你應該主導一切,做出正確和專業的決定。雖然使用者可能當時有些疑惑,但最終他們會感謝你的。

伺服器設計與併發

原則13:從硬體、作業系統到你使用的程式語言等多方面深入瞭解伺服器的工作原理。優化 IO 操作的效率是一個良好架構的首要任務。

原則14:遵循 Amdhal 的同步定律。執行緒之間共享的可變資料會降低程式速度。如果可以,請使用併發資料結構,並且僅在必要時使用同步。儘可能少地使用鎖。如果你打算線上程鎖期間阻塞,請確保自己足夠瞭解具體細節,因為這裡存在極大的隱患。

原則15:如果你的設計是基於事件驅動的非阻塞架構,那就不要阻塞執行緒或者線上程中執行 IO 操作。一旦這樣做,系統將慢如蝸牛。

分散式系統

原則16:無狀態系統具有良好的擴充套件性。我們要儘可能瞭解和使用無分享架構。

原則17:除非你能夠掌控客戶端和伺服器的所有程式碼,否則訊息傳遞失敗的情況在所難免。儘量減少你的系統依賴的因素(例如使用原則18)。

原則18:儘可能實施冪等操作。這樣它就很容易恢復,你至少可以保證交付沒問題。

原則19:瞭解 CAP 定理。擴充套件事務很難。儘可能使用補償,基於 RDBMS 的事務很難擴充套件。

原則20:分散式系統共識不支援擴充套件,也無法進行組通訊,不支援群集範圍內的可靠訊息傳遞。其最大節點限制大約是八個節點。

原則21:你很難隱藏分散式系統中的延遲和故障。(參見分散式計算的謬誤解釋 )。

使用者體驗

原則22:瞭解你的使用者以及他們的目標:他是新手、專家還是臨時使用者?他對電腦科學瞭解多少?極客看重擴充套件功能,開發人員關注示例和指令碼,普通人則更在乎介面。

原則23:最好的產品應當不需要使用者手冊,使用者應該一看就會用。

原則24:當你無法在兩個選項之間做出決定時,請不要通過配置選項的方式來呈現問題。這會給使用者和架構師帶來麻煩。對於系統如何運作的細節,他們沒有你瞭解,他們怎麼能做出決定呢?最好的方案是找到一個每次都有效的選擇;其次是自動做出選擇;第三個方案是新增配置引數並設定合理的預設值。

原則25:始終具有合理的配置預設值。

原則26:設計不良的配置會製造麻煩。始終配置幾個示例值。

原則27:詢問使用者配置值的時候,注意選擇使用者無需即可設定的值(例如,不要問使用者需要的最大快取條目數量,而是要問他想要用於快取的記憶體數量)

原則28:如果發現未知配置,則丟擲錯誤。永遠不要忽視它。在除錯過程中,無提示的配置錯誤會浪費我們很多調式時間。

難點

原則29:嘗試新語言很容易,但要正確使用卻很難。除非公司願意組建一個十人團隊並花一年的時間來學習,否則儘量不要這樣做。如果你仍不死心,請閱讀有關語言設計的五個問題 後再做定奪。

原則30:可組合的拖放 UI 很難實現,除非團隊準備投入10人年的資源,否則不要去做。

最後,讓我談一些隨著時間的推移我的主意發生變化的事情。在理想情況下,一個平臺應當由多個元件組成,每個元件負責一個方面(例如,安全性、訊息傳遞、註冊、調解、分析,等等)。使用這些功能構建的系統將是最佳的。

不幸的是,嚴格執行這一點可能是一個錯誤,特別是在新功能的初始狀態,其中簡單的功能可能導致大的變化,因為我們試圖使一切都是垂直的。有時我們發現我們新增的功能沒用,然後所有額外的工作都沒有用。最後,如果這需要多個團隊之間的協商,該功能可能永遠都無法完成。

現在來看,我願意接受重複。治療帶來的結果可能會比疾病導致後果更嚴重。

結論

作為架構師,我們應該像園丁一樣思考、塑造、策劃和去除雜草而不是定義和構建。

在短期內,由一位架構師來制定架構的確既快捷又實惠。但是,從長遠來看,團隊的力量才是最強的。

如果你不夠投入和細心,你只指出錯誤,但是不道明錯誤原因,那麼你的意見可能會讓團隊感到困惑。避免這種情況的一種方法是擁有一套普遍接受的原則,這些原則是討論架構時遵循的基本點,也是初學者學習架構的好資源。

原文:https://hackernoon.com/first-do-no-harm-30-principles-that-helped-me-avoid-fly-by-architecture-reviews-e8952ac632a

作者:Srinath Perera ,是一位電腦科學家、軟體架構師、作家,他是 apache 的核心成員,擁有 15 年分散式系統程式設計經驗,設計了 Apache Axis2 以及 WSO2 流處理器。

譯者:安翔,責編:胡巍巍

推薦您的文章

其他文章