在生命的低潮期，我增加了思考人生的次數。
前言：
最近在觀看胖東來的創始人於東來先生的一些直播切片，使我感悟良多，同時他的觀點，他的人生態度快速地將我從低落的情緒的沼澤中拉出來。對於他的觀點，我大部分是認同的，欣賞的，稱讚的，少部分不認同。對於他闊達，樂觀，自信，自愛的人生態度；有成人之美的心；尋找自己的長處，量力而行，循序漸進的做事風格，這些點我是很欣賞，覺得他的高度是比我高，也使我有種我也要這樣做的茅塞頓開的感覺。甚至覺得他有種修道，修佛的心態，非常厲害。
從他的觀點結合一些我的觀察和別人的説法，我發現，如果層次越高，責任和權力越大，似乎就越應該花更多的時間在制定規則上，比如我作為一個前端小組長去面試，經常被問到説給團隊制定了什麼規則，如何促進團隊發展和保證代碼的質量，而我的技術水平彷彿沒那麼重要了，技術可能只佔50%-70%吧。而如果做到於東來先生這個位置，他每天花大量時間是用於開會制定員工守則，制定對員工的提升和考核的機制，制定公司制度，獎懲規則，利潤的分配規則。甚至開直播傳播思想和理念。而縱觀當今世界一些“先進”國家，手上更是握着大把的規則，並且哪個國家不遵守，還必定會滿臉通紅，暴跳如雷。他們手中規則的效力似乎與他們的國家地位是相掛鈎的。透過這個現象是否説明了，當管理後，建立一個當下好的規則才是當下對大部分人收益最高的選擇？規範的意義是什麼？有興趣的朋友可以在評論區探討。
正文：
以下前端開發標準規範是我從工作和學習中總結的，均以ESLint和TypeScript的默認配置為前提，並且在持續更新中
- 單個文件的代碼行數不超過300行，特殊情況可以多至四百多五百行。
- 重複的代碼必須抽離出單獨的函數或者組件，然後放在重複代碼的文件結構的共同父級處。
- 代碼提交測試前應儘量減少控制枱的warning，完全消除控制枱的報錯。上線前應該把絕大部分的warning消除。
- 滿足需求後，代碼的編寫以低複雜度的方案為準，以減少接口調用次數的方案為準。
- 單個邏輯不能重複渲染。
- 定時器，事件監聽器使用後在組件銷燬時也要隨之銷燬和取消監聽，減少閉包的使用。
- 每個函數，類和公有變量都應加上功能，作用説明的註釋。並且命名使用其中文功能的英文翻譯。
- 減少if...else if...else的使用，用單if，switch，includes等代替。
- 廢棄的代碼用刪除代替註釋，因為git中有老代碼的記錄，刪除能使代碼整體更整潔，如果怕找不回來可以留一行註釋説明這次git提交的commit-id。
結語：
保持學習，保持成長，保持前進，保持心中的那道光。
