※ 引述《wandallin (万大林)》之铭言：
: 大家晚安，因为本身没什么朋友在新创上班，自己也是第一次在新创
: 所以想在这边询问大家开发上的一些小疑问
: 开发环境是react.js + create react app + firebase
: 目前公司是MVP刚上线的状况还在补足一些功能
: 好让老板出去推销，尚未盈利也还没确认商业模式
: 不过在开发过程中其他工程师会提一些作法，说是为了未来着想
不用过早完美 或 普通
甚至烂 都可以
客户只关心 什么时候上线
可以动就好
专注完美的后果就是把自己搞的压力很大
而且老板+客户会觉得你不专业
工程师常常会非理性 认为OOXX现在不做 之后就会OOXX的结果
只能说 常常都是想太多
: 例如：
: 1. PR要merge的时候做Squash，因为这样git tree比较好看
基本，不过用rebase会更好 但前提是会用
squash会有owner不清的问题
: 2. function超过一百行，就想要拆出来
没有什么超过100行就要拆出来的浅规则
遵循行之有年的SOLID原则 或许是你可以考虑的部分
: 3. 完全遵照eslint的规范，任何warning都不能出现
基本 不过现在都改用 javascript standard style
懒得设定eslint
: 4. 时常想回去重构程式
没时间 而且 在MVP版本不确定是否可行之前 也没必要
: 5. 想把所有异步的function都改成promise
async await , promise 已经是基本款 根本不需要考虑
: 6. 想导入TDD以及jest，让系统减少错误发生机率（目前没人会这东西）
tdd见仁见智，jest一般来说也没时间 可以考虑先用最基本的snatshop
过早全域component化，基本上就是痛苦的开端，不过这也是让unit test or snatshop
最能达到效果的部分
: 7. 注解尽量删除，只留jsdoc，减少封装程式码
以后面维护程式码的人 在越短时间看懂 为基准 才是对的
至于怎么操作 看人
: 上面除了第六项其他都开始做了
: 不知道大家的公司的情况是怎么样
: 我没有想过这些东西的压力会远大过我思考服务架构的问题
: 这些东西让我觉得满烦的，没有制度化都是看个人喜好
: 可能哪天他看到一个别的觉得不错又要用了
: 还是说新创本来就是这样，可能我比较适合回去一般公司
: 这辈子第一次觉得写程式这么烦＝＝
老实说 你还没待过真正的新创
因为真正的新创 才不会有时间让你想这么多