架構師的行為準則(二)

2021-08-25 07:38:20 字數 2517 閱讀 3680

先確保解決方案簡單可用,再考慮通用性和復用性

系統的複雜性往往是架構師基於通用性和復用性的設計而引入的,很多具體問題往往不需要通用性和復用性的解決方案。如果存在多個可實施方案難以取捨,先簡單後通用原則可以成為最終的評判標準。架構師提供具體解決方案時,無需排斥通用和靈活,但是如果過早脫離具體情況,只會迷失在無限的可能性裡,被複雜的配置選項、超負荷的引數列表、冗長羅嗦的介面,以及存在缺陷的抽象所淹沒。先簡單滿足需求,當重複需求再次發生時,通過重構來達到復用是一種不錯的方式

架構師應該親力親為

架構師乾久了往往會脫離技術本身,迷茫在抽象之中,這是很危險可怕的。架構師要取得其他同事的信任,應該比業務人員更懂業務,比開發人員更懂具體的編碼,比測試人員更懂如何有效地測試,就像航班的主駕駛員,雖然不需要親自操作,但經驗豐富,持續地監視著情況,一旦發現異常隨時採取行動。架構師應該專案的交付和質量負有最終的責任。架構師應該盡可能地參與專案,不能把技術決策和方向上的難題拆分出扔給別人,需要採取更務實的辦法,比如親自動手研究或和其他成員討論。

持續整合是架構師的重要任務

普通的開發人員會focus在各自負責的小模組,只會對單個模組負責,而架構師需要對整個系統負責,持續整合是一種對整個系統進行有效控制的好方法,架構師有責任讓它執行起來。

避免進度調整失誤

雖然保障進度是pm的職責,但變更要發生的時候,作為對技術最有發言權的架構師應該站出來,把變更的必要性和風險進行仔細分析,最大限度地支援pm的決策。

取捨的藝術

我們做系統,特別是網際網路系統,絕不是做乙個變形金剛,而是做乙個有缺陷但卻滿足了現階段商業需求的系統,因此架構師需要有取捨的藝術,你的架構是能用有限的資源滿足最迫切的需求,捨掉那些看是光鮮卻無太多用處的東西

打造資料庫堡壘

在上層的程式設計中,架構師一般都會推崇先簡單實現,然後在逐步重構的敏捷方式,但對於較為穩定的後端資料庫,我們需要採取更為謹慎的態度,因為資料庫是整個系統的基石,無論是業務設計還是技術設計都得保持它的穩定性,這是整個系統穩定的基礎。我們往往會發現這麼乙個現象,當程式第一版上線後,資料庫裡表只會增加不會刪除,也不會刪除多餘的字段,每次資料庫變更都會引起所有人的緊張,也會使得本已混亂的資料庫設計更為混亂。

重視不確定性

優良的架構能夠從整體上降低設計決策的重要性,糟糕的架構則會使得常常突出選擇的重要性。如果出現兩個合理地選擇,架構師應該停下來,設法找出介於兩者之間的、具有更低重要性的決策,了解兩者之外還存在其他選擇,比決策結果本身更有價值

不要輕易放過不起眼的問題

專案的失敗或線上故障往往是由於專案過程中的不起眼問題所引起,比如一些特殊的邊界情況,而這些問題絕不能指望開發主力們去發現和解決,因為他們的注意力都會focus在主要矛盾上,作為時刻監控專案的架構師應該擔當起發現這些「小bug」的義務。

讓大家學會復用

架構師有義務提高開發人員可復用地解決問題的意識,比如以上幾種措施:

架構文件的抽象程度要適中

架構師寫架構文件常常很糾結,寫得太高層次的話就太空洞,無切實的指導意義;寫得太具體的話,比如指明到類的各種uml圖,就會很約束開發人員。文件要寫到什麼程度,關鍵在於滿足他人的需求,比如業務部門想從文件中得知系統各功能的實施可行性,因此你的文件要能體現各主要功能是如何滿足的。測試人員想知道系統內部如何流轉和如何對系統進行測試,因此你的文件要體現系統主要模組的執行流程和系統可測試性。開發人員需要知道系統各自模組的劃分和之間的互動規範,因此你的文件要體現模組化設計。pm需要知道這個專案有哪些風險點,因此你的文件要體現風險點識別和如何規避。dba和運維人員需要知道系統的資料量和效能情況,因此需要指明系統如何應對大資料量的情況。關鍵一點,架構師不是為了設計而設計,是要想清楚別人為什麼要看你的文件,怎樣滿足別人的需求

先嘗試後決策

設計中有很多需要決策的點,很多架構師喜歡在象牙塔裡憑藉經驗做決策,感覺這就是架構師需要幹的。其實,這樣的做法往往會讓你很被動,不如延遲決策,把需要決策的點丟擲來,讓大家去嘗試,在實踐比較中,其實無須決策,正確的選擇自然就出來了,這樣也更能拉近你和大家的距離,提高大家的積極性和你的權威性

掌握業務領域知識

架構師的角色任務在於理解業務問題、業務目標、業務需求、並設計技術架構來滿足它們。掌握業務領域知識將有利於架構師選擇合適的架構模式,更好地制定針對未來的擴充套件計畫。

coding是屬於設計範疇

很多人常常把軟體開發模擬於傳統行業,把coding比作是生產過程,因此很多一線開發人員稱作自己為**工人,很多架構師也是這麼認為,只是把開發人員當作實現自己設計的生產工具而已。其實coding相對於傳統行業應該屬於設計範疇,真正生產過程實際上是由工具來完成的編譯、構建和發布過程。架構師更應該把coding當作設計來看,從紙上的設計到coding後的**還有很多設計點可挖,同樣的輸出的背後也許**於完全不同的coding,其軟體成品的價值也是完全不同的。

架構師行為準則

架構師的行為準則 一 最近看了一本書 軟體架構師應該知道的97件事 本來並沒對它抱有太多期望和興趣,畢竟這種講大道理的書不可能帶來什麼實際收穫,但看的過程中被裡面中肯實在的建議給吸引,對於我這種在走向架構師這條路上常常迷失方向的人,實在是雪中送炭。讀完後,決定選擇其中對我有觸動的條目,加上實際工作中...

架構師的行為準則(二)

走向架構師之路 先確保解決方案簡單可用,再考慮通用性和復用性 系統的複雜性往往是架構師基於通用性和復用性的設計而引入的,很多具體問題往往不需要通用性和復用性的解決方案。如果存在多個可實施方案難以取捨,先簡單後通用原則可以成為最終的評判標準。架構師提供具體解決方案時,無需排斥通用和靈活,但是如果過早脫...

架構師的行為準則(三)

讓開發人員自己做主 架構師雖然需要為系統的設計負責,但無須包攬所有的設計工作,應該給予團隊成員足夠的自主權,讓他們發揮自己的創意和能力,你的工作是確保大家的工作能很好的組合在一起,幫助他人解決棘手困難。當你發現同事遇到麻煩時,可以主動給出建議,但更可取的做法是創造良好的氛圍,讓大家主動向你徵求意見。...