小弟目前刚好也是在一家新创工作，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 不过新创公司能不能还技术债还是问题呢