一、技術
看影片教程入門（B站即可），看書深入，最重要的是實踐。
二、怎麼提問
很多新人不知道怎麼提問，問了太簡單的問題怕被人鄙視，更重要的是不知道問題是否簡單。
其實也沒有那麼嚴格，程式設計師還是很願意幫人解決問題的，可以裝一下13並且很有成就感。
值得注意的是：
- 這個問題百度、谷歌是否有答案，對著教程你試過沒有，中間是遇到什麼坎導致你無法解決。
- 這個問題你是怎麼想的，多多少少你會有思路和想法，有了這個基礎，“請教”就變成了“溝通”。
- 實在無法解決，請精簡你的問題，精準描述，不要模糊、籠統，這樣別人很難幫你。
- 如果他人幫了你，請說謝謝，能誇一下就更好了。至於物質上的報答看個人情況。
- 多總結，不要問重複的、類似的問題，答案不重要，重要的是解決的思路。
- 最好將你的問題、解決方案發布到網上，比如部落格，這樣不僅能幫到更多人，還能方便自己覆盤、回顧。
最後，有問題一定一定不要悶著！！
領導最怕的不是你有問題，哪怕很基礎的問題，只要影響了你的進度，比如卡了一個小時都沒解決，就去尋求幫助，不要等最後領導來問題進度的時候，你再把問題丟擲來，然後說沒完成。切記切記！！
三、思維
客戶端往往是頁面驅動，即一個頁面需要哪些東西，怎麼最佳化，跳轉邏輯、層級邏輯等等。
服務端更多的是資料驅動，首先設計表，然後根據頁面返回資料。現在有了領域設計，但是小白還是先放放吧。
資料
從MySQL開始學最好，首先是基本的SQL語句，最好能自己針對業務設計表，怎麼最佳化結構、最佳化查詢，這個可以說是服務端的基本功。
其次是快取，先看看redis吧，然後思考下什麼時候該用快取，什麼時候過期，用什麼結構，怎麼維護資料一致性。這個沒有標準答案，重點是結合業務。
互動
怎麼將資料和頁面結合起來，怎麼返回欄位更合理，怎麼減少客戶端工作量的時候緩解服務端的壓力：
- 並行：只是要求快，沒有時序要求，可以並行工作而不是序列。
- 佇列：對於有時序要求的，可以用佇列排序處理。
- 非同步：客戶端不是立刻需要這個資料的，可以先介面返回然後自己慢慢處理。
併發
可以說是服務端的一生之敵。常用的解決方案就是兩種：
- 加鎖：簡單粗暴但是影響效率。
- 佇列：將所有請求順序化，程式碼比較複雜，但是邏輯清晰合理。
四、編碼（重點）
前面的說實話，幹一段時間，跟幾個專案基本就有體會了，但是編碼，有的人可能開始就很優秀，有的人一輩子都寫的很稀爛，原因就在於最開始的習慣不一樣，我希望更多小白能看到。
- 先想，用80%的時間去想、去設計，然後再寫。
- 程式碼風格因人而異，但是能抽象儘量抽象，不要一個函式梭哈到底。（沒bug > 好維護 > 花裡胡哨全是bug）
- 提交之前一定要多看看，服務端的程式碼往往是牽一髮而動全身，而且服務端有問題往往就是大問題，所以要反覆思考會不會影響其他模組？能不能相容，他人呼叫會不會崩潰？會不會有效率問題？資料量大了會不會有問題？請求量大了會不會有問題？
- 設計的時候要方便測試，比如按天結算的按小時、分鐘結算。寫的時候要寫單元測試。寫完了要自己先過一下再發測。
- 上線前一定要留預案。最壞的情況是什麼？萬一發生了我怎麼辦？線上有bug我要怎麼除錯，怎麼查？如果崩了我有沒有planB?
- 不管是編碼中，還是線上有問題，都要記得覆盤，這很重要。不要在乎是誰的問題，要好好思考怎麼避免，萬一出現了怎麼修復。
- 如果有bug，尤其是線上bug，一定要找到確鑿的證據（日誌+復現）再改。如果重大問題，及時回滾；如果容忍線上偶發，拼命加日誌，抓到了再改。千萬不要覺得是某個問題就改或者打補丁！ 這就像你去看醫生，如果醫生看都沒看就給你開藥要你做手術，你怎麼想？服務端改程式碼一定要像手術刀，穩準狠！
這些習慣，如果是小白，希望你從一開始就養成這樣的認知，就覺得理應如此，我相信你能受益匪淺。
還有其他問題，歡迎評論區一起討論。