噜噜噜综合,又色又爽又高潮免费观看,综合无码一区二区三区四区五区,中文字幕无码人妻aaa片,四虎成人精品永久网站

41. Engineer in the whitespaces by Michael Nygard

【設(shè)計(jì)空白處】

架構(gòu)圖通常由一些方塊表示互相依賴的系統(tǒng)，它們之間用箭頭連接，箭頭邊上寫著小小的幾個(gè)字，剩下的就是大片的空白。這空白處看似什么都沒(méi)有，可是在現(xiàn)實(shí)中，有網(wǎng)卡、入侵檢測(cè)系統(tǒng)、防火墻、消息隊(duì)列服務(wù)、數(shù)據(jù)格式轉(zhuǎn)換服務(wù)、通信設(shè)備，甚至可能穿越萬(wàn)水千山。因此，在這個(gè)箭頭旁，還是要把一些重要問(wèn)題考慮清楚：

(1). 調(diào)用方操作太過(guò)頻繁怎么辦?忽略、禮貌地拒絕或者竭力滿足?

(2). 如果響應(yīng)超時(shí)則調(diào)用方怎么辦?重試、等待或視為接收方故障?

(3). 雙方收到的數(shù)據(jù)版本或者格式與期待的不一致時(shí)怎么辦?

(4). 兩方中的任何一方短暫消失會(huì)有什么影響?

舉個(gè)例子，假設(shè)有個(gè)箭頭寫的是“HTTP搭載的SOAP-XML”，它可能會(huì)有這樣的注釋：“期待每個(gè)HTTP請(qǐng)求包含一條查詢，每個(gè)HTTP響應(yīng)發(fā)回一條查詢結(jié)果。每秒最多接受100次請(qǐng)求，在99.999%比例下請(qǐng)求響應(yīng)時(shí)間小于250毫秒”。

42. Talk the Talk by Mark Richards

【入行說(shuō)行話】

專業(yè)人士之間常用行話交流，而架構(gòu)師最重要的行話就是架構(gòu)模式。模式可以按照層次范圍劃分為四類：企業(yè)架構(gòu)模式、應(yīng)用架構(gòu)模式、集成模式、設(shè)計(jì)模式。企業(yè)架構(gòu)模式處理高層架構(gòu)，設(shè)計(jì)模式處理組件內(nèi)部的架構(gòu)。常見的企業(yè)架構(gòu)模式有事件驅(qū)動(dòng)架構(gòu)(EDA)、面向服務(wù)架構(gòu)(SOA)、面向資源架構(gòu) (ROA)以及管道架構(gòu)(PA)。應(yīng)用架構(gòu)模式是企業(yè)架構(gòu)內(nèi)部應(yīng)用或子系統(tǒng)架構(gòu)的模式，例如J2EE中的會(huì)話面(Session Façade)、傳輸對(duì)象(Transfer Object)模式。集成模式是在應(yīng)用、子系統(tǒng)、組件之間共享信息和功能的模式，比如文件共享、遠(yuǎn)過(guò)程調(diào)用和各種消息收發(fā)模式。設(shè)計(jì)模式是最底層的模式，是架構(gòu)師和開發(fā)人員交流的標(biāo)準(zhǔn)詞匯。還要了解反面模式(anti-patterns)，也就是那些反復(fù)出現(xiàn)、起負(fù)作用、需要避免的過(guò)程。常見的反面模式包括分析麻痹(Analysis Paralysis)、委員會(huì)設(shè)計(jì)(Design By Committee)、蘑菇房管理(Mushroom Management)、死亡征途(Death March)等。了解架構(gòu)模式何以讓我們更清楚、簡(jiǎn)潔、高效地溝通，所謂入行說(shuō)行話(walk the walk and talk the talk)。

43. Heterogeneity Wins by Edward Garson

【異構(gòu)取勝】

在分布式軟件系統(tǒng)中，通信協(xié)議已經(jīng)發(fā)生了一個(gè)重要的演變，就是從二進(jìn)制協(xié)議向文本協(xié)議轉(zhuǎn)變。文本協(xié)議，比如用于Web服務(wù)的XML/SOAP、表述性狀態(tài)轉(zhuǎn)移(REST)、原子資源(Atom)、可擴(kuò)展消息傳遞及呈現(xiàn)協(xié)議(XMPP)，使得通信更為簡(jiǎn)單靈活，系統(tǒng)的不同部分可以按照自己的需要選擇不同的編程語(yǔ)言，以便發(fā)揮最佳的效果。由此形成的異構(gòu)系統(tǒng)，必將超越過(guò)去由單一語(yǔ)言主宰的系統(tǒng)。

44. Dwarves, Elves, Wizards, andKings by Evan Cofsky

【小矮人、精靈、巫師和國(guó)王】

RandyWaterhouse在《Cryptonomicon》中將他遇到的人分為四類，他們是：

小矮人(Dwarves)： 他們?cè)诤诎档亩囱ㄖ行燎趧趧?dòng)，制作出漂亮的物品。他們的手藝名揚(yáng)四方，他們的力量改變著大地。

精靈(Elves)：他們溫文爾雅，終日創(chuàng)造美麗神奇的東西。他們天賦極高，能實(shí)現(xiàn)其他種族不可思議的東西。

巫師(wizards)：他們精通魔法，無(wú)比強(qiáng)大。

國(guó)王(Kings)： 他們是領(lǐng)袖，知道如何調(diào)遣其他角色。

架構(gòu)師好比是國(guó)王，該熟悉各個(gè)角色，還要保證所設(shè)計(jì)的架構(gòu)中具有這些角色的位置。只為個(gè)別角色設(shè)計(jì)架構(gòu)，就只能吸引個(gè)別的角色，不能發(fā)揮大家的特長(zhǎng)。一個(gè)好國(guó)王，會(huì)給大家樹立追求的愿景，會(huì)讓大家各司其責(zé)，共同學(xué)習(xí)，共同成長(zhǎng)，實(shí)現(xiàn)目標(biāo)。

45. Learn from Architects ofBuildings by Keith Braithwaite

【向建筑師學(xué)習(xí)】

“建筑是一種社會(huì)行為，是人類活動(dòng)的物質(zhì)場(chǎng)所。”—Spiro Kostof

(在建筑中要充分考慮人和社會(huì)的因素)

“良好的教育和豐富的心靈也許能造就偉大的頭腦，卻不能造就偉大的建筑。”—Frank Lloyd Wright

(不斷嘗試和改進(jìn)才能接近完美)

“醫(yī)生出了錯(cuò)可以將死人埋掉，建筑師出了錯(cuò)只能讓客戶種爬藤遮丑。”—ibid

(避免設(shè)計(jì)錯(cuò)誤很重要)

“建筑師堅(jiān)信，不僅要做上帝身邊的助手，還應(yīng)該伺機(jī)取得上帝的寶座。”—Karen Moyer

(要立志精通客戶的業(yè)務(wù))

“在建筑中和在一切操作藝術(shù)中一樣，最后都要?dú)w于操作。操作的結(jié)果應(yīng)當(dāng)就是良好的建筑。好建筑有三個(gè)條件：有用、牢固、愉悅。”—Henry Watton

(好東西不經(jīng)要有用、耐用，還要賞心悅目啊)

"建筑師一定是雕塑家或畫家。如果他不是雕塑家或畫家，他只能做個(gè)建筑工。"—John Ruskin

(美很重要)

"聽起來(lái)有點(diǎn)矛盾、但它的確是一個(gè)重要的真理：沒(méi)有哪個(gè)建筑能達(dá)到無(wú)瑕疵的崇高。"—ibid

(好作品也帶有作者和時(shí)代的局限性)

46. Fight repetition by NiclasNilsson

【消除重復(fù)】

軟件開發(fā)中有兩條真理：抄襲是作惡;重復(fù)勞動(dòng)降低開發(fā)速度。如果一個(gè)項(xiàng)目的軟件大量存在復(fù)制、粘貼、修改的工作方式，或者不同地方都在處理驗(yàn)證、審核、日志、數(shù)據(jù)持久化之類的工作，那么就有嚴(yán)重的重復(fù)問(wèn)題。消除重復(fù)是架構(gòu)師的職責(zé)。完全順序書寫的代碼只適合于給計(jì)算機(jī)執(zhí)行，良好的代碼是給人讀的，要讓人讀起來(lái)清楚、高效、輕松，那么就要消除重復(fù)性。使用恰當(dāng)?shù)目蚣?包括面向方面編程框架)、對(duì)功能進(jìn)行再抽象等，都是消除重復(fù)的方法。

47. .Welcome to the Real World byGregor Hohpe

【走進(jìn)現(xiàn)實(shí)世界】

工程師喜歡精確，01世界的軟件工程師尤其喜歡按部就班的順序處理，喜歡是非分明�？墒乾F(xiàn)實(shí)世界卻是凌亂的�？蛻粝聠沃�后很快又要取消，支票被拒付，信件丟失，付款延期，承諾落空。用戶不按要求輸入數(shù)據(jù)，不按規(guī)定步驟操作。分布式系統(tǒng)帶來(lái)了更多的不一致性：服務(wù)連不通，不發(fā)通知就改接口，沒(méi)有事務(wù)保證�，F(xiàn)實(shí)就是這個(gè)樣子，早晚總會(huì)出問(wèn)題，你得承認(rèn)它。但也別太害怕。事件驅(qū)動(dòng)編程、狀態(tài)機(jī)模式、錯(cuò)誤重試等這些都是可以采用的技術(shù)。只是，在現(xiàn)實(shí)世界里，你要記�。盒前涂丝Х鹊瓴贿m用兩階段提交。

48. Don't Control, but Observe byGregor Hohpe

【寧觀察、不控制】

過(guò)去的系統(tǒng)比較簡(jiǎn)單而固定，在架構(gòu)上是實(shí)現(xiàn)設(shè)計(jì)模型，按模型控制構(gòu)建過(guò)程。但是，21世紀(jì)的軟件開發(fā)中，在松耦合的基礎(chǔ)上對(duì)軟件提出了隨著時(shí)間演化的柔性(flexible)要求，因此就不再能夠嚴(yán)格控制。針對(duì)這種情況，可以先不用設(shè)計(jì)靜態(tài)的結(jié)構(gòu)，而是在演化中持續(xù)觀察，從觀察所得到的數(shù)據(jù)中抽象出當(dāng)時(shí)的模型，按照規(guī)則對(duì)模型進(jìn)行驗(yàn)證，保證它沒(méi)有循環(huán)依賴、空接收通道的消息發(fā)送等問(wèn)題。

49. Janus the Architect by DaveBartlett

【向雅努斯學(xué)習(xí)】

雅努斯(Janus)是羅馬神話中的門神，他有兩個(gè)頭顱，守衛(wèi)著過(guò)去通向未來(lái)的大門。架構(gòu)師要向雅努斯那樣，能傾聽客戶的訴求、分析他們的趨勢(shì)。他設(shè)計(jì)出來(lái)的架構(gòu)既要滿足眼前的需要，又要適應(yīng)即將到來(lái)的變革，經(jīng)得起時(shí)間的考驗(yàn)。

50. Architects focus is on theboundaries and interfaces by EinarLandre

【架構(gòu)師關(guān)注邊界和接口】

處理復(fù)雜系統(tǒng)的基本策略是“分而治之、各個(gè)擊破”。架構(gòu)師要將整個(gè)系統(tǒng)劃分成若干情景(Context)，各個(gè)情景有自己明確的邊界 (Boundary)，情景之間有組織歸屬、功能使用或者技術(shù)依賴關(guān)系，這些關(guān)系通過(guò)接口來(lái)具體實(shí)現(xiàn)。關(guān)注邊界和接口的結(jié)果，是形成低耦合、高內(nèi)聚的系統(tǒng)。

51. Challenge assumptions -especially your own by Timothy High

【不要想當(dāng)然】

因?yàn)閍ssume(想當(dāng)然)=ass(蠢驢) +u(你)+me(我)，所以想當(dāng)然會(huì)使你我與蠢驢為伍。

沒(méi)有事實(shí)依據(jù)的道聽途說(shuō)未必正確，沒(méi)有事實(shí)依據(jù)的主觀臆斷往往是錯(cuò)的。即使正確的結(jié)論，也因時(shí)勢(shì)的變遷而發(fā)生改變。所以，在架構(gòu)設(shè)計(jì)中，但凡要在幾種選項(xiàng)之間做出取舍的地方(比如性能與可維護(hù)性、成本與上市時(shí)間等)，都要提供選擇的理由。理由不能只是簡(jiǎn)單的論斷，要有考查的要素(比如技術(shù)條件、人員技能、政策環(huán)境等)及其事實(shí)依據(jù)，。

52. Record your rationale by Timothy High

【記錄你的理由】

在作出技術(shù)取舍的時(shí)候，都要提供選擇的理由。提供理由的方式是把它記錄下來(lái)。要說(shuō)明做了什么決定、選擇了什么、拒絕了什么，為何選這種而不選那種。這些文檔可以讓開發(fā)人員理解架構(gòu)設(shè)計(jì)的內(nèi)在邏輯、讓客戶理解為何某些部分要求更加昂貴的硬件設(shè)備、讓將來(lái)?xiàng)l件改變以后對(duì)系統(tǒng)架構(gòu)進(jìn)行修改更容易。

53. Empower developers by Timothy High

【培養(yǎng)開發(fā)人員】

架構(gòu)師要盡力培養(yǎng)開發(fā)人員。為他們提供足夠的設(shè)備、網(wǎng)絡(luò)、數(shù)據(jù)、資料。保證他們具有所需的技能，不足的就要安排培訓(xùn)。開發(fā)人員除了能動(dòng)手實(shí)踐，還要參與學(xué)術(shù)討論，所以如果有出差經(jīng)費(fèi)的要讓組員參加各種宣講或會(huì)議，沒(méi)有經(jīng)費(fèi)的也要加入技術(shù)性的郵件列表并參與本地的一些活動(dòng)。平庸的團(tuán)隊(duì)不可能做出大事情，要盡可能參加選擇開發(fā)人員的過(guò)程，尋找那些對(duì)技術(shù)好學(xué)上進(jìn)并且善于與團(tuán)隊(duì)合作的人。在和軟件設(shè)計(jì)的大目標(biāo)不沖突的地方，要讓開發(fā)人員自主決策。制定編碼原則、編碼規(guī)范。保護(hù)開發(fā)人員免受不必要的文字工作、辦公室雜務(wù)等打攪。架構(gòu)師雖然不是項(xiàng)目經(jīng)理，但在軟件開發(fā)過(guò)程方面要積極參與管理，消除各種障礙。

54. It is all about the data by Paul W. Homer

【軟件都跟數(shù)據(jù)有關(guān)】

一般討論編碼的時(shí)候，都是站在面向指令的視角，講命令、函數(shù)、算法�？墒且�理解一個(gè)復(fù)雜的系統(tǒng)(比如UNIX操作系統(tǒng))，就很難在成千上萬(wàn)行代碼中理出頭緒。這時(shí)，如果我們關(guān)注代碼下面的數(shù)據(jù)(比如UNIX系統(tǒng)的文件、進(jìn)程等)，就相對(duì)容易理解些了。形成這種對(duì)比的原因是代碼很龐雜，而數(shù)據(jù)則很簡(jiǎn)潔。后者就是面向數(shù)據(jù)的視角。大多數(shù)問(wèn)題的核心是數(shù)據(jù)問(wèn)題。關(guān)注數(shù)據(jù)，能更容易地處理復(fù)雜系統(tǒng)問(wèn)題。要在系統(tǒng)建設(shè)早期完整地設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)，避免在系統(tǒng)建設(shè)過(guò)程中或投入運(yùn)行后再來(lái)修改數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)結(jié)構(gòu)修改將導(dǎo)致大量的代碼修改。

55. Control the data, not just thecode by Chad LaVigne

【控制數(shù)據(jù)，而不只是代碼】

只有由代碼自動(dòng)構(gòu)建程序的工具是不夠的。手工或者編寫腳本來(lái)修改數(shù)據(jù)庫(kù)、添加數(shù)據(jù)不僅效率低下，而且容易出錯(cuò)。自動(dòng)構(gòu)建工具不僅要考慮代碼的變化，還要考慮數(shù)據(jù)結(jié)構(gòu)的變化，它們是不可分割的一個(gè)整體。

56. Don't Stretch The ArchitectureMetaphors by David Ing

【不要讓比喻誤導(dǎo)他人】

在描述抽象或新的設(shè)計(jì)時(shí)，架構(gòu)師喜歡使用比喻�？墒牵�比喻容易讓人誤解。比如，“一個(gè)游艇一樣的系統(tǒng)”，言者可能指的是池子里的小船，而聽者理解的是橫跨太平洋的豪華游輪。又比如，“一個(gè)文件柜”，言者只是想表示內(nèi)容是按字母排列的，而聽者卻想的是文件柜有六個(gè)面、上面還嵌入了一個(gè)鐘表。只在開始的時(shí)候使用比喻，然后要迅速轉(zhuǎn)入精確的描述，不能停留在比喻上。

57. Focus on Application Supportand Maintenance by Mncedisi Kasper

【關(guān)注應(yīng)用支持與維護(hù)】

很多架構(gòu)師出身于開發(fā)人員，因此他們過(guò)多地關(guān)注開發(fā)階段而很少關(guān)注軟件系統(tǒng)運(yùn)行以后的支持和維護(hù)階段。其實(shí)，一個(gè)軟件系統(tǒng)的生命周期中，支持維護(hù)階段超過(guò)80%以上的時(shí)間比例。所以，設(shè)計(jì)之初，就要關(guān)注支持維護(hù)。要注意，支持人員和開發(fā)人員不同，他們沒(méi)有IDE工具，沒(méi)有復(fù)雜的測(cè)試工具，也不能隨意關(guān)閉和啟動(dòng)生產(chǎn)系統(tǒng)。系統(tǒng)要給他們提供足夠的問(wèn)題跟蹤、審核、分析手段。只有系統(tǒng)管理員滿意了，才會(huì)大家都滿意。

58. Prepare to pick two by Bill dehOra

【學(xué)會(huì)三選二】

著名的Brewer猜想說(shuō)：對(duì)于現(xiàn)代分布式應(yīng)用系統(tǒng)來(lái)說(shuō)，數(shù)據(jù)一致性(Consistency)、系統(tǒng)可用性(Availability)、服務(wù)規(guī)�？煞謪^(qū)性(Partitioning)三個(gè)目標(biāo)(合稱CAP)不可同時(shí)滿足，最多只能選擇兩個(gè)。

59. Prefer principles, axioms andanalogies to opinion and taste byMichael Harmer

【多用原則、公理和民意，少用觀點(diǎn)和偏好】

架構(gòu)師個(gè)人的觀點(diǎn)和偏好需要結(jié)合項(xiàng)目的實(shí)際情況進(jìn)行仔細(xì)分析、充分論證，才能作為架構(gòu)設(shè)計(jì)的依據(jù)。而原則、公理和民意，相對(duì)可以直接地作為架構(gòu)設(shè)計(jì)的依據(jù)。所以，要提高架構(gòu)水平和提高效率，可以多用原則、公理和民意，少用個(gè)人的觀點(diǎn)和偏好。