轉架構設計準則word版(編輯修改稿)
2025-06-12 17:44 本頁面
【文章內(nèi)容簡介】 些問題絕不能指望開發(fā)主力們?nèi)グl(fā)現(xiàn)和解決，因為他們的注意力都會 focus 在主要矛盾上，作為時刻監(jiān)控項目的架構師應該擔當起發(fā)現(xiàn)這些 小 bug的義務。 讓大家學會復用 架構師有義務提高開發(fā)人員可復用地解決問題的 意識，比如以上幾種措施： 讓大家把自己能復用的代碼及時共享給他人 加強復用代碼的易用性，避免誤用 讓大家認識到已有資源好過自己動手 架構文檔的抽象程度要適中 架構師寫架構文檔常常很糾結，寫得太高層次的話就太空洞，無切實的指導意義；寫得太具體的話，比如指明到類的各種 UML 圖，就會很約束開發(fā)人員。文檔要寫到什么程度，關鍵在于滿足他人的需求，比如業(yè)務部門想從文檔中得知系統(tǒng)各功能的實施可行性，因此你的文檔要能體現(xiàn)各主要功能是如何滿足的。測試人員想知道系統(tǒng)內(nèi)部如何流轉和如何對系統(tǒng)進行測試，因此你的文檔要體現(xiàn)系統(tǒng)主要模塊的運行流程和系統(tǒng)可測試性。開發(fā)人員需要知道系統(tǒng)各自模塊的劃分和之間的交互規(guī)范，因此你的文檔要體現(xiàn)模塊化設計。 PM 需要知道這個項目有哪些風險點，因此你的文檔要 體現(xiàn)風險點識別和如何規(guī)避。 DBA 和運維人員需要知道系統(tǒng)的數(shù)據(jù)量和性能情況，因此需要指明系統(tǒng)如何應對大數(shù)據(jù)量的情況。關鍵一點，架構師不是為了設計而設計，是要想清楚別人為什么要看你的文檔，怎樣滿足別人的需求 先嘗試后決策 設計中有很多需要決策的點，很多架構師喜歡在象牙塔里憑借經(jīng)驗做決策，感覺這就是架構師需要干的。其實，這樣的做法往往會讓你很被動，不如延遲決策，把需要決策的點拋出來，讓大家去嘗試，在實踐比較中，其實無須決策，正確的選擇自然就出來了，這樣也更能拉近你和大家的距離，提高大家的積極性和你的權威性 掌握業(yè) 務領域知識 架構師的角色任務在于理解業(yè)務問題、業(yè)務目標、業(yè)務需求、并設計技術架構來滿足它們。掌握業(yè)務領域知識將有利于架構師選擇合適的架構模式，更好地制定針對未來的擴展計劃。 coding 是屬于設計范疇 很多人常常把軟件開發(fā)類比于傳統(tǒng)行業(yè)，把 coding 比作是生產(chǎn)過程，因此很多一線開發(fā)人員稱作自己為代碼工人，很多架構師也是這么認為，只是把開發(fā)人員當作實現(xiàn)自己設計的生產(chǎn)工具而已。其實 coding 相對于傳統(tǒng)行業(yè)應該屬于設計范疇，真正生產(chǎn)過程實際上是由工具來完成的編譯、構建和發(fā)布過程。架構師更應該把 coding 當作 設計來看，從紙上的設計到 coding 后的代碼還有很多設計點可挖，同樣的輸出的背后也許來源于完全不同的 coding，其軟件成品的價值也是完全不同的。 本文來自 CSDN 博客，轉載請標明出處： 讓開發(fā)人員自己做主 架構師雖然需要為系統(tǒng)的設計負責，但無須包攬所有的設計工作，應該給予團隊成員足夠的自主權，讓他們發(fā)揮自己的創(chuàng)意和能力，你的工作是確保大家的工作能很好的組合在一起，幫助他人解決棘手困難。當你發(fā)現(xiàn)同事遇到麻煩時，可以主動給出建議，但更可取的做法是創(chuàng)造良好的氛圍，讓大家主動向你征求意見。 控制項目規(guī)模 架構師要 試圖避免做那種 超大型 系統(tǒng)，因為這種系統(tǒng)往往難以控制，控制項目規(guī)模的辦法通常有： 抓住真正需求 分而治之 設置優(yōu)先級 盡快交付原則 架構師不是演員，而是管家 有些架構師誤解了證明自己價值的含義，以為是炫耀技術才華，甚至是刁難開發(fā)團隊，把自己放在高高在上的位子，試圖讓別人來崇拜你。其實架構師的職責和管家類似，承擔著管理技術資產(chǎn)的責任，要深入了解系統(tǒng)里各個細節(jié)，要精打細算，而不是浮在表面做無實文章。 關注性能 高性能往往和代碼優(yōu)美性常常沒法兼容，有些架構
研究報告相關推薦
鄂ICP備17016276號-1