大家好，我是魚皮，今天給大家分享一個開發小經驗。

很多沒有實際工作過的同學，可能都會認為程序員的工作只有寫代碼 + 和產品經理 “拉扯”，也會習慣性地用代碼量來評價一個程序員的工作強度和等級，以為碼字如飛、每月能寫個幾萬行代碼的程序員就是大佬。

我以前也是這么認為的，直到我正式進入企業工作，才發現真的不是這么一回事兒！高端的同學總是用最簡短精妙的代碼來解決問題。包括我認識的很多高職級大佬（被外界稱為 “架構師”），他們的平均代碼量都很少、甚至有些已經完全不寫代碼了。

那他們的工作都是干啥呢？

其中最常見的工作就是 設計 ，這里的設計不是指 draw a picture 畫畫設計稿，而是根據真實的業務需求去設計系統的整體架構、或者設計需求的解決方案、設計整個系統的劃分、資源的協調調度等。

通過這點，也側面反映出了設計的重要性，代碼只是把我們的思想、我們的設計表述出來的一種介質（或者說是工具）罷了。

也許我們的工作沒有達到架構師的高度，但在我們做需求的過程時，一定進行設計：先理清楚業務邏輯，想好怎么寫代碼，再根據設計去具體寫代碼實現（類似翻譯的過程）。

我剛進騰訊實習的時候，導師給我安排了一個很大的工作 —— 重構老系統為新框架。我當時覺得很簡單，不就是把框架 A 換成框架 B 么？業務邏輯基本都不用動，分分鐘搞定好吧！于是在排期的時候信誓旦旦地跟我導師說：3 天完成。

我導師只是笑了笑：年輕人不要太自信！慢慢來吧。

結果你猜怎么著？那個需求我做了整整一個多月。。。就是因為沒有設計好怎么去做、也沒有調研框架 A、框架 B 的差異性，直接上手去換框架、寫代碼，導致到處都是報錯，甚至影響了業務邏輯。

還有幾次，我以為需求很簡單，想都沒想就去寫代碼了，結果在寫代碼的過程中發現了大問題，就像走迷宮走到了死胡同一樣無力回天。如果先做好設計，有了清晰的路線和規劃，再去寫代碼，出現延期、返工的概率就會大大降低。

所以設計有多重要就不言而喻了。

那應該怎么做設計呢？設計分為很多種，比如系統設計、架構設計、詳細設計等。每個展開去說都能扯個幾萬字，這里我就挑 詳細設計 小講一下。

所謂詳細設計，顧名思義，就是很詳細的設計。

比如業務流程具體是怎樣的、有哪些步驟？某個算法具體怎么實現等？

正好上周在 星球 中直播帶大家做項目，需求是開發一個用戶注冊功能的后臺。我就拿這個注冊功能的詳細設計來舉例子吧，如圖：

從上到下看一遍你會發現，一個小小的注冊功能竟然有那么多要考慮的地方，各種各樣的校驗。如果你不做設計、直接上手寫代碼，那么會不會漏掉一些校驗、搞錯關鍵步驟，導致整個系統出問題呢？后面發現問題再去改代碼，可就麻煩多了（要反復上線）。

所以在開發需求、尤其是包含復雜業務邏輯的需求時，不要想當然，直接去寫代碼了。而是可以像我上面舉的例子一樣先設計一下、想清楚怎么寫代碼，再去按照設計寫代碼就很簡單了~

經常有同學問我怎么提高業務思維、為什么我看到很多系統都能很快地想到實現方案，其實就是因為平時做任何需求的時候，我都會思考、在心里做設計。我也強烈建議大家這么做，腦袋越用越靈嘛。

所以我也會在星球直播帶大家做項目過程中多帶大家分析問題、思考和設計方案，而不止是寫代碼本身，相信這樣會給大家帶來更大的幫助。

---

以上就是本期分享，最后也歡迎大家加入魚皮的 編程學習圈子 (dogyupi.com) ，和幾千名小伙伴們一起交流學習~

總結

以上是生活随笔為你收集整理的别以为程序员的工作就是写代码的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。