作者：零一

來源：前端印象

前言

大家好，我是零一，今天要跟大家聊聊開發(fā)流程中不起眼的環(huán)節(jié)——設(shè)計方案。你們可能沒聽過，也可能只是簡單得走過過場，別劃走，這非常重要！

在字節(jié)，我接觸到了更完善、更規(guī)范、更高效的開發(fā)流程：產(chǎn)品需求設(shè)計?=>?需求粗評?=>?做設(shè)計方案?=>?粗估時?=>?需求細評?=>?排期?=>?開發(fā)?=>?提測、修bug => code review =>?上線

其實在我未工作之前，大部分的流程我都聽說過或者在實習(xí)時經(jīng)歷過，比較少接觸的可能就是設(shè)計方案和code review了，這兩者分別是干什么的？

• 設(shè)計方案：在拿到需求后，寫一個文檔，來描述自己對于該需求的實現(xiàn)思路、模塊劃分等相關(guān)考慮的點，可供今后自己或他人查閱

• Code review：代碼提交合并前給mentor或leader檢查一下你的代碼，讓別人作為旁觀者來看你的代碼，集思廣益，完善代碼，發(fā)現(xiàn)未考慮到的邊界問題

說實話哈，啥設(shè)計方案啊，我第一次在一家小公司實習(xí)的時候，突然就被產(chǎn)品叫過去，花5分鐘給我闡述了一下下個版本他想要上的功能，緊接著立馬就問我：你看看大概需要多久？我的預(yù)估是5天后就上線，ok嗎？

我：？？？？？？？？？?（內(nèi)心os：我剛知道這個需求，我哪能那么快知道我得花多久做出來啊！你說5天就5天吧，反正我說6天也沒用）

太離譜了，可能很多小公司的現(xiàn)狀都是像我說的這樣吧！這樣真的很不好，版本快速迭代中摻雜著許多需求，而開發(fā)時間又比較緊張，只會讓開發(fā)想盡辦法怎么趕緊把功能實現(xiàn)，而不會去考慮任何性能問題，更別說讓你考慮邊界問題了。長期這樣下去，你會深深地體會到你處于一個無止境的項目快速迭代中，加班、通宵可能都是常事，哪還會有時間去學(xué)習(xí)新的知識或做自己愛做的事，也不會有多余的時間去關(guān)注自己接手的需求從開發(fā)到上線的整個生命周期線，不會定期去復(fù)盤，因此個人的項目經(jīng)驗、技術(shù)積累是很少的

之前也有小伙伴私聊過我類似的情況，我也是建議他最好能在一個有「自我學(xué)習(xí)」、「定期復(fù)盤反省」的環(huán)境中工作

大圣老師就是如此，記得他在有次直播中講到，他當年去360時，把「能留給自己充足的學(xué)習(xí)時間」作為他最在乎的因素，這樣真的非常好。大家也可以看看自己當前的現(xiàn)狀是否真的利于自己發(fā)展，然后做更長遠的打算。

好了，言歸正傳！

我們?yōu)槭裁匆獙懺O(shè)計方案呢？

目的是為了在真正開始敲代碼之前理清自己的思路，對需求有一個更清楚的認識，這樣就不至于在開始開發(fā)后邊寫代碼邊思考了，想必你們都有遇到在寫代碼時突然發(fā)現(xiàn)哪一模塊之前沒考慮到，然后對之前寫好的代碼的架構(gòu)進行調(diào)整，代碼進行抽離，這無疑是在降低開發(fā)效率。

另一點就是時間一久，突然這個功能出現(xiàn)了一個bug讓你去修復(fù)，你可能會對自己寫的代碼有些忘卻，此時找到之前自己寫的設(shè)計方案一看便知，這同樣也能作為新入職的小伙伴在熟悉現(xiàn)有代碼的重要資源！

對于第二點我深有感觸，到一個新部門總會接手1~2個祖?zhèn)黜椖看a，緊接著你就要閱讀他們的代碼邏輯，這是非常痛苦的，因為你根本不了解這些需求的背景，也不了解他人代碼完整的設(shè)計思路，這不跟抱著一本厚書在那硬啃一樣嘛！

image-20210725102004643

要是之前的人都寫過設(shè)計方案，你完全可以在看每個模塊的時候，找到相應(yīng)的文檔，這不事半功倍嘛~

那么如何寫設(shè)計方案呢？

整個方案大致分為4個部分：需求相關(guān)信息、方案調(diào)研、具體方案、其它

一、需求相關(guān)信息

作為一個開發(fā)工程師，一定要有工程師的精神，需要對自己所接手的需求有清晰的認識，這包括：負責這個需求的其它相關(guān)人員分別是誰（產(chǎn)品、測試、UI、后端等）、我這個需求的出現(xiàn)背景是什么、需求何時提測，何時上線...

格式如下：

一、需求相關(guān)信息需求背景：因為我們要做線下推廣，提高xxxxxxxxxPRD：文檔鏈接產(chǎn)品：小華UI：小明測試：小紅前端：零一服務(wù)端：小張聯(lián)調(diào)時間：2021.07.30提測時間：2021.07.31上線時間：2021.08.10

把這些內(nèi)容寫在設(shè)計方案的開頭，讓跟這個需求相關(guān)、不相關(guān)的人都能一目了然，如果遇到問題也可以立馬精準地找到相應(yīng)的人

二、方案調(diào)研

這一部分主要是需要我們在考慮功能實現(xiàn)的技術(shù)選型時，對比很多不同的方案，綜合考慮每一種方案的優(yōu)缺點，可以適當?shù)厝∩岷透倪M，形成一套適合當前場景的技術(shù)方案。

舉個比較簡單的例子吧，假設(shè)你此次接的需求中有一個復(fù)雜的動畫要實現(xiàn)，那么你以下這幾種考慮的方向

• 以前我有沒有做過類似的動畫，可以借鑒的？

• 公司內(nèi)部有沒有什么現(xiàn)成的庫或者代碼能用？

• 業(yè)界有沒有現(xiàn)成的庫或者比較不錯的實現(xiàn)思路？

• 如果不用別的庫，用原生實現(xiàn)，我會怎么做？有沒有什么兼容性等其它問題？

在了解了這四種場景以后，我們此時需要思考別人的方案和我自己的方案哪一個更好，優(yōu)缺點分別是什么？別人的方案是否適用于我們當前的場景？在綜合考慮了眾多因素后，我們選擇一套相對比較靠譜的方案用于實行。

通過以上幾個步驟來支撐我們接下來敲出來的代碼的可靠性與質(zhì)量！

三、具體方案

這部分是最重要的了，它幾乎涵蓋了你所有需要思考的東西：業(yè)務(wù)的完整流程、數(shù)據(jù)結(jié)構(gòu)的設(shè)計、關(guān)鍵功能的邏輯描述、異常的處理、安全性、性能、與現(xiàn)有業(yè)務(wù)的耦合情況、組件復(fù)用

起碼要保證其他人以及你自己，在看到具體的方案介紹時，可以很清楚地明白你的設(shè)計思路、寫代碼的思路、模塊的劃分。你可以用任何形式去表達你的思路，例如偽代碼、流程圖或者純文字等等

簡單演示一下：

「流程圖」

流程圖的設(shè)計能讓你對自己的需求有更清楚的了解，也能讓他人對這個需求有一個直觀的認識

「偽代碼」

function?getSomeData()?{let?data;?if(無緩存)?{//?請求數(shù)據(jù)if(請求異常)?//?展示錯誤頁面;data?=?請求到的數(shù)據(jù);}//?展示頁面 }

偽代碼可以在你不寫具體代碼實現(xiàn)前，展示大致的編碼思路，那么在大家一起過你的設(shè)計方案時，就可以很清楚得知道你的代碼想怎么實現(xiàn)，因為是偽代碼，所以非技術(shù)的同學(xué)說不定也能看懂，然后給你提點意見呢！

「模塊劃分」

模塊的劃分也是考驗?zāi)慵軜?gòu)設(shè)計的一個點，你需要考慮清楚你的代碼中，哪些需要單獨抽離出來作為一個單獨的模塊，哪些可以作為公共組件，哪些是跟業(yè)務(wù)高耦合的

「用例圖」

用例圖的話，能幫助你整理需求中每一個大大小小的場景，這個光靠腦子想可能沒有太大的作用，當你列出來時，你可能會發(fā)現(xiàn)這個流程好像少了點什么東西，也就是有助于你考慮更全，關(guān)注到一些犄角旮旯的邊界。插播個小彩蛋，我有個前端同事寫用例寫的特別好，有一次leader調(diào)侃說他這個寫的也太太太詳細了，每一處考慮得都特別周全，甚至都可以直接原封不動得給測試當測試用例了，hhhh

我所列舉的例子都比較簡單，大家根據(jù)自己實際情況進行操作就好。

還有一些別的就是，你還需要考慮一下你的某些接口需不需要考慮安全問題，比如點擊submit會增加抽獎次數(shù)，那不會被別人惡意偽造一些信息進行刷抽獎次數(shù)呢？還有你的頁面會不會存在一些性能問題？如果以后要在這個需求上擴展別的功能，你覺得你的代碼可擴展性如何？當然，你要考慮的肯定遠不止這些，希望每個工程師都能對自己的方案考慮周全，做到精益求精，這樣才是一個合格的工程師！

四、其它

最后一部分完全可以留給你自己自由發(fā)揮，可以記錄下與這個需求相關(guān)的一切，我個人覺得可以寫的有這些：

• 你在寫設(shè)計方案時遇到的問題以及解決辦法

• 你的代碼上線以后，用戶的反饋如何，如果好，好在哪里；如果不好，到底是哪里出了問題，該如何解決

• 你在方案調(diào)研時，有沒有發(fā)現(xiàn)別人的方案哪里做的不好，或者有哪些值得學(xué)習(xí)的地方

• 在此次整個開發(fā)流程中，有覺得哪個流程不太好的（低效、無用的溝通等等），可以記錄在此，然后找相關(guān)人員討論改進

• more...

總之，這里隨心所欲發(fā)揮

實踐感受

一開始讓我寫設(shè)計方案時我略微有些抗拒，就心里想著為啥寫個代碼還要先寫文檔，這不是在增加我的工作量嘛？

后來leader告訴我，寫設(shè)計方案的時間不會算在我的開發(fā)時間內(nèi)的，而是在開發(fā)時間之前，給我3~4天專門用來寫設(shè)計方案（內(nèi)心os：woc？這么爽！我寫！我寫！），這不香的要死嘛，于是我也就開始嘗試寫設(shè)計方案了

在寫的過程中發(fā)現(xiàn)，流程上我可能會發(fā)現(xiàn)一些同事們都沒有考慮到的問題，這是站在開發(fā)的視角去看的，所以產(chǎn)品同學(xué)難免會遺漏一些點；而在case的梳理上我又偶爾會發(fā)現(xiàn)大家都沒有考慮到的邊界問題，可能是真的大家都沒考慮到，也有可能是我的想法比較獨特，但這都ok，在后面所有相關(guān)人員統(tǒng)一過我的設(shè)計方案的時候可以一起討論出個對錯。嗯，這些都是光憑腦袋想不一定能想到的，或者哪個瞬間想到了卻來不及記錄，到了開發(fā)的時候又給忘了！

等我設(shè)計方案寫完以后，相關(guān)人員會約一個時間一起聽我講一遍我的設(shè)計方案，不同崗位的同學(xué)有不同的視角去看問題，每個人也有不同的想法，所以這里能暴露出很多問題，也能把很多不ok的點處理掉，例如我的leader經(jīng)驗比較豐富，每次過設(shè)計方案時他都會提醒我哪一塊兒地方可能會存在安全問題，記得考慮一下。

再后來測試同學(xué)會整理一些測試用例，拉大家case評審，你之前做過了設(shè)計方案，對自己的需求非常熟悉了，那么在測試過你的需求的case時你會更加的明白，也許測試考慮到了你沒考慮到的點，也許是他遺漏了某些點而你考慮到了，這些都是可以互補的。

完成了以上內(nèi)容，基本上我寫代碼的思路就通了，確實也節(jié)省了不少的時間！等我開發(fā)完以后，還會再自測一遍，怎么測？直接拿我設(shè)計方案和測試給出來的測試用例對照著自測就好啦，總不能說你自己這里都還沒跑通就拿過去給測試測吧？

總之收獲還是很大，但設(shè)計方案的實施還是需要有一個不那么短的開發(fā)周期的，那種需求剛提，5天上線的情況哪有時間給你寫設(shè)計方案啊，就更別說考慮這么多東西了，你自己個人也很難沉淀下東西

不過哦~我突然又發(fā)現(xiàn)了寫設(shè)計方案的另外一個隱藏好處！我們的簡歷上不是會寫上自己過往項目經(jīng)驗和工作經(jīng)歷嘛，這些都跟我們做過的項目需求緊密相關(guān)，你如果之前每個需求都寫設(shè)計方案，那么寫簡歷還用愁嘛，妥妥的篩選一下 + 復(fù)制粘貼啊

往期推薦

對象存儲，為什么那么火？

高性能開發(fā)，別點，發(fā)際線要緊！

什么是自動駕駛？

被 AI?算法“監(jiān)控”的打工人

點分享

點收藏

點點贊

點在看

總結(jié)

以上是生活随笔為你收集整理的设计方案，拿来吧你！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。