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