一、是避免过度封装。 针对业务需求，我个人是比较喜欢过程式的开发模式的，因为有一个清晰的脉络。 除非遇到了多个页面有相同的逻辑，可以使用面向对象的方式，或者抽离到一个公共文件中进行复用。

二、对于路由跳转的传参，不要一股脑地把url上所有参数都传到下一页。 当下开发是爽了，不用考虑url上有什么。等到后面的人接手时，完全不清楚url会具体携带哪些参数。 就比如当下的我，对于一些一股脑this.$route.query的传递方式，是既怕又恨。 我怕以前的老逻辑中出现大量这种方式的书写，又恨自己不敢大胆地重构这些旧逻辑。

三、对于开发代码的git提交，我推崇是改动细分多提交。 在开发完一小段功能就提交一次，而不是完成一整个页面大需求再最后提交。 我从工作初期就一直使用这种方式，仍旧记得以前给同事推荐这种方式。不知今日的ta是否采纳了呢？ 此方式的好处就是无论是代码回滚，还是cherry pick都非常方便。劣势则是提交数量会大大增加。

四、多记录 随着年纪的增长，对于好记性不如烂笔头这句话愈发赞同。只要是在工作中遇到的一些问题、解决思路，亦或者一些开发日常，都可以记录下来。 一是能清晰反映出每日的工作进展，二来也能日后进行回顾反思

五、多注释 虽然有句古话叫好的代码完全不用注释，但我认为天底下百分之九十九的人都无法写出完美代码。先不论他人，光是自己几个月前亲手写的代码，在几个月重温时也得细品一下，有些甚至会摸不着头脑。 故我们需要注释，利己利人。