大家好，我叫謝偉偿短，是一名程序員。
最近狀態(tài)不是很好馋没，輸出少了...
本節(jié)主題：如何梳理代碼邏輯
在日常工作中昔逗，作為初中級程序員，大部分的工作是在實現(xiàn)業(yè)務邏輯篷朵，但有可能整個項目的代碼勾怒，你不是第一個接手的婆排，即代碼結構不是你設計，前期的需求討論你也沒有參與笔链，最常見的情況是段只，你接手的是半成品的項目。
這個時候需要你不斷的完成需求鉴扫。
那么如何快速的熟悉的項目赞枕，之前我講過的一個方法是：使用相同的技術棧實現(xiàn)一個類似的項目。
上述的方法可以讓你快速的熟練技術棧坪创，比如技術選型炕婶，比如項目的組織，比如代碼的風格莱预∧啵可以快速讓你避免對技術的不適感。
但是存在什么問題依沮？
即：你熟練了技術棧涯贞，但是對業(yè)務實現(xiàn)并沒有實質性的幫助。怎么說危喉？你借用相同的技術棧宋渔，需求的提出是你自己，需求的實現(xiàn)也是你自己姥饰，這樣的總體實現(xiàn)起來傻谁，當然比較容易，你理所當然知道如何實現(xiàn)需求列粪。
現(xiàn)實中的需求呢审磁，常常是變動的，特別是創(chuàng)業(yè)公司岂座，為了賣出產(chǎn)品态蒂，可能會在項目內完成一些客戶提出的滿足自己需要的需求，需要你定制费什，這個時候的需求來自客戶钾恢，客戶的需求可不管你的實現(xiàn)的難度和合理性。
這個時候鸳址，需要你對一個或者多個項目的實現(xiàn)細節(jié)比較熟悉瘩蚪，不然來的需求，你可能會不太清楚實現(xiàn)起來可能會遇到什么樣的問題稿黍、實現(xiàn)的難度是什么疹瘦。當然這些問題，隨著你經(jīng)驗的越來越豐富巡球，你會越來越熟練言沐，越來會知道實現(xiàn)中的問題邓嘹，以及時間的評估。
本節(jié)险胰，講述的是你經(jīng)驗不是那么足汹押，如何快速的了解的項目并且快速實現(xiàn)需求。
1. 一個工具：思維導圖
這個工具起便，有人用來梳理想法棚贾、有人用來拆分思維觀點...
有手寫的，也有借助APP等客戶端設備的缨睡。
當初我用這個工具的想法很簡單鸟悴，即梳理想法，比如想寫一篇文章奖年，初期我會借用思維導圖來梳理角度细诸，列舉文章的主要方面，比如先寫什么陋守，后寫什么震贵，想表達什么，用什么樣的實例來輔助證明我的觀點等水评。
前期也還糾結于如何手繪思維導圖猩系，把時間都糾結在繪制好看的思維導圖層面，現(xiàn)在回頭看看有點本末倒置了中燥。
隨著自己思維不斷的演練寇甸，思維導圖的功用越來越和列表差不多。
當然因人而異疗涉。
思維導圖的功用是用來梳理想法之類拿霉，很多使用者使用經(jīng)常用來提煉書籍的主要觀點。
所以咱扣，理所當然可以用來梳理代碼的邏輯绽淘。
2. 怎么用
- 理解項目結構
- 找到主程序入口
- 閱讀源代碼
- 再讀一遍
- 邊讀邊繪制思維導圖
- 數(shù)據(jù)庫（增刪改查）
如何借用這個工具來梳理代碼邏輯？
- 理解項目結構
項目結構這事闹伪，我總是反復說沪铭，項目清晰的劃分一定程度上體現(xiàn)在項目結構上，隨著接觸項目的越來越多偏瓤，項目劃分杀怠、項目結構都存在一定的共性。
比如厅克，項目的配置信息赔退、中間件、模型的定義已骇、項目的入口离钝、第三方包、編譯腳本等
理解項目的結構是第一步褪储，知道項目的哪個部分是用來做什么卵渴，哪些是輔助性的功能，哪些是核心實現(xiàn)的功能鲤竹。
- 主程序函數(shù)入口
在Go 語言中浪读，主函數(shù)入口，就是 main 函數(shù)辛藻，但一般main 函數(shù)都不是那么明顯碘橘，不是一眼可以看出功能來。
比如API 主函數(shù)吱肌，只是啟動 Web 服務痘拆，開始監(jiān)聽端口，真正的函數(shù)入口有可能是設備捕獲頭像信息氮墨，將頭像信息入庫纺蛆，成為數(shù)據(jù)庫原始數(shù)據(jù)。
- 閱讀源代碼
比如API 服務规揪，這個好辦桥氏，一個個接口看，看如何實現(xiàn)資源的增刪改查猛铅，對應的動作是什么字支。絕大多數(shù)接口都只是完成對資源的簡單操作，比如刪除奸忽，比如獲取堕伪，比如更新等。
這些不是我們進行思維導圖的重點月杉，重點應該是理解項目的原始數(shù)據(jù)的入口刃跛。
比如說這是一個機器視覺項目，攝像頭是數(shù)據(jù)采集器苛萎，核心應該是在關注原始數(shù)據(jù)采集這塊桨昙。
比如采集到的參數(shù)有哪些，涉及到的模型有哪些腌歉，對應的數(shù)據(jù)庫內表有哪些蛙酪，采集到一條數(shù)據(jù)，涉及哪些表操作等翘盖。這些才是我們需要閱讀源代碼的重點桂塞。
- 再讀一遍
沒什么。書讀百遍其義自現(xiàn)馍驯。
- 邊讀遍繪制導圖阁危，不斷修繕
- 傳入的參數(shù)是什么
- 涉及的表有哪些
- 表為什么這么設計
- 表之間的關系是咋樣的
- 中間件起到什么樣的作用
- 程序結束的標志是什么
磕磕碰碰玛痊，中間可能還有不懂，實在琢磨不透狂打，問問有經(jīng)驗的人擂煞。
3. 理解業(yè)務
- 根據(jù)思維導圖更改代碼實現(xiàn)需求
當你繪制完了宫仗，你對整個項目的理解更進一步了菱农，這個時候最好的辦法是不斷的實現(xiàn)需求趴樱。根據(jù)自己的能力先想想如何自己實現(xiàn)需求以及對應的時間評估翻擒。
盡早完成需求病蛉，不斷的向比自己高段位的程序員求證店茶，需求的實現(xiàn)是不是正確的歧焦，delay 了 容易給人不靠譜的印象缺脉。有可能別人只要和你提個點惦辛，你就能更好的完成任務了呢劳秋。
4. 拋開代碼理解業(yè)務
- 從商業(yè)的角度
- 從產(chǎn)品經(jīng)理的角度
其實這個階段的事不必單獨抽出來，在實現(xiàn)需求的過程中都是不斷的理解的裙品。
因為需求俗批，就是根據(jù)這些商業(yè)的需要才得到。你理解了商業(yè)的需要市怎，你就知道需求岁忘，知道了需求的本質，產(chǎn)品經(jīng)理給你的需求区匠，你自己就可以考量干像，是否合理，需求是否是過度的驰弄，或者說換個角度麻汰，需求是不是更合理？
比如說戚篙，這是一個機器視覺項目五鲫。所有的數(shù)據(jù)源是圖像，拍攝到的圖像岔擂，進行算法識別位喂，入庫，再根據(jù)庫內帶有信息的圖像進一步分析乱灵，得到一些商業(yè)價值塑崖。
都是識別場景，機場需要的識別場景可能和線下新零售的識別場景不一致痛倚。機場更多的識別人和物的安全性规婆。新零售識別人，更多的是針對人給出商品推薦。
所以抒蚜，在編寫代碼的過程中掘鄙，你需要理解需求的來源，從商業(yè)和產(chǎn)品經(jīng)理的角度思考需求嗡髓。
你可能會覺得自己水平還不行通铲，給需求就乖乖實現(xiàn)得了。
技術只是手段器贩，最終的目的是完成好的產(chǎn)品，多思考合理性也許能不斷的使產(chǎn)品更好朋截，參與一款好的產(chǎn)品的過程蛹稍，為什么不呢？
5. 反復和優(yōu)化
- 爆炸式增長
- 漸進式增長
簡單的實現(xiàn)業(yè)務需求部服，對一個后端工程師來說唆姐，這些遠遠不夠。
只能實現(xiàn)需求廓八，你的可替代性就強奉芦，核心競爭力就弱。因為隨便找個對語言熟悉的人剧蹂，都可以完成你的任務声功。
后端工程師，技能的精進宠叼，和數(shù)據(jù)量的大小還是有一定相關的先巴，比如數(shù)據(jù)量只有10萬級別，你可能怎么實現(xiàn)都可以冒冬，也不太會遇到難題伸蚯，瓶頸等。
那假如 100萬呢简烤，1000萬呢剂邮，1億呢？這對后端工程師的要求顯而易見吧横侦？
通常來說挥萌，只要你不是做外包的，基本上你會持續(xù)的接觸一個或者多個項目丈咐，項目會隨著需求不斷的變更瑞眼。當然隨著數(shù)據(jù)量的增多，項目的整體設計也可能需要變更棵逊。數(shù)據(jù)量的增多伤疙，有爆發(fā)式的，這種情況，沒有一定的知識儲備徒像，解決起來非常的難黍特，第一，你需要經(jīng)驗锯蛀；第二灭衷，你需要團隊。比如某APP 用戶量瞬間從百萬級到億級旁涤，這種情況翔曲，沒有足夠的積累，不好意思劈愚，解決不了的瞳遍。
再一種是漸進式，比如你賣出一個設備菌羽，數(shù)據(jù)量大概增加5萬掠械，這種漸進式呢，原則就是遇到問題注祖，解決問題猾蒂。或者提前儲備知識是晨，進行項目優(yōu)化肚菠。
具體的過程，等我技術上升一個等級再來細說罩缴。
6. 總結
本節(jié)講述的是如何進行代碼邏輯的梳理案糙。借助思維導圖進行梳理。沒有具體的使用實例靴庆，只是大概講述了制作思維導圖梳理代碼邏輯的要點时捌。
原因有二：
- 我自己接手的項目不宜公開
- 開源的項目大多不是偏業(yè)務型，都是框架類或者第三方庫類炉抒。這種不太有承前啟后的邏輯梳理奢讨。
希望大家喜歡⊙姹。可以在實際的項目內多嘗試拿诸。
謝謝，我是謝偉塞茅，再會亩码。
