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

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

【需求先于履歷】

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

2. Simplify essential complexity;diminish accidental complexity by NealFord

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

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

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

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

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

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

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

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

5. Architecting is aboutbalancing by Randy Stafford

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

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

6. Seek the value in requestedcapabilities by Einar Landre

【鑒別客戶要求中的價(jià)值】

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

7. Stand Up! by Udi Dahan

【站著說話】

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

8. Skyscrapers aren't scalable byMicheal Nygard

【摩天大樓不可伸縮】

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

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

【談判多過你的想象】

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

10. Quantify by Keith Braithwaite

【量化】

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

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

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

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

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

【沒有通用解決方案】

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

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

【盡早考慮性能】

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

14. 14.Application architecturedetermines application performance byRandy Stafford

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

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

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

【帶錯(cuò)提交是禍害】

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

16. There Can be More than One by Keith Braithwaite

【世界并非千篇一律】

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

17. Business Drives by Dave Muirhead

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

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

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

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

用戶掏錢買的往往不是什么通用的功能，大多數(shù)時(shí)候他們只看重其中自認(rèn)為重要的部分。設(shè)計(jì)的產(chǎn)品要先滿足具體的要求，經(jīng)過實(shí)踐并簡化掉那些不必要的東西，才能進(jìn)行泛化推廣;要先有使用的機(jī)會(huì)，才能帶來重用的機(jī)會(huì)。如果一開始就以通用、重用為目的閉門造車，結(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)團(tuán)隊(duì)就必須知道團(tuán)隊(duì)成員需要知道的技術(shù)。架構(gòu)師和項(xiàng)目經(jīng)理，好比飛機(jī)上的副駕駛和駕駛。飛機(jī)常常是副駕駛操縱，可是關(guān)鍵時(shí)刻得看駕駛的。項(xiàng)目經(jīng)理忙于日常任務(wù)安排、資源調(diào)配，而架構(gòu)師看似清閑，而在技術(shù)決策中要提出重要的意見，對(duì)保證項(xiàng)目的質(zhì)量和按期交付起著很大的作用。

20. Continuously Integrate by Dave Bartlett

【持續(xù)集成】

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