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

1. Don't put your resume ahead ofthe requirements by Nitin Borwankar

【需求先于履歷】

身為架構(gòu)師要平衡客戶、公司和個人的利益。用時興的技術(shù)為個人履歷增光添彩固然重要，但應(yīng)該把客戶的長遠需求放在首位。約束技術(shù)偏好，能夠使客戶、團隊、自己和家人都多些快樂。在未來的工作中，客戶的口碑是比個人的履歷更加寶貴的東西。

2. Simplify essential complexity;diminish accidental complexity by NealFord

【簡化先天復(fù)雜性，避免后天復(fù)雜性】

任何業(yè)務(wù)問題都有其復(fù)雜性，簡化復(fù)雜性是客觀需要。但為此采取的工作很可能帶來新的復(fù)雜性。了解代碼中真正用于處理業(yè)務(wù)的比例，從實踐中發(fā)展出恰當(dāng)?shù)南到y(tǒng)框架，避免隨意添加框架。后天復(fù)雜性的積累會使系統(tǒng)越來越難以維護和升級。

3. Chances are your biggest problemisn't technical by Mark Ramm

【技術(shù)不是最大問題】

聰明的架構(gòu)師能夠選擇最恰當(dāng)?shù)募夹g(shù)，而有效的架構(gòu)師則還要說服開發(fā)人員理解他的選擇。軟件是由人開發(fā)的，人心不齊才是最大的問題。有時人的問題導(dǎo)致項目失敗，卻讓技術(shù)來背黑鍋。必要時應(yīng)進行平等的對話、理性的分析、耐心的解釋。

4. Communication is King; Clarityand Leadership its humble servants byMark Richards

【溝通為王，澄清和引領(lǐng)為仆】

閉門造車、發(fā)號施令的架構(gòu)師必將被反抗的開發(fā)者所推翻。架構(gòu)師應(yīng)就項目的宗旨和目標與開發(fā)人員溝通。有效溝通的要點是簡明和垂范。拋開長篇大論的 Word文檔，使用清晰易懂的Visio圖形;討論時使用白板，對重要的內(nèi)容拍照記錄。與QA、PM和開發(fā)人員密切合作，讓他們了解架構(gòu)過程，洞悉架構(gòu)全景，引領(lǐng)他們走出迷茫。

5. Architecting is aboutbalancing by Randy Stafford

【在平衡中進行架構(gòu)】

架構(gòu)工作包括模塊劃分、接口定義、職責(zé)分配、模式應(yīng)用、性能優(yōu)化等傳統(tǒng)技術(shù)活動，也要考慮安全、可用性、支持、發(fā)布、開發(fā)條件等問題，更要照顧管理人員、操作人員、維護人員等有關(guān)各方的關(guān)切。要在平衡各方關(guān)切的過程中開展架構(gòu)工作。

6. Seek the value in requestedcapabilities by Einar Landre

【鑒別客戶要求中的價值】

客戶往往把他們的思考作為解決他們所面臨的問題的方案。但客戶要求未必都是對解決實際問題有價值的。架構(gòu)師應(yīng)當(dāng)提出更好、更節(jié)約的解決方案。這一目標可以通過和客戶進行討論達到。和客戶討論時，多從業(yè)務(wù)角度問問為什么，少使用軟件術(shù)語，不要假定客戶具有軟件方面的知識。

7. Stand Up! by Udi Dahan

【站著說話】

架構(gòu)師和項目組成員的溝通，不應(yīng)象過去和機器打交道一樣隨意。當(dāng)你的聽眾超過一個人時，自己就應(yīng)當(dāng)站著說話。站著說話的好處是有指揮整個房間的氣勢，增加了你的權(quán)威和自信，別人更不容易打斷你的話。站著說話還能使用眼神交流、肢體語言，也有助于控制聲音。站著說話，能提高溝通效果。

8. Skyscrapers aren't scalable byMicheal Nygard

【摩天大樓不可伸縮】

把軟件工程比喻成蓋樓，有好的一面。從荒蕪的工地到聳立的高樓，過程漫長。每一段時間中，每一個工人都要各盡其責(zé)，每一個未完工的構(gòu)件都要穩(wěn)穩(wěn)當(dāng)當(dāng)才行，值得軟件工程學(xué)習(xí)，這就是一次一個組件的增量部署。這個比喻也有不恰當(dāng)?shù)囊幻�。摩天大樓在造成以后就不可搬遷、不可加層。而軟件則可以反復(fù)調(diào)整，這就是“及早發(fā)布”(Early release)。

9. You're negotiating more oftenthan you think. by Michael Nygard

【談判多過你的想象】

我們作為工程師，更愿意與人協(xié)作。而項目負責(zé)人作為控制項目成本的人，更在乎削減成本。我們看到的是談話，他看到的是談判，所以我們常常遭受預(yù)算打擊。如果你提了冗余、備份之類的東西后，他問你“這個東西必須要有嗎?”,千萬不要讓步。不要說“沒有也行，只是會在故障恢復(fù)期間不能運行”這樣的話。反而要說：“事實上不僅要兩套，要四套才能確保萬無一失。沒有這個，每天就至少會有三次出問題，而且不排除當(dāng)你正在給董事長做演示的時候出問題。”

10. Quantify by Keith Braithwaite

【量化】

需求必須量化。“快”、“好”、”伸縮性”、“可用性”、“靈活”、“極少”、“大量”等都不是需求，因為它們不可量化，這些詞找不到客觀的衡量標準。談需求的時候，必須說明數(shù)目、時間、來源、去向，不能準確給出數(shù)值的，必須指明一個具體的范圍。例如：最大響應(yīng)時間1500毫秒，平均響應(yīng)時間為 750至1250毫秒。

11. One line of working code isworth 500 of specification by Allison Randal

【一行正確代碼勝過千言萬語】

設(shè)計說明是宏觀描述，代碼則是微觀實現(xiàn)。可是如果設(shè)計說明脫離了編碼實現(xiàn)，猶如違背物理學(xué)原理的大樓設(shè)計，縱使它美輪美奐，也會轉(zhuǎn)眼間土崩瓦解。架構(gòu)師做設(shè)計時，要時刻想著編碼人員如何實現(xiàn)它。設(shè)計完成后，如果程序員提出質(zhì)疑，往往就是設(shè)計有問題，至少是設(shè)計不清晰。對設(shè)計進行再修改是正常的事情。

12. There is no one-size-fits-allsolution by Randy Stafford

【沒有通用解決方案】

一雙鞋難合千人腳，過去積累的經(jīng)驗未必適合現(xiàn)在具體的應(yīng)用情景，架構(gòu)師要堅持鍛煉自己的情景意識，按照新的情景進行設(shè)計。想要打造一個通用的解決方案往往造成過度設(shè)計，添加大量無關(guān)宏旨、甚至影響性能的不合理要求。

13. It's never too early to thinkabout performance by Rebecca Parsons

【盡早考慮性能】

用戶通常只會提出功能需求。架構(gòu)師要盡早考慮非功能需求。性能測試也要及早展開。

14. 14.Application architecturedetermines application performance byRandy Stafford

【軟件系統(tǒng)架構(gòu)決定性能】

如果架構(gòu)不良，性能就不會良好。資源不是無限的，動用再多的性能調(diào)優(yōu)手段，到頭來也是束手無策。

15. Commit-and-run is a crime. by Niclas Nilsson

【帶錯提交是禍害】

下班時間到了才寫完最后一行代碼，干脆省略了編譯、測試的過程，直接提交代碼，迅速奔赴約會。這種做法使得隱藏的錯誤隨著項目組其他開發(fā)人員更新代碼而擴散，導(dǎo)致其他人不敢更新代碼，打亂了大家的工作流程。個別開發(fā)人員把自己該做的工作留給他人是錯誤的。當(dāng)然，架構(gòu)師也應(yīng)考慮給開發(fā)人員創(chuàng)造好有利的環(huán)境。比如，自動構(gòu)建工具、自動測試工具、測試驅(qū)動開發(fā)實踐、持續(xù)集成服務(wù)器等。

16. There Can be More than One by Keith Braithwaite

【世界并非千篇一律】

技術(shù)上能做到強求統(tǒng)一，實現(xiàn)一套數(shù)據(jù)模型、一種消息格式、一套收發(fā)系統(tǒng)，如此等等�？墒菢I(yè)務(wù)世界往往是不一致、多側(cè)面、甚至模糊的。統(tǒng)一的設(shè)計未必能滿足各種業(yè)務(wù)要求，應(yīng)當(dāng)要允許那些互相矛盾、重復(fù)或交叉的非功能特性存在。

17. Business Drives by Dave Muirhead

【業(yè)務(wù)決定技術(shù)】

為了建設(shè)一個系統(tǒng)，架構(gòu)師必須把技術(shù)部門和業(yè)務(wù)部門團結(jié)在一起。但要明白二者的立場是不同的，避免技術(shù)人員作出業(yè)務(wù)決策。建造系統(tǒng)通常都是講求投資回報的，從開工到投產(chǎn)要不斷遇到各種技術(shù)上的決策，要一直以滿足業(yè)務(wù)部門的要求為準則，才能獲得最大的投資回報。如果業(yè)務(wù)部門對技術(shù)部門的提問遲遲不予答復(fù)，那么可以視為委托開發(fā)團隊考慮。即使這樣也不能直接將問題交回給技術(shù)人員，因為業(yè)務(wù)問題是宏觀問題，技術(shù)決策是微觀問題。架構(gòu)師應(yīng)當(dāng)組織討論并拿出答案。

18. Simplicity before generality,use before reuse by Kevlin Henney

【先簡化再泛化、先使用再重用】

用戶掏錢買的往往不是什么通用的功能，大多數(shù)時候他們只看重其中自認為重要的部分。設(shè)計的產(chǎn)品要先滿足具體的要求，經(jīng)過實踐并簡化掉那些不必要的東西，才能進行泛化推廣;要先有使用的機會，才能帶來重用的機會。如果一開始就以通用、重用為目的閉門造車，結(jié)果很可能是無用、難用、棄用。

19. Architects must be handson by John Davies

【架構(gòu)師必須是高手】

架構(gòu)師不是空談家，他必須在數(shù)據(jù)庫、軟件編程、數(shù)據(jù)信息、網(wǎng)絡(luò)等某一領(lǐng)域有專長并且通曉其它領(lǐng)域，換句話說，他要想帶領(lǐng)團隊就必須知道團隊成員需要知道的技術(shù)。架構(gòu)師和項目經(jīng)理，好比飛機上的副駕駛和駕駛。飛機常常是副駕駛操縱，可是關(guān)鍵時刻得看駕駛的。項目經(jīng)理忙于日常任務(wù)安排、資源調(diào)配，而架構(gòu)師看似清閑，而在技術(shù)決策中要提出重要的意見，對保證項目的質(zhì)量和按期交付起著很大的作用。

20. Continuously Integrate by Dave Bartlett

【持續(xù)集成】

過去軟件項目中提倡及早構(gòu)建、及時發(fā)布，以便盡早發(fā)現(xiàn)風(fēng)險、避免風(fēng)險。隨著自動構(gòu)建技術(shù)日趨成熟，現(xiàn)在已經(jīng)能夠做到持續(xù)集成了。持續(xù)集成(CI)工具可以自動構(gòu)建、測試，在完成時還能向外發(fā)送電郵或即時信息。