擼代碼前先寫下設(shè)計方案

擼代碼前，先寫下設(shè)計方案什么是設(shè)計方案？解決一個復雜的問題，一般要經(jīng)過幾個不同的步驟。其中最重要的是問題發(fā)現(xiàn)階段，分析階段，和構(gòu)建交付階段。在分析階段，工程師們研究哪些方案可以解決客戶需求。一個設(shè)計方案，不代表已經(jīng)有了可以上線的代碼，雖然在驗證方案的過程中，有可能會寫一些代碼。設(shè)計方案，是分析階段的成果，它告訴大家：真正需要解決的問題是什么？為什么要現(xiàn)在解決？如何解決？為什么要寫設(shè)計方案？有始有終的團隊，在每個階段結(jié)束的時候，會審視目標是否達成。對于分析階段，他們會查看設(shè)計方案的好壞，來鑒別工作成果。而有些團隊，射出去的箭，還沒看是否擊中大雁，就迫不及待朝大雁跑去。沒寫設(shè)計方案，就擼代碼，一是溝通效率低，二是容易在項目后期發(fā)現(xiàn)設(shè)計上的缺陷而進入令人焦慮的趕工模式。

寫下來一次，隨時隨地用

口頭交流，眉飛色舞，固然爽快，可是口說無憑，什么也留不下來。結(jié)果，嘴皮子磨爛，一遍一遍得給不同的人講你們的方案。這里我們要學習Java的設(shè)計理念，寫一次，哪哪都能用。把設(shè)計方案寫下來，有助于和團隊里不同職能的人溝通：產(chǎn)品經(jīng)理：保證對問題一致的理解，并且知道方案的優(yōu)勢及其劣勢，不會到后期發(fā)現(xiàn)劣勢而導致意外項目經(jīng)理：闡明方案所做的假設(shè)以及可能出現(xiàn)的風險，幫助在項目執(zhí)行過程中追蹤這些風險團隊成員和其他團隊負責人:收集大家對方案的看法，接受大家對所選方案的挑戰(zhàn)，保證你的方案凝聚了各種思維的光輝老板：當成匯報，幫助老板看到你們的成果，并且給他提供一個管中窺豹的機會，讓他看到你們整個團隊的合作質(zhì)量質(zhì)量工程師：說明你們要構(gòu)造的是什么，幫助他們寫出好的測試團隊的新人：幫助新人獲取知識，所有的設(shè)計方案積累起來，就是一部團隊發(fā)展史，幫助新人了解大廈是如何一層一層建起來的

真正的學習來自于清單檢查

曾有人問一位智者，你是如何成功的？智者答，正確的決定。人又問，如何做正確的決定？智者再答，經(jīng)驗。人仍不解，如何獲取經(jīng)驗？智者說，錯誤的決定。

犯錯，大家都難以避免，而有的人錯了再錯。真正的學習來自于錯誤到經(jīng)驗的轉(zhuǎn)化。寫下來你的設(shè)計方案，按照積累的清單，逐條檢查，能保證方案質(zhì)量，雖然不能保證不犯新錯誤，但至少同樣的錯誤不犯兩遍。如果你什么都不寫，只是口頭說說，就達不到清單檢查的效果。

其實清單檢查不僅僅適用于設(shè)計方案，任何形式的寫作都可以從中受益。秋葉在他的《寫作七堂課》里也介紹了寫作清單的重要性。如何寫一個好的設(shè)計方案？不幸的家庭有各種不幸的理由，而幸福的家庭，都是相同的。好的設(shè)計方案里應該都包含下面的這幾點。如果你熟悉JDK里JEP(javaenhancementproposal)，你會發(fā)現(xiàn)下面的這些關(guān)鍵點在JEP里也能找到，我也是受了JEP的啟發(fā)。

目標

解釋你們最終想要獲得的成果。目標的缺失，或者模糊的目標，說明沒有真正看到問題的本質(zhì)，沒有真正領(lǐng)會用戶的需求。這樣做的風險是解決一個根本不存在的問題，竹籃打水一場空。

動機

動機是對目標進一步的解釋，特別是對現(xiàn)狀的解釋。你之所以有目標，是因為你不滿意當下，在現(xiàn)狀和目標之間有差距。這個差距是什么？為什么我們現(xiàn)在必須縮短這個差距？

描述

動機回答的是為什么，描述回答的是如何做。這里要解釋如何一步一步的實現(xiàn)解決方案。一個準確完成的描述會告訴讀者你問題的復雜度。

風險

你的方案可能無法考慮到所有的限制因素。就像分布式系統(tǒng)里的CAP理論一樣，網(wǎng)線拔掉的時候，是各自為政，還是坐等網(wǎng)線插好。解釋方案的限制因素，打好預防針，防止驚嚇。

測試計劃

如果知道怎么測，那么表明你知道成功是什么樣子。相反，如果你不知道怎么測，表明你沒有想清楚你究竟要的是什么。

替換方案

上面解釋的都是被選中的方案。不要小瞧那些被砍掉的方案。寫下那些沒有被采納的，可以證明你們想的足夠全面，也可以解釋你們是如何做決定的。所謂的決策，歸根揭底，就是做取舍的方式。結(jié)語新冠疫情改變了我們工作的方式，越來越多的遠程