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