軟件架構(gòu)師應(yīng)該知道的97件事
當(dāng)前位置:點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
1. 客戶需求重于個(gè)人簡(jiǎn)歷 ( Nitin Borwankar ) 客戶需求至上。沽名釣譽(yù),事與愿違。 2. 簡(jiǎn)化根本復(fù)雜性 ,消除偶發(fā)復(fù)雜性 ( Neal Ford ) 分析問(wèn)題好比撥云見(jiàn)月、水落石出。 3. 關(guān)鍵問(wèn)題可能不是出在技術(shù)上 ( Mark Ramm ) 團(tuán)隊(duì)同心,其利斷金。 4. 以溝通為中心,堅(jiān)持簡(jiǎn)明清晰的表達(dá)方式和開(kāi)明的領(lǐng)導(dǎo)風(fēng)格 ( Mark Richards ) 溝通應(yīng)當(dāng)言簡(jiǎn)意賅、詳略得當(dāng),別拖泥帶水。 5. 架構(gòu)決定性能 ( Randy Stafford ) 種瓜得瓜,種豆得豆,架構(gòu)設(shè)計(jì)也是一樣道理。 6. 分析客戶需求背后的意義 ( Einar Landre ) 抽絲剝繭,洞見(jiàn)癥結(jié)。不要被表面需求迷惑。 7. 起立發(fā)言 ( Udi Dahan ) 起立發(fā)言效果更好。 8. 故障終究會(huì)發(fā)生 ( Michael Nygard ) 應(yīng)該提前設(shè)計(jì)預(yù)防措施,限制故障。 9. 我們常常忽略了自己在談判 ( Michael Nygard ) 工程師應(yīng)該適時(shí)轉(zhuǎn)換角色,學(xué)習(xí)談判的技巧。 10. 量化需求 ( Keith Braithwaite ) 沒(méi)有規(guī)矩,不成方圓。 11. 一行代碼比五百行架構(gòu)說(shuō)明更有價(jià)值 ( Allison Randal ) 可工作的代碼才是目標(biāo),設(shè)計(jì)只是達(dá)成目標(biāo)手段。 12. 不存在放之四海皆準(zhǔn)的解決方案 ( Randy Stafford ) 軟件世界沒(méi)有萬(wàn)能鑰匙。 13. 提前關(guān)注性能問(wèn)題 ( Rebecca Parsons ) 盡早展開(kāi)性能測(cè)試。 14. 架構(gòu)設(shè)計(jì)要平衡兼顧多方需求 ( Randy Stafford ) 平衡兼顧項(xiàng)目的技術(shù)需求和相關(guān)各方的業(yè)務(wù)需求。 15. 草率提交任務(wù)是不負(fù)責(zé)任的行為 ( Niclas Nilsson ) 要設(shè)法杜絕開(kāi)發(fā)人員草率提交任務(wù)的念頭。 16. 不要在一棵樹(shù)上吊死 ( Keith Braithwaite ) 為客戶提供多樣化的解決方案。 17. 業(yè)務(wù)目標(biāo)至上 ( Dave Muirhead ) 技術(shù)決策不能脫離業(yè)務(wù)目標(biāo)和現(xiàn)實(shí)條件的約束。 18. 先確保解決方案簡(jiǎn)單可用,再考慮通用性和復(fù)用性 ( Kevlin Henney ) 19. 架構(gòu)師應(yīng)該親歷親為 ( John Davies ) 身先士卒才能贏得同事的信任。 20. 持續(xù)集成 ( David Bartlett ) 21. 避免進(jìn)度調(diào)整失誤 ( Norman Carnovale ) 不惜一切代價(jià)拒絕調(diào)整項(xiàng)目進(jìn)度的要求。 22. 取舍的藝術(shù) ( Mark Richards ) 架構(gòu)不可能滿足所有需求。 23. 打造數(shù)據(jù)庫(kù)堡壘 ( Dan Chak ) 一開(kāi)始就要定義好數(shù)據(jù)模型。 24. 重視不確定性 ( Kevlin Henney ) 推遲決策,建設(shè)性地利用不確定性。 25. 不要輕易放過(guò)不起眼的問(wèn)題 ( Dave Quick ) 別忘了溫水煮青蛙的故事。 26. 讓大家學(xué)會(huì)復(fù)用 ( Jeremy Meyer ) 重復(fù)利用已有資源,首先要改變大家的觀念。 27. 架構(gòu)里沒(méi)有大寫的“I ” ( Dave Quick ) 變讓自己變成自大狂。 28. 使用“ 一千英尺高” 的視圖 ( Erik Doernenburg ) 選擇合適的架構(gòu)視圖。 29. 先嘗試后決策 ( Erik Doernenburg ) 30. 掌握業(yè)務(wù)領(lǐng)域知識(shí) ( Mark Richards ) 31. 程序設(shè)計(jì)是一種設(shè)計(jì) ( Einar Landre ) 軟件開(kāi)發(fā)也分成設(shè)計(jì)和生產(chǎn)兩個(gè)階段。 32. 讓開(kāi)發(fā)人員自己做主 ( Philip Nelson ) 33. 時(shí)間改變一切 ( Philip Nelson ) 選擇值得投入精力的工作,別跟以前的工作過(guò)不去。 34. 設(shè)立軟件架構(gòu)專業(yè)為時(shí)尚早 ( Barry Hawkins ) 35. 控制項(xiàng)目規(guī)模 ( Dave Quick ) 36. 架構(gòu)師不是演員,是管家 ( Barry Hawkins ) 別忘了你的工作責(zé)任。 37. 軟件架構(gòu)的道德責(zé)任 ( Michael Nygard ) 架構(gòu)師的決定會(huì)影響許多人,務(wù)必慎重。 38. 摩天大廈不可伸縮 ( Michael Nygard ) 但軟件可以。 39. 混合開(kāi)發(fā)的時(shí)代已經(jīng)來(lái)臨 ( Edward Garson ) 40. 性能至上 (Craig Russell ) 41. 留意架構(gòu)圖里的空白區(qū)域 ( Michael Nygard ) 空白區(qū)域“充滿”了各種軟件和“硬件”。 42. 學(xué)習(xí)軟件專業(yè)的行話 ( Mark Richards ) 同行之間講行話方便交流。 43. 具體情境決定一切 ( Edward Garson ) 44. 侏儒、精靈、巫師和國(guó)王 ( Evan Cofsky ) 開(kāi)發(fā)團(tuán)隊(duì)不應(yīng)該同質(zhì)化。 45. 向建筑師學(xué)習(xí) ( Keith Braithwaite ) 借鑒建筑行業(yè)的經(jīng)驗(yàn)。 46. 避免重復(fù) ( Niclas Nilsson ) 47. 歡迎來(lái)到現(xiàn)實(shí)世界 ( Gregor Hohpe ) 現(xiàn)實(shí)世界比軟件世界復(fù)雜。 48. 仔細(xì)觀察,別試圖控制一切 ( Gregor Hohpe ) 49. 架構(gòu)師好比兩面神 ( David Bartlett ) 架構(gòu)師應(yīng)該像兩面神一樣,眼觀六路、耳聽(tīng)八方。 50. 架構(gòu)師應(yīng)關(guān)注邊界和接口 ( Einar Landre ) 尋找自然的邊界,分而治之。 51. 助力開(kāi)發(fā)團(tuán)隊(duì) ( Timothy High ) 優(yōu)秀團(tuán)隊(duì)是成功的保障,要盡量助力開(kāi)發(fā)團(tuán)隊(duì)。 52. 記錄決策理由 ( Timothy High ) 記錄架構(gòu)決策背后的理由,具有極高的投資回報(bào)價(jià)值。 53. 挑戰(zhàn)假設(shè), 尤其是你自己的 ( Timothy High ) 臆斷是事情搞砸的主要根源。務(wù)必要確保軟件基石堅(jiān)實(shí)可靠。 54. 分享知識(shí)和經(jīng)驗(yàn) ( Paul W. Homer ) 幫助周圍的人不斷改善,他們也會(huì)幫助我們發(fā)揮出全部的潛力。 55. 模式病 ( Chad La Vigne ) 不要讓一展設(shè)計(jì)模式功力的欲望,遮蔽了務(wù)實(shí)的真知。 56. 不要濫用架構(gòu)隱喻 ( David Ing ) 不要耽溺于系統(tǒng)隱喻之中,反讓它拖了后腿。 57. 關(guān)注應(yīng)用程序的支持和維護(hù) ( Mncedisi Kasper ) 應(yīng)用程序的支持和維護(hù),永遠(yuǎn)都不應(yīng)該是事后才考慮的事情。 58. 有舍才有得 ( Bill de hóra ) 珍惜需要權(quán)衡的時(shí)機(jī),遠(yuǎn)勝毫無(wú)約束和限制。 59. 原則、公理和類比勝于個(gè)人意見(jiàn)和口味( Michael Harmer ) 60. 從“ 可行走骨架” 開(kāi)始開(kāi)發(fā)應(yīng)用 ( Clint Shank ) 從“ 可行走骨架” 開(kāi)始,增量培育系統(tǒng)成長(zhǎng) 。 61. 數(shù)據(jù)是核心( Paul W. Homer ) 從“數(shù)據(jù)是核心”這個(gè)角度去認(rèn)識(shí)系統(tǒng),能大大降低理解復(fù)雜度 。 62. 確保簡(jiǎn)單問(wèn)題有簡(jiǎn)單的解 (Chad La Vigne ) 63. 架構(gòu)師首先是開(kāi)發(fā)人員 (Mike Brown ) 碰到麻煩時(shí),架構(gòu)師可不能只會(huì)干吹煙圈卻束手無(wú)策。 64. 根據(jù)投資回報(bào)率(ROI )進(jìn)行決策( George Malamidis ) 65. 一切軟件系統(tǒng)都是遺留系統(tǒng)( Dave Anderson ) 軟件很快便會(huì)過(guò)時(shí),修改維護(hù)無(wú)可避免。 66. 起碼要有兩個(gè)可選解決方案( Timothy High ) 67. 理解變化的影響 ( Doug Crawford ) 清楚認(rèn)識(shí)變化類型及其影響。 68. 你不能不了解硬件( Kamal Wickramanayake ) 硬件容量規(guī)劃,是和軟件架構(gòu)同等重要的事情。 69. 現(xiàn)在走捷徑,將來(lái)需付息( Scot Mcphee ) 及時(shí)還清技術(shù)債務(wù)。 70. 不要追求“完美”,“足夠好”就行( Greg Nyberg ) 避免過(guò)度設(shè)計(jì)。 71. 小心“好主意” ( Greg Nyberg ) 72. 內(nèi)容為王 ( Zubin Wadia ) 73. 對(duì)商業(yè)方,架構(gòu)師要避免憤世嫉俗( Chad La Vigne ) 74. 拉伸關(guān)鍵維度,發(fā)現(xiàn)設(shè)計(jì)中的不足( Stephen Jones ) 75. 架構(gòu)師要以自己的編程能力為依托( Mike Brown ) 76. 命名要恰如其分( Sam Gardiner ) 弄清楚要做的究竟是什么。 77. 穩(wěn)定的問(wèn)題可以獲得高質(zhì)量的解決方案( Sam Gardiner ) 78. 天道酬勤( Brian Hart ) 真正做好那些看似簡(jiǎn)單的任務(wù),堅(jiān)守承諾。 79. 對(duì)決策負(fù)責(zé)( Yi Zhou ) 80. 棄聰明,求質(zhì)樸( Eben Hewitt ) 81. 精心選擇有效技術(shù),絕不輕易拋棄( Chad La Vigne ) 82. 客戶的客戶才是你的客戶!( Eben Hewitt ) 83. 事物發(fā)展總會(huì)出人意料 ( Peter Gillard-Moss ) 設(shè)計(jì)是在不斷變化的世界中持續(xù)進(jìn)行探索試驗(yàn)的過(guò)程。 84. 選擇彼此間能和諧共處的框架( Eric Hawthorne ) 當(dāng)心“無(wú)所不能”型的框架。 85. 著重強(qiáng)調(diào)項(xiàng)目的商業(yè)價(jià)值( Yi Zhou ) 86. 不僅僅只控制代碼,也要控制數(shù)據(jù)( Chad La Vigne ) 87. 償還技術(shù)債務(wù) ( Burkhardt Hufnagel ) 在速度和架構(gòu)間進(jìn)行權(quán)衡,保持平衡。 88. 不要急于求解( Eben Hewitt ) 首先看看是否可以改變問(wèn)題。 89. 打造稱手的系統(tǒng)( Keith Braithwaite ) 90. 找到并留住富有激情的問(wèn)題解決者( Chad La Vigne ) 91. 軟件并非真實(shí)的存在 ( Chad La Vigne ) 虛擬世界中的軟件是柔韌可變的。 92. 學(xué)習(xí)新語(yǔ)言 ( Burkhardt Hufnagel ) 防止溝通不暢和誤解 。 93. 沒(méi)有永不過(guò)時(shí)的解決方案( Richard Monson-Haefel ) 94. 用戶接受度問(wèn)題( Norman Carnovale ) 減輕用戶接受度問(wèn)題帶來(lái)的風(fēng)險(xiǎn)。 95. 清湯的重要啟示 ( Eben Hewitt ) 軟件架構(gòu)設(shè)計(jì)需要不斷的精煉濃縮。 96. 對(duì)最終用戶而言,界面就是系統(tǒng)( Vinayak Hegde ) 97. 優(yōu)秀軟件不是構(gòu)建出來(lái)的,而是培育起來(lái)的( Bill de hóra ) 該文章在 2010/8/18 15:01:21 編輯過(guò) |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |