轉(zhuǎn)架構(gòu)設計準則word版(已修改)
2025-05-23 17:44 本頁面
【正文】 【轉(zhuǎn)】架構(gòu)設計準則 最近看了一本書《軟件架構(gòu)師應該知道的 97 件事》，本來并沒對它抱有太多期望和興趣，畢竟這種講大道理的書不可能帶來什么實際收獲，但看的過程中被里面中肯實在的建議給吸引，對于我這種在走向架構(gòu)師這條路上常常迷失方向的人，實在是雪中送炭。讀完后，決定選擇其中對我有觸動的條目，加上實際工作中的感悟，形成一套自認為正確的架構(gòu)師行為準則，以此來矯正自己的行為。 客戶需求高于一切 不要為了自己的項目經(jīng)歷上添加光彩而去一味追求時髦而光鮮的方案，而是應該扎根客戶需求，腳踏實地地為客戶著想，這樣才能更體現(xiàn)技術(shù)的價值，不至于迷失方向。架構(gòu)師首先不要把自己當做技術(shù)人員，而是業(yè)務人員，把實現(xiàn)業(yè)務需求作為至上的目標，學會拒絕成本高，性價比不高的技術(shù)。 簡化根本復雜性 常常為了解決某一局部復雜性引入了更為復雜的框架或產(chǎn)品，使得復雜性不減反增。往往正確的方式是做減法而不是加法，把最根本的復雜源找到，把根鏟除。 關(guān)鍵問題可能不是出在技術(shù)上 總結(jié)失敗的項目常常會糾結(jié)于選擇了錯誤的技術(shù)。其實技術(shù)并沒有錯，而是在使用技術(shù)上或是在執(zhí)行過程中人為的偏差導致。而架構(gòu)師解決這種人為的問題比較好的方式是溝通，通過有效地溝通把技術(shù)貫徹下去 以溝通為中心，堅持簡明清晰和開明的風格 架構(gòu)師不要坐在象牙塔里，命令開發(fā)人員實施你的設計和決策，而是應該盡量簡化你的設計，透徹地與他們溝通，并且關(guān)鍵在于開明地接受他們的建議并勇于推翻自己的決策 架構(gòu)決定性能 最好提升性能的方法不是痛苦地做一次次對即將上線的產(chǎn)品做性能測試和提升，而是在架構(gòu)設計的時候就把性能作為重要因素，從架構(gòu)底層考慮分布式、緩存、系統(tǒng)交互劃分等影響性能的重點。提前關(guān)注性能 ，是解決性能問題代價最小的方式 分析客戶要求背后的真實需求 合同上或 UC 上只是客戶的要求，而并非 100%是客戶真實的需求，架構(gòu)師的重要責任就是挖掘隱藏在要求背后的真實需求，這個不但可以最大化滿足客戶，也往往可以幫助我們避開技術(shù)壁壘，當真正抓住客戶需求的時候，我們也許能用更為簡單的替代方案滿足客戶 溝通是架構(gòu)師達成目標的核心技能 常用的溝通技能和準則有以下幾點： 不要把溝通當做對抗 不要帶有情緒與人溝通 表達自己方案之前傾聽他人觀點 站立發(fā)言是擴大溝通影響力的一種好方式 學習業(yè)務或技術(shù)領域中的行話，降低溝通成 本 不要為預防故障引入更多的故障 架構(gòu)師常常會為識別出的可能故障點加入監(jiān)控措施，但往往會忽略做些監(jiān)控措施也是會有故障的，不要試圖讓你的系統(tǒng)天衣無縫，這往往是使系統(tǒng)更為復雜和脆弱的來源。先承認是系統(tǒng)總會有缺陷的，只是把這些缺陷設定為容易察覺和維護的點 量化非功能性需求 往往功能性需求容易量化，因為這些是看得見和摸得著的，但像性能好、可擴展性好、高可用性等這些非功能性需求卻不好量化，但作為架構(gòu)師要有意識地去定義和量化這些需求，只有這樣才能更好地和其他部門更好溝通，謀求更多資源，也便于系統(tǒng)更有效地驗收 一行代碼比 500 行架構(gòu)說明更有說服力 架構(gòu)師往往喜歡待在象牙塔里，堆砌大量架構(gòu)文檔，然后希望其他開發(fā)人員能乖乖地去實施。這樣做的效果往往是不好的，一方面很難有這樣的牛人能洞察所有的細節(jié)，在文檔里就預測性地解決了所有問題，另一方面也不利于架構(gòu)師與開發(fā)人員的溝通。比較好的做法是架構(gòu)師參與具體實施，在實施中驗證和改進架構(gòu)設計，與大家達成一片也便于加深彼此配合的默契程度。 不存在放之四海皆準的解決方案 不存在最好的架構(gòu)，只有最合適的架構(gòu)。不會有一種架構(gòu)方案，在任何項
研究報告相關(guān)推薦
鄂ICP備17016276號-1