最近几个项目不是很顺利，虽然大的问题没有，但是小的问题还是零零星星的。自我总结一下，可能和我提交代码的习惯不好有一定程度上的关系。
以前在 real 的时候，我的提交代码习惯还是比较好的，基本上能做到一次提交解决一个问题，符合单一职责原则,来 hdf 后，慢慢有些放松了。做业务项目的时候，因为代码量大，而且比较分散，每次找代码都很麻烦，于是我投机取巧，尽量不提交代码，要找代码的时候，从修改记录里找，只要被我修改过且没有提交的，都可以在修改记录里很快找到。以至于有时候项目开始的时候，我都是先把几个重点相关的代码写一下注释，以让它们出现在修改记录里。当开始做技术项目的时候，我一般不是立马拉新的分支去做，而是直接用已经打开的分支先尝试进行修改，等技术调研，功能都实现差不多的时候，我再去拉个分支，把这些代码迁移过去。
这样种种的不良习惯，确实也导致了代码质量的下降。分析一下原因，其实很简单，因为整个编程过程中经历了 N 多次打断，也可能经历了 N 多天，中间穿插了 N 多个项目来回切换。长时间不提交，以至于修改记录里积攒了大量的代码，你甚至忘记了刚刚离开之前你修改了哪些代码。危险也就在这个时候种下了种子。
从现在开始，重新养成提交代码的好习惯，一次提交仅完成一件事情，和写好提交注释。刻意的约束自己，其实不难，而且会收益多多。
首先代码提交变得简洁明了了，在 review 代码的时候，可以通过每次提交的注释快速回忆起这次提交的修改内容。
在写代码的时候，也可以约束自己的思维不要太跳跃，明确告诉自己本次修改要完成什么功能，避免思维发散。项目中老代码太多，开发过程中看见了总是心里痒痒，于是这里改改，那里改改。现在就要约束自己了，只完成和本次提交相关的代码修改，无关的不要去修改，保持专注，也让自己开发过程变成有序。
方便回退代码，特别是一些技术调研的代码，如果技术方案遇到不可克服的问题，可以轻松的回退到之前的某个版本。如果没有即使提交的话，你就可能需要从一堆代码里去慢慢找哪些代码要回退，哪些代码要保留了。
代码写一半被中断后，比较容易恢复现场。每次当你回到项目工程的时候，看见的只是最近一次修改的几个改动，你就可以很快的告诉自己刚才离开之前在做什么了。而如果面对的是，从项目开始到现在所有的改动，那可能就需要多花一些功夫去接续上离开之前的工作。
可以避免代码丢失。代码保存在本地没有提交，总归是一件不好的习惯，以前我们曾经要求过下班前，需要把代码都提交到服务器上。有一次公司统一购买的一批电脑，先后出现了两次硬盘损坏的问题，导致我们的开发工程师的代码都丢了，只能重新开发了。这种事情是小概率事件，碰见就很倒霉了。我碰见的却是另外一种情况，我经常会直接打开一个暂时没有用的工程来写一些实验性的代码，而不是拉取一个新的分支来写。因为是实验性的，所以我是不会提交的。时间长了，我会忘记我之前写的某个代码放在了哪个工程了，也可能在删除工程的时候忘记这个工程是否有未提交的代码，所以我就经常会找不到我曾经写的代码。
- EOF -
本站文章除注明转载外，均为本站原创或编译。欢迎任何形式的转载，但请务必注明出处，尊重他人劳动。
转载请注明：文章转载自 Binkery 技术博客 [https://binkery.com]
本文标题： 精细化提交代码和提高代码质量的关系
本文地址： https://binkery.com/archives/2020.09.02-精细化提交代码和提高代码质量的关系.html