設計方案，寫了才知道有多香

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

在字節，我接觸到了更完善、更規范、更高效的開發流程：產品需求設計 => 需求粗評 => 做設計方案 => 粗估時 => 需求細評 => 排期 => 開發 => 提測、修bug => code review => 上線

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

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

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

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

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

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

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

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

好了，言歸正傳！

我們為什么要寫設計方案呢？

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

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

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

image-20210725102004643

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

那么如何寫設計方案呢？

整個方案大致分為4個部分：需求相關信息、方案調研、具體方案、其它

一、需求相關信息

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

格式如下：

一、需求相關信息 需求背景：因為我們要做線下推廣，提高xxxxxxxxx PRD：文檔鏈接 產品：小華 UI：小明 測試：小紅 前端：零一 服務端：小張 聯調時間：2021.07.30 提測時間：2021.07.31 上線時間：2021.08.10

1

2

3

4

5

6

7

8

9

10

11

12

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

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-gcgYAzSJ-1629268348043)(https://mmbiz.qpic.cn/mmbiz_png/lgHVurTfTcyTg1OlvoiaicMNktCUib3myEEhWqA50Z9JDhkcTmiaOticKgHweWq36zOcW1Ww79Z3J56jvMtsMlSmB4g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)]

二、方案調研

這一部分主要是需要我們在考慮功能實現的技術選型時，對比很多不同的方案，綜合考慮每一種方案的優缺點，可以適當地取舍和改進，形成一套適合當前場景的技術方案。

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

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

公司內部有沒有什么現成的庫或者代碼能用？

業界有沒有現成的庫或者比較不錯的實現思路？

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

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

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

三、具體方案

這部分是最重要的了，它幾乎涵蓋了你所有需要思考的東西：業務的完整流程、數據結構的設計、關鍵功能的邏輯描述、異常的處理、安全性、性能、與現有業務的耦合情況、組件復用

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

簡單演示一下：

「流程圖」

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

「偽代碼」

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

1

2

3

4

5

6

7

8

9

10

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

「模塊劃分」

模塊的劃分也是考驗你架構設計的一個點，你需要考慮清楚你的代碼中，哪些需要單獨抽離出來作為一個單獨的模塊，哪些可以作為公共組件，哪些是跟業務高耦合的

「用例圖」

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

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

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

四、其它

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

你在寫設計方案時遇到的問題以及解決辦法

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

你在方案調研時，有沒有發現別人的方案哪里做的不好，或者有哪些值得學習的地方

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

more…

總之，這里隨心所欲發揮

實踐感受

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

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

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

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

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

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

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

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

我是零一，希望本文對你們有所幫助，對于設計方案的看法，你們可以在評論區發表~ 也歡迎訪問我的個人博客

web前端

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。