小弟目前剛好也是在一家新創工作，coding資歷不滿一年
公司剛好也是用 JS開發，剛好可以來分享個經驗
※ 引述《wandallin (萬大林)》之銘言：
: 1. PR要merge的時候做Squash，因為這樣git tree比較好看
個人習慣問題？我一開始也是通通commit上去，後來發現很醜
所以才逐漸會用 squash 整合commit
不過用 squash 後就會開始思考：哪些 commit 該留哪些不該留
很多就只是暫存用的 commit 或者是多餘的 commit
commit 上去根本只是干擾追蹤程式演變
所以個人是認為說 git tree 好看不好看，應該不是你們討論的點
如果真的要好看的話，那push上去之前通通squash成一行 commit
或者只留下 merge XXXX，可是這有意義嗎 囧
所以說這其實是開發者之間溝通好就可以
: 2. function超過一百行，就想要拆出來
一個函數 >100 行就想要拆出來，這完全是我的寫照
理由就是可以拆成一個最小工作單元好維護、好規模化
甚至你要重複程式碼也很好複製貼上(誤
寫成一個兩三百行的code，要重複利用就需要花點時間
不過這基本上是在寫code階段就可以決定的了
例如這個函數有5個步驟，每個步驟可能可以各自寫成工作單元
所以我常常被主管唸說拆太小了(遮臉)
我剛看一下我的函數蠻少超過 100 行，很多都在50行內就解決了
另一個類似問題就是每行字數，像我們前端就是約定好每行不超過80
不過後端工程師他們有各自的習慣，所以在後端code就是120
: 3. 完全遵照eslint的規範，任何warning都不能出現
eslint是個好東西！
但eslint要注意的是，他每個規則不是強制性的
而是要按造開發習慣，去客製化自己的規則
比方說他有些規則是 prefer-destructuring, prefer-template 這種
老實說真的要用解構或者用template字串嗎...?
並且當你用 eslint 這種靜態程式碼檢查工具，
他的用意就是提醒目前的code沒有遵守你預先設定的規則
所以這些 warning, error 就是告訴你違反了自己設定的規則
如果不想修這些 warning 或者 error
那就是應該把他從code裡面 用 /* eslint-disable XXX */
或者從 eslintrc 裡面把規則移除，或者放大絕 yarn remove eslint XDD
其實問題並不是在 eslint ，而是團隊間怎麼溝通這個規則吧
: 4. 時常想回去重構程式
: 5. 想把所有非同步的function都改成promise
其實這兩點是一樣的：重構程式
重構程式是個良好的習慣，他在改善舊有的程式碼
增加程式可讀性、可維護性
例如打開 legacy code，有時候真的是要邊寫測試邊重構
才能把需要的新功能加上去...
但個人是覺得有時候重構要看時間
如果現在要開發一個新功能，
然後同事在那邊說：沒空，我手上程式還沒重構完
你或者老闆你應該會想掐死他
更何況新創生死存亡都在一瞬間了XD...
有些技術債就等活著的時候再來還了
: 6. 想導入TDD以及jest，讓系統減少錯誤發生機率（目前沒人會這東西）
這點我有深刻體驗，我們前端沒有很嚴謹的測試
所以有次我 push master 結果上線後整個網站死掉
幸好我們有完整的ci/cd，很快就rollback 到前一個版本
我一整個嚇到漏尿，我後來就補上一些可以很快檢查出錯誤的測試
經過那次慘痛經驗後，基本上能寫測試的我都會寫測試
除了增加程式信心度，同時也可以去思考哪些是預期行為哪些不是
不過有時候新功能要緊，所以通常都是寫核心功能的測試
剩下的再慢慢補上去
: 7. 註解盡量刪除，只留jsdoc，減少封裝程式碼
jsdoc是個好東西，提示參數資料型別非常好用
註解要不要寫要不要留，真的是見仁見智
我們目前註解都是用來做注意事項或者todo
至於用減少封裝程式碼來說刪除註解...
現在 js 在 production 環境應該都有用封裝的程式，例如 webpack
就可以直接用 uglifyjs 去把程式碼的註解全部移掉還幫你最小化
這方面有現有的套件幫你做掉了XD
所以其實看一下... 很多都內化成平常的習慣了 哈哈
不過這種開發守則，要不要遵守就是看你們公司了~
大不了就是技術債而已XD 不過新創公司能不能還技術債還是問題呢