1.?行為準(zhǔn)則

2.?設(shè)計(jì)過程的螺旋式上升

文章來源地址http://www.zghlxwxcb.cn/news/detail-760140.html

2.1.?圓錐體中的箭頭進(jìn)一步螺旋式上升

2.2.?你現(xiàn)在更確定你理解了問題空間

2.3.?你的原型為你的解決方案提供了越來越多的信心

2.4.?隨著每一次迭代，設(shè)計(jì)文檔變得更加清晰和詳細(xì)

3.?技術(shù)設(shè)計(jì)流程

3.1.?當(dāng)被要求對系統(tǒng)進(jìn)行修改時(shí)，大多數(shù)入門級工程師會直接跳入編碼環(huán)節(jié)

3.2.?技術(shù)設(shè)計(jì)流程可以幫助每個(gè)人就某項(xiàng)大型變更的設(shè)計(jì)達(dá)成一致

3.3.?正確地完成、參與和領(lǐng)導(dǎo)技術(shù)設(shè)計(jì)工作是很有意義并且有價(jià)值的

3.4.?單獨(dú)的深入思考和協(xié)作的小組討論

3.4.1.?研究、頭腦風(fēng)暴和寫作構(gòu)成了深度工作

3.4.1.1.?外界干擾是深度工作的“殺手”

3.4.1.2.?避免所有的交流方式

3.4.1.2.1.?關(guān)閉聊天

3.4.1.2.2.?關(guān)閉電子郵件

3.4.1.2.3.?禁用電話通知

3.4.1.2.4.?換個(gè)地方坐

3.4.2.?設(shè)計(jì)討論和對設(shè)計(jì)文件的評論構(gòu)成了合作的部分

3.4.2.1.?有形產(chǎn)出是一份設(shè)計(jì)文檔

4.?設(shè)計(jì)的思考

4.1.?設(shè)計(jì)漏斗的基礎(chǔ)是從探索開始的

4.1.1.?在制定設(shè)計(jì)方案之前，你需要了解問題空間和需求

4.1.2.?探索既是一項(xiàng)個(gè)人運(yùn)動，也是一項(xiàng)團(tuán)隊(duì)運(yùn)動

4.2.?定義問題

4.2.1.?首要任務(wù)是定義和理解要解決的那個(gè)（或那些）問題

4.2.2.?需要了解問題的邊界，以便知道如何解決它，并避免構(gòu)建錯(cuò)誤的東西

4.2.3.?用你自己的語言向利益相關(guān)者重述問題，詢問你的理解是否與他們一致

4.2.3.1.?如果有一個(gè)以上的問題，詢問哪些問題是最優(yōu)先的

4.2.4.?完善的問題描述將導(dǎo)致一份與原來截然不同的解決方案，工程師可聚焦在問題上并列出優(yōu)先事項(xiàng)

4.3.?著手調(diào)查

4.3.1.?不要從問題定義直接就過渡到“最終”設(shè)計(jì)

4.3.2.?考慮相關(guān)的研究、替代的解決方案，以及權(quán)衡各方案的利弊

4.3.3.?你提出的設(shè)計(jì)不應(yīng)該是你的第一個(gè)想法，而應(yīng)該是你若干想法中最好的那個(gè)

4.3.4.?網(wǎng)上有大量的資源，看看別人是如何解決類似問題的

4.3.5.?行業(yè)大會是另一種可供檢查的資源，幻燈片或錄音通常會在網(wǎng)絡(luò)上公布

4.3.6.?不要忘記學(xué)術(shù)研究，利用論文末尾的參考文獻(xiàn)部分來尋找更多的閱讀材料

4.3.7.?與你正在探索的問題領(lǐng)域的專家交流

4.3.7.1.?注意與外人交流時(shí)不要泄露公司的專有信息

4.3.8.?批判性地思考

4.3.8.1.?一個(gè)特別常見的錯(cuò)誤做法是將一個(gè)與你的問題相似但不完全相同的解決方案全盤復(fù)制

4.3.8.2.?你的問題不是谷歌的問題（即使你在為谷歌工作），盡管它們看起來很相似

4.4.?進(jìn)行實(shí)驗(yàn)

4.4.1.?實(shí)驗(yàn)會讓你對自己的想法增長信心、暴露出設(shè)計(jì)上的權(quán)衡，并澄清問題空間

4.4.2.?不要迷戀你的實(shí)驗(yàn)性代碼

4.4.2.1.?你要盡可能快地學(xué)習(xí)到更多的東西

4.5.?給些時(shí)間

4.5.1.?好的設(shè)計(jì)需要創(chuàng)造力

4.5.2.?設(shè)計(jì)需要深入思考

4.5.3.?你不會在你鎖定的整段時(shí)間內(nèi)進(jìn)行“設(shè)計(jì)”

4.5.3.1.?你的大腦需要時(shí)間來放松

4.5.3.2.?休息一下，給自己一個(gè)呼吸的空間

4.5.3.3.?允許你的思想放松和游蕩

4.5.3.4.?去散步、泡茶、閱讀、寫作、畫畫

4.5.4.?設(shè)計(jì)是一種每天24小時(shí)都在進(jìn)行的工作，所以要有耐心

4.5.4.1.?你的大腦總在醞釀著各種想法，創(chuàng)意想法會在一天內(nèi)隨機(jī)出現(xiàn)（甚至在你睡覺的時(shí)候）

4.5.5.?輕松的設(shè)計(jì)方法并不意味著你可以永遠(yuǎn)這樣做

4.5.5.1.?設(shè)計(jì)尖峰(design spike)是管理創(chuàng)造性工作和可預(yù)測的交付之間的緊張關(guān)系的一個(gè)好方法

4.5.5.1.1.?尖峰是極限編程(extreme programming，XP)的術(shù)語，指有時(shí)間限制的調(diào)查

5.?使用設(shè)計(jì)文檔模板

5.1.?概要

5.2.?現(xiàn)狀與背景

5.3.?變更的目的

5.3.1.?軟件團(tuán)隊(duì)往往擁有超過他們能同時(shí)應(yīng)對的極限的項(xiàng)目

5.4.?需求

5.4.1.?面向用戶的需求

5.4.1.1.?從用戶的角度定義了變更的性質(zhì)

5.4.2.?技術(shù)需求

5.4.2.1.?包括解決方案必須滿足的硬性需求

5.4.2.2.?技術(shù)需求通常是由互操作性問題或嚴(yán)格的內(nèi)部準(zhǔn)則引起的

5.4.2.3.?服務(wù)水平目標(biāo)也可以定義在這里

5.4.3.?安全性與合規(guī)性需求

5.4.3.1.?確保安全性的需求得到明確的討論

5.4.3.2.?數(shù)據(jù)保留和訪問政策通常包括在這里

5.4.4.?其他

5.5.?潛在的解決方案

5.5.1.?撰寫這部分內(nèi)容對你和讀者來說都是一種工具

5.5.2.?目的是迫使你不僅要思考你的第一個(gè)想法，還要思考其他的想法和它們之間的利弊

5.5.3.?描述合理的替代方案，以及你為什么拒絕它們

5.5.4.?描述潛在的解決方案將預(yù)先解決“為什么不做××？”的評論

5.5.5.?如果你因?yàn)殄e(cuò)誤的原因而否定了某個(gè)解決方案，評論者就有機(jī)會發(fā)現(xiàn)其中的過錯(cuò)，甚至可以找出你沒有考慮過的替代方案

5.6.?建議的解決方案

5.6.1.?描述你所確定采用的解決方案

5.6.2.?要比概要中簡短的描述更加詳細(xì)，并且可能包含突出變化的圖示

5.6.3.?如果你的建議包括多個(gè)階段，請解釋該解決方案是如何從一個(gè)階段發(fā)展到另一個(gè)階段的

5.7.?設(shè)計(jì)與架構(gòu)

5.7.1.?系統(tǒng)構(gòu)成圖

5.7.2.?UI/UX變更點(diǎn)

5.7.3.?代碼變更點(diǎn)

5.7.4.?API變更點(diǎn)

5.7.5.?持久層變更點(diǎn)

5.8.?測試計(jì)劃

5.8.1.?不要事先定義每項(xiàng)測試，而是去解釋你計(jì)劃如何去驗(yàn)證你的變更

5.9.?發(fā)布計(jì)劃

5.9.1.?描述你將使用的策略，以避免復(fù)雜的部署順序需求

5.9.2.?記錄你需要設(shè)置的特性開關(guān)，以控制新版本的展開

5.9.3.?想一想你將如何發(fā)現(xiàn)你發(fā)布的變更是否生效

5.9.4.?在發(fā)現(xiàn)問題時(shí)你將如何回滾

5.10.?⑩遺留的問題

5.10.1.?明確地列出設(shè)計(jì)中尚未回答的緊迫問題

5.10.2.?征求讀者意見的一種好方法，并說明你的“已知的未知”

5.11.?⑾附錄

5.11.1.?加入額外的令人感興趣的細(xì)節(jié)

5.11.2.?添加相關(guān)工作參考

5.11.3.?進(jìn)一步閱讀資料

到了這里，關(guān)于讀程序員的README筆記13_技術(shù)設(shè)計(jì)流程（上）的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！