1.合理命名

合理命名，这里的命名包括变量名，方法名，文件名，git的提交信息，分支名等等。

起的名字应该让其他开发者一看就知道你的方法是用来干什么的，这个文件是讲什么的，你这批提到的代码具体内容更新了些什么东西，新建了这个分支又是用来干嘛。

当然也不一定是为了给别人看,就比如我在看我自己一年前写代码的时候呢,也要重新过一遍才能搞清楚每一个功能是怎么实现的，这时候如果你里面的命名都比较正常的话，这样找到要修改的地方就会比较快。

或者如果说当产品迭代多了之后呢，想要追溯到没有某一个具体功能的一个旧版本的时候，如果你git里边的描述都非常清楚,也会比较容易的能够找得到。

2.合理的写注释

注释是一定要写的，只不过不要写得太多。我以前的话就很喜欢写那个分隔线，就是某一个功能是从哪里开始，然后到哪里结束，因为我老是翻半天都找不到我想要找的那一行代码，后来有一天我知道写分隔线其实是不太规范的，就有点类似于你可能每写一两行代码就写一行注释，解释一下他是干嘛的一样，就比较多余，如果说方法名,变量名都起得非常的精准的话，别人其实一看就知道是干什么的就不用额外去解释，比如说你一个获取用户列表的方法名叫getuserlist，别人一看这个方法都知道他是干嘛的。

HTML里头的class名ID名也是一样的，比如说用户列表里的标题class或者id叫做比如说user list title会比你直接叫做title要好找很多,如果命名可以做到非常精准的话,其实就可以通过搜索关键词去直接定位到那行代码，就不用去写什么分隔线之类的。

我觉得比较有必要写注释的地方,就包括比如说to啊，或者说这行代码可能稍微需要一些优化啊，然后存在一些问题什么的要给后边开发的人或审核代码的人解释一下，或者我注释掉了一段代码，然后解释一下为什么我要把它注释掉，或者是一些比较复杂的功能,不能够完全通过命名去解释清楚的，或者说我使用了一些比较冷门的第三方插件我想要解释一下或者是附上一个文档链接等等

3.尽量分组件

组件化是前端开发里面一个核心的概念，把页面上的每个模块单独分出来，作为一个单独的组件不仅可以方便今后把单拎出来重复使用而且也可以避免某一个文件里面的代码太长,导致我又要写分割线了。

我在自己刚刚开始做开发的时候就经常会省时间嘛，就偷懒就把所有东西都写一个文件里，短期看来呢确实是挺省事的所以就往里头加的功能越来越多，那个文件里的代码就会变得越来越长,你要找到某一行代码就变得更加不方便，而且随着一个文件里的功能点越来越多你想要去拆分成不同的组件，也就越来越麻烦，牵一发而动全身所以你懂吧，问题呢就滚雪球形成一个闭环所以说如果在刚开始写的时候就养成分组件的习惯后续就不会有这样的困扰了

4.不要让自己卡在小的bug上

我是一个有一点完美主义的人，一旦遇到了bug解决不掉了就浑身不舒服。可是解决bug这种东西很多时候都是看运气的，就很难保证说我多长时间我就一定能搞完,我发现了这个时候就一定要有大局观，在适当的时候放弃执念就可以节省掉很多时间,想想你现在在做的这个功能的实现主要是依赖什么，是不是这个bug，还是别的什么东西。

就比如说作为一个登录页做到验证用户收的那个邮箱的格式的时候出现了bug，我就一直卡在那里，但是吧登录功能的实现在老板或者是普通用户看来，就是你输了用户名,密码之后可以登录成功，或者说他告诉你登陆失败了，那其他东西也很重要但是相较于此来说还是比较次要的，所以说接下来呢，把登陆接口给它接上，其实对于完成这整个任务来说更重要。

其次就是如果我先跳过这个bug先去做那个更关键的工能,心理上来讲也会比较的好受一点，毕竟在这整个的功能只实现了20%的时候,被一个bug卡住，和在整个功能都完成了90%的时候被这个bug卡住，相比后者压力会相对小很多。

5.找一个时间段是可以专注于工作的

寻找一个时间段是可以专注于工作。程序员在工作的时候很忌讳被打断，就是我们在构思一个功能怎么样去实现的时候，通常来说都是需要集中思考的,这也是为什么我们很容易陷入就是发现了一个bug就一定得去死磕他想要把解决，至少对我自己来说是这样的。

如果我在写代码的时候,被一个很小的事情打断了，比如说有人来找我聊天，然后我开始分心去加入这个话题的时候还要重新再回到这个工作状态，我又要去花一些时间,重新进入到我这个逻辑思维里头，你们懂我意思吗？

所以通常我再给我自己安排工作的时候，如果我知道我接下来可能要去做一些新功能或者是要去解决一个bug的时候,我会给自己至少至少三个小时的时间是完全没有任何干扰的，这样可以保证我最大化的提高自己的工作效率。