国产精品一区二区av交换,中文字幕人成无码免费视频,永久免费av无码网站性色av,欧美一道本一区二区三区,樱桃熟了a级毛片

80. Don’t Be a Problem Solver by Eben Hewitt

【不做解題機】

作為一個架構(gòu)師，要處理的問題是方方面面的。不要在開發(fā)人員一遇到編程問題就幫他們解答。很多問題往往他們自己可以查資料找到答案。幫助他們解答簡單的問題是放棄了處理更復(fù)雜問題的機會。

作為一個架構(gòu)師，要知道解決問題的最好方式就是避免發(fā)生問題。不要對所有問題一概接收，要使用成熟好用工具，一開始就避免發(fā)生問題。沒有問題，比解決問題好。

81. Choose your weapons carefully,relinquish them reluctantly by Chad LaVigne

【在恰當(dāng)?shù)臅r候，鳥槍換炮】

架構(gòu)師的武器庫中，有自己歷經(jīng)大小戰(zhàn)役的各式武器。新武器紛紛出世，該換的時候就得換。但換武器也得考慮時機。

一要評估風(fēng)險：新武器是否適用于眼前的項目?

二要評估成本：掌握新技術(shù)所花費的人力物力是否負擔(dān)得起?

三要評估形勢：看中的武器是曇花一現(xiàn)還是大勢所趨?

82. Your Customer is Not YourCustomer by Eben Hewitt

【客戶的客戶，才是我們的客戶】

當(dāng)討論需求的時候，不要只顧著聽客戶的陳述�？蛻粢苍S不了解他的客戶想要什么。而找出他的客戶(系統(tǒng)的終端用戶)的真實需求，是系統(tǒng)成功的必要條件。所以說，客戶的客戶，才是我們的客戶。要關(guān)心客戶的客戶。

83. It will never look likethat by Peter Gillard-Moss

【系統(tǒng)不會是設(shè)計的模樣】

在一個永恒變化的世界中，設(shè)計是一個持續(xù)進行和經(jīng)驗實證的過程。無論當(dāng)初設(shè)計如何深入細致，系統(tǒng)永遠不會像設(shè)計的那樣變成現(xiàn)實。某些情況總會發(fā)生，某個外部因素總會影響系統(tǒng)，甚至內(nèi)部某個人的代碼也會出現(xiàn)異常�；蛘咴O(shè)計依賴的某些信息出錯，或者推論不正確，或者混淆了某些概念的細微差別。也許需求變了，也許技術(shù)更新了，也許某人找到了比你更好的方法。這些微小的變化促使你修改設(shè)計，從一個版本到另一個版本，直到你不堪忍受。

84. Choose Frameworks that playwell with others by Eric Hawthorne

【選擇好搭配的框架】

在選擇框架的時候，不僅要看它是否在自己擅長的領(lǐng)域做得好，還要看它是否容易和其它框架搭配。對框架的要求是：謙虛、簡單、專業(yè)。所謂謙虛，是指不妄想包攬自己不擅長領(lǐng)域的工作，不和其它框架重疊。

85. Make a strong businesscase by Yi Zhou

【搞定一個強大的業(yè)務(wù)專案】

以下五步，助你做成一個強大的業(yè)務(wù)專案。

建立價值提議：你的新軟件架構(gòu)有什么價值?和其它架構(gòu)相比如何提高生產(chǎn)能力和效率?

制定量化指標：帶來的豐厚回報包括哪些合理的數(shù)據(jù)指標?

換成傳統(tǒng)標準：把這些數(shù)據(jù)指標換算成傳統(tǒng)的業(yè)務(wù)標準——金錢，它們是多少?

了解何處停手：向項目干系人了解，這項提議在哪些業(yè)務(wù)上應(yīng)用以后，能夠適可而止?

尋找恰當(dāng)時機：什么時候用戶比較能接受我們的提議?比如另一個架構(gòu)慘遭失敗的時候。

86. Pattern Pathology by Chad LaVigne

【模式病】

模式是為了交流和理解而總結(jié)的設(shè)計方法。在設(shè)計上使用模式，要考慮實用、高效。如果為了炫耀自己關(guān)于模式的知識，在設(shè)計中塞入大量模式，那就犯了模式病。要以高效的解決方案為中心，只采用那些的確能解決問題的模式，避免犯模式病。

87. Learn a new language by Burk Hufnagel

【學(xué)習(xí)新語言】

要學(xué)習(xí)業(yè)務(wù)部門的業(yè)務(wù)語言，才能和他們有效溝通。

要學(xué)習(xí)編程人員的技術(shù)語言，才能和他們有效溝通。

88. Don't Be Clever by Eben Hewitt

【不要聰明要愚笨】

做人，尤其是做架構(gòu)師，確實是需要有思想、有知識、有遠見。可是，我們設(shè)計的架構(gòu)卻應(yīng)該反過來，不要聰明，要愚笨。所謂愚笨，就是簡單，堅持一個組件只能在確定的條件下做一件事。聰明的組件造價高昂，維護艱難。愚笨的組件開發(fā)容易，維護簡單。聰明的架構(gòu)在現(xiàn)實面前往往脆弱不堪，愚笨的架構(gòu)卻生命長久。

89. Build Systems to be Zuhanden byKeith Braithwaite

【建造應(yīng)手的系統(tǒng)】

應(yīng)手(德文zuhanden)和在手(德文vorhanden)是哲學(xué)家海德格爾創(chuàng)造的概念。應(yīng)手的東西是人在達成他的目標時隨手可用的工具，它近乎成為人身體的一部分而不需要關(guān)注，只需要使用。在手的東西是需要人時刻關(guān)注的工具，它要顯示自己的存在，要強調(diào)自己的權(quán)利，以致于主人因注意它而難于接近目標。我們建造系統(tǒng)的時候，容易把系統(tǒng)看得太重，建造出在手的系統(tǒng)。但一個真正好的系統(tǒng)，應(yīng)該是應(yīng)手的系統(tǒng)，對于用戶越透明越好。

90. Find and retain passionate problemsolvers by Chad LaVigne

【尋找和挽留有激情的問題解決者】

組建一支好的開發(fā)團隊，要靠出眾的開發(fā)人員。開發(fā)人員不僅要有豐富的知識，更要有解決問題的熱情和技能。選人的時候，不要太關(guān)注知識，而忽略了熱情和技能。

91. Software doesn’t really existby Chad LaVigne

【軟件無形】

軟件工程和傳統(tǒng)的土木工程比起來，具有產(chǎn)品無形的特點。無形意味著我們可以不按土木工程那樣的順序來建造，這是它的好處�？墒�，無形也有壞處。用戶容易產(chǎn)生誤解，以為軟件可以隨便修改、可以中途大幅度地變更需求。

92. Pay down your technical debtby Burk Hufnagel

【償還技術(shù)債務(wù)】

一個使用中的系統(tǒng)，總有一天會出現(xiàn)BUG或者要增加新特性。這時候有兩種相反的意見�？蛻粢�求盡快解決，而開發(fā)人員卻要求慢慢設(shè)計、修改、測試。面對這樣的矛盾，架構(gòu)師就會想，不如走條捷徑，把問題應(yīng)付了事。但是，在技術(shù)問題上，沒有捷徑可走，該做的工作總要做。捷徑不僅有快的一面，也有臟的一面。把臟東西放到系統(tǒng)中，增加了系統(tǒng)的不穩(wěn)定性，提高了將來運行維護的成本。第一次不做好，以后就要付出利息。所以，要看客戶的要求到底有多急迫，是否值得付出技術(shù)上的利息而做那種匆匆忙忙的發(fā)布。如果一定要盡快發(fā)布，也不要發(fā)布了就止步不前。要馬上投入新工作，提供良好技術(shù)解決方案，盡快償還欠下的債務(wù)。

93. You can't future-proofsolutions by Richard Monson-Haefel

【不能做面向未來的方案】

人不能預(yù)測未來是一條普遍的真理。未來不是十年二十年那么漫長的時間，未來就在這確定的一刻之后。周一活生生見面的人，周二卻傳來撞車的噩耗，這便是未來不確定的例證。今日選擇的語言會成為明日的COBOL，今日選擇的框架會成為明日的DCOM。要弄明白今日的需求已是不易，想知道明日的需求終歸徒勞。不如務(wù)實一些，就提供對今日需求的最佳解決方案吧。

94. The User Acceptance Problem byNorman Carnovale

【用戶接受問題】

人們往往難以接受一個新系統(tǒng)或者大升級。究其原因，有以下幾種：

(1) 有的人擔(dān)心新系統(tǒng)替代老系統(tǒng)后功能無法使用，自己失去影響和權(quán)力。

(2) 有的人害怕未經(jīng)檢驗的新技術(shù)。

(3) 有的人擔(dān)心成本/預(yù)算。

(4) 有的人只是不喜歡變化。

針對不同的擔(dān)憂，用培訓(xùn)、演示等方式與用戶分享新系統(tǒng)帶來的好處、新系統(tǒng)的局限，促進用戶接受新系統(tǒng)。

95. The Importance of Consommé by Eben Hewitt

【清湯的重要性】

美味的牛肉清湯需要精心制作，要剔除眾多雜質(zhì)才能得到。據(jù)說有的烹飪學(xué)校的老師把十美分硬幣放在碗底進行檢驗，能透過湯看清硬幣上的日期的，才算好湯。軟件架構(gòu)也需要反復(fù)提問、反復(fù)調(diào)整，需要去除各種雜質(zhì)，直到只剩下簡單、可核實的關(guān)于系統(tǒng)真實特性的描述。

96. For the end-user, the interfaceis the system by Vinayak Hegde

【對于終端用戶，界面就是系統(tǒng)】

不管你的系統(tǒng)有多先進和與眾不同，如果它的用戶界面讓人痛苦，就等于系統(tǒng)讓人痛苦。有很多好系統(tǒng)被壞界面給遮蔽了。要把用戶界面當(dāng)作軟件項目中的重要決策之一來對待。

97. Great software is not built, itis grown by Bill de hora

【偉大的軟件不是建造出來的，它是生長出來的】

雖然軟件要進行架構(gòu)設(shè)計，也從建筑和工程中借鑒了很多比喻，可偉大的軟件不是建造出來的，它是生長出來的。一開始就建造龐大的軟件，很容易失敗。我們要有宏大的遠景，但是必須要在小處下手。先做一個小的系統(tǒng)，再慢慢演化升級，向心目中的遠景靠近。