小弟目前刚好也是在一家新创工作，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/cn.aspx?n=bbs/Soft_Job/M.1524588404.A.4A4.html