入职一个月，我在项目中犯了的哪些错？

趁着今天周末，爬上来总结一下，入职的这一个月，我在项目中犯的一些错误。正好趁着今天人少，小鹿会在文末给大伙送一波书籍。

不知不觉入职都一个月了，这一个月感觉过的贼快而且贼充实，更贼有收获，你要问收获是啥？那就莫过于项目中出了各种错。

我们前端团队就我一个应届生，算是一个拖后腿的吧，哈哈哈，初次入职，接触到公司的项目，出错也是很正常的，但是想要快速的去适应以及不再出现一些小错误，那就要每天都好好的反思了。比如，晚上躺在床上，想想今天又在项目中得到了哪些教训。

今天就和大家伙聊聊在项目中我犯过的一些比较“智障”的问题。

先说说版本控制 git，玩坏不止一两次了，每次都要亲自叫老大帮忙过来解决，git 基本的操作，我相信各位都玩的很 6 了，但是有一些特殊情况真的是第一次遇到，不敢轻举妄动呀，不然就该删页面跑路了。

毕竟之前一个人，一个项目，怎么玩都没事，玩坏了大不了重新上传，但是到了团队中，git 的版本提交都要涉及到多个人甚至很多人，提交的规范那也是必不可少的。

举个实际的例子，之前提交代码团队都用的是传统的提交，每个人将项目 fork 之后，都在自己的分支进行开发，开发完成都会提交一个 pr，然后项目负责人同意后才会进行真正的合并。

但是有个问题，人一旦多起来，整个项目分支就显的很乱，如下：

这条绿色的就是项目的主分支，而其他颜色的线是团队中各个队员的分支，开发完毕后我们一般都合并到主分支上。

这样看起来每个人什么时间提交了什么，看起来很费劲，所以有了变基模式（rebase）。多人提交如下：

这么一看，清晰多了，每个节点就是代表那个人提交了新的代码，这样一目了然，而不去之前一堆分支中去找。

初次使用，确实被我玩坏过几次，但是老大总是很有耐心的手把手教科书本版教我，我的操作问题出在哪，你们可以想象出那种多么有爱的画面，有这么好的一个老大，谁不爱呢？

关于 Git 变基后期会专门写一篇技术文，这里俺就不多啰嗦了，看下一个问题。

之前写的项目基本以实现功能为目标，代码的可优化性基本不考虑，也就是说，你写完一段功能代码，是否考虑一下有没有更好的更简洁或者设计更好的代码逻辑。

这也算我之前写代码的一个毛病吧，入职之后，算是长记性了，老大把我这毛病硬生生的给调出来了。每次开发完提交代码，都需要经过老大的审核，会从头到尾看一下你写的代码逻辑有没有问题，如果有问题会告诉你这个地方应该怎么改动，怎么去优化实现达到更好的一种格式和规范。

为了尽量不占中老大帮我审核代码的时间，每次我自己写完之后，都要问一问自己代码有没有可以优化的地方，自然而然形成了一种习惯。

除此之外，之前开发工具中中没有装 ESlint，难免少一个分号，都会被老大挑出来，然后改完进行重新提交。看着到可能很多人会说，你们代码都这么规范标准的吗？

我个人觉得，越是这样严格的要求，越是好，偶尔听到朋友那公司项目代码烂成一锅粥，突然发现自己有多么很幸运啊，很幸运能遇到这么规范的代码设计。

这也看得出，我们老大也是一个对团队队员严谨和高标准要求的一个人，所以能在年轻的时候多遇到一些老大这样的人，无论是技术还是生活，对我还是有很大影响的。

除了以上项目中出现的问题，还有比如说第三方库的使用标准以及代码提交原子化，变量和方法的规范命名等问题，作为职场新人，还是应该多多注意的。

一个月的时间，总结了很多实际项目的经验，我觉得这些经验都可以拿出来分享，少走一些坑，多一些方法，这对与刚接触一个陌生的项目是很有帮助的。

后边正在准备一篇入职如何快速融入熟悉项目的经验总结。一起期待吧！

— 【 THE END 】—
本公众号全部博文已整理成一个目录，请在公众号里回复「m」获取！

3T技术资源大放送！包括但不限于：Java、C/C++，Linux，Python，大数据，人工智能等等。在公众号内回复「1024」，即可免费获取！！