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