大家好，我是魚皮，今天給大家分享一個開發小經驗。
很多沒有實際工作過的同學，可能都會認為程序員的工作只有寫代碼 + 和產品經理 “拉扯”，也會習慣性地用代碼量來評價一個程序員的工作強度和等級，以為碼字如飛、每月能寫個幾萬行代碼的程序員就是大佬。
我以前也是這么認為的，直到我正式進入企業工作，才發現真的不是這么一回事兒！高端的同學總是用最簡短精妙的代碼來解決問題。包括我認識的很多高職級大佬（被外界稱為 “架構師”），他們的平均代碼量都很少、甚至有些已經完全不寫代碼了。
那他們的工作都是干啥呢？
其中最常見的工作就是 設計 ，這里的設計不是指 draw a picture 畫畫設計稿，而是根據真實的業務需求去設計系統的整體架構、或者設計需求的解決方案、設計整個系統的划分、資源的協調調度等。
通過這點，也側面反映出了設計的重要性，代碼只是把我們的思想、我們的設計表述出來的一種介質（或者說是工具）罷了。
也許我們的工作沒有達到架構師的高度，但在我們做需求的過程時，一定進行設計：先理清楚業務邏輯，想好怎么寫代碼，再根據設計去具體寫代碼實現（類似翻譯的過程）。
我剛進騰訊實習的時候，導師給我安排了一個很大的工作 —— 重構老系統為新框架。我當時覺得很簡單，不就是把框架 A 換成框架 B 么？業務邏輯基本都不用動，分分鍾搞定好吧！於是在排期的時候信誓旦旦地跟我導師說：3 天完成。
我導師只是笑了笑：年輕人不要太自信！慢慢來吧。
結果你猜怎么着？那個需求我做了整整一個多月。。。就是因為沒有設計好怎么去做、也沒有調研框架 A、框架 B 的差異性，直接上手去換框架、寫代碼，導致到處都是報錯，甚至影響了業務邏輯。
還有幾次，我以為需求很簡單，想都沒想就去寫代碼了，結果在寫代碼的過程中發現了大問題，就像走迷宮走到了死胡同一樣無力回天。如果先做好設計，有了清晰的路線和規划，再去寫代碼，出現延期、返工的概率就會大大降低。
所以設計有多重要就不言而喻了。
那應該怎么做設計呢？設計分為很多種，比如系統設計、架構設計、詳細設計等。每個展開去說都能扯個幾萬字，這里我就挑 詳細設計 小講一下。
所謂詳細設計，顧名思義，就是很詳細的設計。
比如業務流程具體是怎樣的、有哪些步驟？某個算法具體怎么實現等？
正好上周在 星球 中直播帶大家做項目，需求是開發一個用戶注冊功能的后台。我就拿這個注冊功能的詳細設計來舉例子吧，如圖：
從上到下看一遍你會發現，一個小小的注冊功能竟然有那么多要考慮的地方，各種各樣的校驗。如果你不做設計、直接上手寫代碼，那么會不會漏掉一些校驗、搞錯關鍵步驟，導致整個系統出問題呢？后面發現問題再去改代碼，可就麻煩多了（要反復上線）。
所以在開發需求、尤其是包含復雜業務邏輯的需求時，不要想當然，直接去寫代碼了。而是可以像我上面舉的例子一樣先設計一下、想清楚怎么寫代碼，再去按照設計寫代碼就很簡單了~
經常有同學問我怎么提高業務思維、為什么我看到很多系統都能很快地想到實現方案，其實就是因為平時做任何需求的時候，我都會思考、在心里做設計。我也強烈建議大家這么做，腦袋越用越靈嘛。
所以我也會在星球直播帶大家做項目過程中多帶大家分析問題、思考和設計方案，而不止是寫代碼本身，相信這樣會給大家帶來更大的幫助。
以上就是本期分享，最后也歡迎大家加入魚皮的 編程學習圈子 (dogyupi.com) ，和幾千名小伙伴們一起交流學習~