轉(zhuǎn)架構(gòu)設(shè)計(jì)準(zhǔn)則word版-文庫吧資料
2025-05-15 17:44本頁面
【正文】 務(wù)想辦法提升開發(fā)團(tuán)隊(duì)的戰(zhàn)斗力，常有以下方式： 尋找或開發(fā)工作需要的工具，并附上使用技巧 做定期的分享或提高團(tuán)隊(duì)學(xué)習(xí)氣氛，保持團(tuán)隊(duì)技術(shù)上的先進(jìn)性 參與開發(fā)團(tuán)隊(duì)的招聘工作 給予開發(fā)人員更多的決策空間，幫助其成長 保護(hù)好開發(fā)人員，讓他們盡可能地免于雜事之中 直接參與開發(fā)，分擔(dān)壓力 記錄決策的理由 架構(gòu)師常常需要權(quán)衡和決策，但決策過后卻沒有把決策的過程和理由記錄下來，其實(shí)這是在浪費(fèi)很大的一筆財(cái)富。 對復(fù)雜性要有前瞻意識 在實(shí)際的運(yùn)行環(huán)境中，往往簡單的系統(tǒng)都有可能變得非常復(fù)雜，簡單的遠(yuǎn)程接口可能調(diào)不通、穩(wěn)固的數(shù)據(jù)庫可能 down 掉、消息順序可能會錯(cuò)亂、服務(wù)器可能會無緣無故地 down 機(jī)，不要假設(shè)這些情況不會發(fā)生，架構(gòu)師應(yīng)該對復(fù)雜的情況有前瞻意識，要在假設(shè)類似于前面的狀態(tài)存在的情況下設(shè)計(jì)軟件。 關(guān)注性能 高性能往往和代碼優(yōu)美性常常沒法兼容，有些架構(gòu)師往往不在乎性能上的點(diǎn)滴損耗，為了代碼更重用或更優(yōu)美，不 惜多查一次數(shù)據(jù)庫，多與外系統(tǒng)交互一次，這種做法會讓后期的性能提升很被動(dòng)，性能壓力會逼迫你打破原有的設(shè)計(jì)，為提升性能把代碼搞得支離破碎。 控制項(xiàng)目規(guī)模 架構(gòu)師要 試圖避免做那種 超大型 系統(tǒng)，因?yàn)檫@種系統(tǒng)往往難以控制，控制項(xiàng)目規(guī)模的辦法通常有： 抓住真正需求 分而治之 設(shè)置優(yōu)先級 盡快交付原則 架構(gòu)師不是演員，而是管家 有些架構(gòu)師誤解了證明自己價(jià)值的含義，以為是炫耀技術(shù)才華，甚至是刁難開發(fā)團(tuán)隊(duì)，把自己放在高高在上的位子，試圖讓別人來崇拜你。 本文來自 CSDN 博客，轉(zhuǎn)載請標(biāo)明出處： 讓開發(fā)人員自己做主 架構(gòu)師雖然需要為系統(tǒng)的設(shè)計(jì)負(fù)責(zé)，但無須包攬所有的設(shè)計(jì)工作，應(yīng)該給予團(tuán)隊(duì)成員足夠的自主權(quán)，讓他們發(fā)揮自己的創(chuàng)意和能力，你的工作是確保大家的工作能很好的組合在一起，幫助他人解決棘手困難。其實(shí) coding 相對于傳統(tǒng)行業(yè)應(yīng)該屬于設(shè)計(jì)范疇，真正生產(chǎn)過程實(shí)際上是由工具來完成的編譯、構(gòu)建和發(fā)布過程。掌握業(yè)務(wù)領(lǐng)域知識將有利于架構(gòu)師選擇合適的架構(gòu)模式，更好地制定針對未來的擴(kuò)展計(jì)劃。關(guān)鍵一點(diǎn)，架構(gòu)師不是為了設(shè)計(jì)而設(shè)計(jì)，是要想清楚別人為什么要看你的文檔，怎樣滿足別人的需求 先嘗試后決策 設(shè)計(jì)中有很多需要決策的點(diǎn)，很多架構(gòu)師喜歡在象牙塔里憑借經(jīng)驗(yàn)做決策，感覺這就是架構(gòu)師需要干的。 PM 需要知道這個(gè)項(xiàng)目有哪些風(fēng)險(xiǎn)點(diǎn)，因此你的文檔要 體現(xiàn)風(fēng)險(xiǎn)點(diǎn)識別和如何規(guī)避。測試人員想知道系統(tǒng)內(nèi)部如何流轉(zhuǎn)和如何對系統(tǒng)進(jìn)行測試，因此你的文檔要體現(xiàn)系統(tǒng)主要模塊的運(yùn)行流程和系統(tǒng)可測試性。 讓大家學(xué)會復(fù)用 架構(gòu)師有義務(wù)提高開發(fā)人員可復(fù)用地解決問題的 意識，比如以上幾種措施： 讓大家把自己能復(fù)用的代碼及時(shí)共享給他人 加強(qiáng)復(fù)用代碼的易用性，避免誤用 讓大家認(rèn)識到已有資源好過自己動(dòng)手 架構(gòu)文檔的抽象程度要適中 架構(gòu)師寫架構(gòu)文檔常常很糾結(jié)，寫得太高層次的話就太空洞，無切實(shí)的指導(dǎo)意義；寫得太具體的話，比如指明到類的各種 UML 圖，就會很約束開發(fā)人員。 重視不確定性 優(yōu)良的架構(gòu)能夠從整體上降低設(shè)計(jì)決 策的重要性，糟糕的架構(gòu)則會使得常常突出選擇的重要性。 取舍的藝術(shù) 我們做系統(tǒng)，特別是互聯(lián)網(wǎng)系統(tǒng)，絕不是做一個(gè)變形金剛，而是做一個(gè)有缺陷但卻滿足了現(xiàn)階段商業(yè)需求的系統(tǒng)，因此架構(gòu)師需要有取舍的藝術(shù)，你的架構(gòu)是能用有限的資源滿足最迫 切的需求，舍掉那些看是光鮮卻無太多用處的東西 打造數(shù)據(jù)庫堡壘 在上層的程序設(shè)計(jì)中，架構(gòu)師一般都會推崇先簡單實(shí)現(xiàn)，然后在逐步重構(gòu)的敏捷方式，但對于較為穩(wěn)定的后端數(shù)據(jù)庫，
研究報(bào)告相關(guān)推薦
鄂ICP備17016276號-1