良好的开发习惯助你一臂之力——程序员日常开发注意事项总结

冷不防 2021-09-21 06:02 283阅读 0赞

作为一名刚入行不久的菜鸟 Java 程序员，经常被自己的一些不好的开发习惯给坑，导致明明运行好好的项目突然出现意想不到的 Bug。然后，我就被导师叫过去进行了一番细心的指导，这里要特别感谢一下我的导师，可以说他在我目前开发路上给了我许多帮助。

### 注意事项 ###

这里，我总结了几条开发中我认为比较重要的注意事项：

**1. 完善代码注释**

我相信很多小伙伴跟我一样，自己写的代码过一段时间去看就不知道是怎么回事了，而且经常发出疑问，“咦，这是我写的代码吗”。所以，注释是一个很好的东西，它不仅可以帮助我们理解程序中的每一行代码在做什么，而且可以降低代码的维护成本。

但是，注释也不能随随便便的写，任何地方都写。这样会让代码显得冗余繁杂，反而降低了代码的可读性和维护性。

我们在写注释时要讲究简明扼要，突出含义。对于类的注释，要表明类的功能和副作用（即使用该类时会不会出现一些异常等）；对于方法的注释，要表明方法是干什么的，每个参数的含义以及方法的副作用。

**2. 完善单元测试**

单元测试可以帮助我们发现程序中一些的 Bug，提升代码质量，提高开发效率。

很多小伙伴应该和我一样也会时不时偷懒，没有去写单元测试，觉得很麻烦。但是，我在导师的督促下也补上了单元测试，后来我每次改了 Bug 后都用单元测试跑一下，就检查出了问题，比之前自己人工测试要快的多。突然就发现了单元测试的好处，虽然前期写单元测试有点麻烦，但是后期的收益是杠杠的，真香。

**3. 过时的方法代码不要急着删除**

在项目迭代中，我们会不断重构一些之前写的不是很好的方法。但是，过时的方法不应该马上删除，而是应该等重构的新方法上线运行一段时间，没有出现异常后才将过时的方法删除。

为什么要这样做呢？因为我们并不能保证重构的新方法上线后一定能稳定运行。如果上线后新方法在运行的过程中出现 Bug，并且影响了用户的部分操作。那么，过时的方法就可以作为一种应急的替代方法，将新方法换下来，以保证用户正常操作。之后，我们再进行新方法的 Bug 排查与修复。

**4. 在一个版本的迭代中，项目的 API 只能增加不能删除**

在前后端分离的项目中，当需要修改项目 API 地址时，应该是在旧的 API 地址上再添加新的 API 地址，旧的 API 地址应保留至项目迭代几个版本后，没有出现问题才进行删除。

为什么要这样做呢？因为随着时间的推移，我们可能并不清楚到底有多少地方调用了旧的 API 地址。所以，当我们用新的 API 地址替换旧的 API 地址时，并不能保证所有的地方都完成替换了或者在替换时因为一些其他因素而漏掉了一些。如果此时就把旧的 API 地址删除了，那么上线后会存在很多风险。

比较好的做法就是让旧的 API 地址随着项目一起迭代几个版本后才删除，这样我们有足够的时间去发现遗漏的地方，减小项目上线出现的风险。

**5. 请新建一个项目分支来修复 Bug**

当项目出现 Bug 需要进行修复时，应该从当前版本分支（确保此分支没有进行任何更改）上新开一个新分支来进行 Bug 修复，最后再合并回原分支上。

这样做有什么好处呢？首先，不会影响我们正在开发的内容；同时，我们在修复 Bug 时，并不能保证修改后的程序没有副作用，这样也便于我们进行测试。

**6. 新建一个项目分支来完成项目新需求开发**

当项目有新需求要进行开发时，应该在 Git 上新建一个项目分支来完成新需求的开发，并将分支命名成 `version_版本号_需求名` 这种形式。

为什么不直接在当前版本分支上开发呢？如果我们在当前版本分支上进行开发，当项目出现 Bug 需要马上修复并上线时，而当前版本分支上还有我们没有开发完的新需求，根本不具备重新上线的条件了。此时，只有重新从远程仓库将当前版本的内容下载到本地，再进行 Bug 修复。这样反而很影响我们的开发效率。

当我们在新分支上完成新需求开发时，应该先将当前版本分支合并到新分支上进行测试，没有问题后再合并到当前版本分支上。

### 小结 ###

在日常的开发中，养成良好的开发习惯不仅可以帮助我们提高开发效率，还可以降低开发过程中出现的一些不必要的失误与错误，间接地也改善了我们的代码质量。

所以，小伙伴们一定要养成良好的开发习惯哟，一起加油！欢迎补充。

还没有评论，来说两句吧...