一名前端實習生在京東的成長小結_敲程式碼的小提琴手

theme: awesome-green

這裡是一名23屆的在校學生，自一月初以前端開發實習生加入京東科技的前端研發組以來，到現在已經是有三個月了，我也結束了這段充實的實習，準備返蓉回到校園，去準備期末考試、實驗課之類的事務。

首先感謝組內同事，特別是我的mentor教授給我的知識，感謝他們不厭其煩地帶著我完成任務、解決問題。

另外也是回過頭來反思了一下：自己是否有幫助到團隊解決什麼問題？自己是否從這段實習中有所收穫？靜下心來思考沉澱了一下，希望能讓自己有所收穫，讓大家有所共鳴吧。

本文簡單分為以下幾部分：

在京東學習的“三個階段”‘
- 學習規範、讀文件階段
- 程式碼質量優化階段
- 編碼速度提升階段
工作以外的個人學習、成長
- 程式碼規範、分支管理規範
工作中，通過寫業務、寫bug（x）得到的一些收穫
展望未來，之後工作中要避免踩的一些坑
- 寫業務的時候要考慮全面，把自己想象成產品經理，直接面對需求，你寫出來的程式碼，能用麼？有bug麼？最開始不注意自己程式碼的質量，提測之後會很難受哦~

首先感謝下每天幫我review我的 * 山程式碼的mentor，您辛苦了 orz （希望mentor大大不要逛掘金要不直接社死現場 QAQ

合理地封裝元件
- 減少與業務強相關的變數、方法通過業務元件的傳值解決這部分需求
- 追求更好的擴充套件能力、使封裝好的元件更加靈活
- 迭代新需求的時候要不斷思考可以把哪些內容封裝成通用元件

從這個階段開始，mentor會給我一個頁面，讓我獨立完成並且評估時間，關注點主要在於：

程式碼規範
- 雖然平時寫業務的時候有ESlint的幫忙，但是程式碼規範這個基本功肯定還是要具備的，寫一些小demo，完成一道力扣，都體現了一名程式設計師的基本素養~
分支管理規範
- 分支管理 Gitflow工作流文件
  
  一個功能一個分支，寫完了一個功能就提pr 提完pr就刪除分支~
  
  相關文件：my-git/git-workflow-tutorial.md at master · xirong/my-git (github.com)
- commit命名規範
  - 每天一提交的commit，這個還是要保證基本的規範滴，要不然想追溯之前的版本，就懵逼了XD
  - 'feat', // 新功能 feature 'fix', // 一個錯誤修復 'refactor', // 重構(既不增加新功能，也不是修復bug) 'docs', // 僅文件更改 'test', // 新增缺失的測試或更正現有的測試 'chore', // 既不修正錯誤也不增加功能的程式碼更改 'style', // 不影響程式碼含義的更改（空白，格式，缺少分號等） 'perf', // 改進效能的程式碼更改 'revert', // 回退 // eg: 'feat: 添加了圖表功能'
- 不要在程式碼倉庫中使用強制回滾的命令~

寫這篇總結的一個原因是為了回顧下自己上段實習的收穫，而更重要的一個原因是為了從上段三個月的實習中找出自己存在的問題並爭取不要在下次實習再犯，這裡也簡單列出來吧——

好多時候工作效率不夠高，總喜歡寫會兒業務耍會兒手機
- 解決方案：工作時遠離手機，並通過計時器碎片化地分割任務，做到心裡有數地高效完成任務。
總是想當然地編碼，好多時候與實際需求相悖，或者存在明顯的bug，經常把mentor氣笑 😶‍🌫️
- 解決方案：理解了產品需求之後，構思好頁面如何實現，再去寫程式碼。
如果有一個卡住自己很久的bug不知道怎麼修，困擾了自己很久的需求不知道怎麼寫，要及時問下mentor，避免無意義的時間浪費。
- 當然了，問問題之前要先查閱文件，看看是否有很顯而易見的解決方案~

再次感謝京東科技我所在的前端研發組的各位有愛的小夥伴，這真的是個超級棒的團隊鴨！瘋狂打call，大家有緣再見啦！