小弟目前剛好也是在一家新創工作，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 不過新創公司能不能還技術債還是問題呢 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.161.237.91 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1524588404.A.4A4.html