蚂蚁搬家式的代码修改-源码版本管理工具

2025.07.12
成为程序员之后，其实会在进步的路上遇到很多问题。公司当然是已经把从研发到生产到销售的环节打通了，但是随着业务越来越多，之前的管理模式不一定适用于现在的管理范围，而且，领导们都在变老，他们的思维固化也很严重，或者他们并不愿意给手下的员工更多建言献策的机会。所以有很多我们作为一线员工能够看到而没办法改变的问题。但是，我知道我看到了，我必须让我自己避免这些问题。

这其中一个很重要的问题就是“蚂蚁搬家式的代码修改”。随着代码版本越来越多，往往在不经意间就写了很多bug进去。因为硬件测试需要环境，但是很多时候并不能够及时的在正确的环境上进行完整的测试，而且测试结果的质量往往和测试人员的经验有强相关。这就导致了当你最终发现的时候，这个bug已经隐藏的很深，进而很难进行排查。这才是项目维护成本高昂，维护周期较长的最大问题。

最好的办法就是进行“蚂蚁搬家式的代码修改”，将不同的功能拆分成不同的版本进行添加和备份，以至于在未来爆出某个功能隐藏很深的bug时，能够 通过修改的版本进行精确的定位。

“蚂蚁搬家式的代码修改”指的是将不同功能或者打大段的代码修改进行拆分，这样做就会需要大量的版本号去进行编码和备份，以致于每一个版本都有一个独特的版本号。看似简单的目的，执行起来是比较难的。主要有几个问题：

• 代码采取分布式管理，实际就是存放在不同的电脑里，不能直观方便的进行代码全流程溯源
• 代码的版本记录依靠共享EXCEL表格，只能用版本号一个个查找，无法直观的看到代码分支
• 一个代码版本的编号产生，依靠在EXCEL表格中查找，未登记编号的就可以使用，编号没有规则
• 代码版本的编号有限，现在使用xx.xx四位数进行编号，在实际执行过程中位数是不够的
• 客户端无法方便的查找需要的固件型号

在这样的情况下，我们的工作也在正常的进行，但是给开发人员的版本号使用带来了很大的不便，很多版本号被分割的断断续续。大家也不喜欢用更多的版本号去分割不同的功能。很多人都是修改十几个bug才更换一个新的版本号，或者添加了10个功能才更换一个新的版本号。这就产生了上边的终极问题——排查隐藏bug的时间人力成本高昂。当然，我也一样，我没有办法避免这个问题，但是我希望能够把我所能掌控的程序按照我的想法进行修改，验证过的功能用版本号进行单独的分割，放在我自己的版本管理软件中。总的流程就是，拿到需求，确认方案，拆解方案，支持A功能，验证A功能，版本管理软件记录A功能，然后B功能，C功能，D功能…

FPGA的版本管理可是非常不容易的，而且也没有什么软件进行支持，不然我们团队也不会还使用excel进行管理。这点我甚至不需要怀疑。除了excel之外，我们还使用SVN进行代码管理，但是现在好像已经很久没有进行过代码的上传了，都是保存在自己的电脑上。我在没有学习过代码管理软件之前，尝试用树状图和excel来记录修改记录，其实是很难受的，你没有办法直接用树状图或excel打开对应版本的代码，因为文本和源码是分离保存的，只能来回切换的去看。后来觉得实在不行，又学着别人去给源码文件夹加后缀和备份，修改了什么直接在源码文件夹命名就可以看出来。但是，源码命名就那几个字，你写再多它也不够细致，所以还是不行。然后，我去学习了git和SVN，这两个软件倒是开发的挺完善的，但是并不适用于FPGA程序的开发以及和同事的配合（主要因为不是团队使用）。那些软件都是使用的分支结构，为了能够在团队内开源，进行团队协作，最终程序通过合并放在服务器上。而fpga可没有什么树状结构，往往都是一个一个个没有关系的工程，不可能给你开什么分支，也无法在服务器上编译和验证，再加上对比不方便，会在源码文件夹中建立仓库导致没有办法一键分享等问题，我就又更换了。换到了第一个直接文本和源码对接的模式。

第一个版本是在excel管理模式上的升级。首先我会使用bat代码，直接创建一系列的文件夹，然后把文件夹的目录放在excel中，对目录中的版本更新进行记录，做到看着excel的内容可以直接在旁边打开对应的代码进行对比。这个模式采用的是EXCEL可以调用相关bat文件，bat文件再去执行一系列的文件夹操作。这个bat文件也是第一次使用，当时想到的只是想把分开存储的EXCEL登记表和源码联系起来，才知道原来excel可以直接打开相应的文件夹。这个模式用了有1个月吧，用下来整体感觉还好，就是在存储到相应文件夹的时候需要先打开文件夹然后再复制进去，再把相关的路径放置在excel表格的对应位置，这样子也可以直接根据写的注释打开相关源码文件。后来觉得这个写入的流程还可以优化一些，最好是有一个类似于git的软件，更方便的做这件事。

这个时候python出现了，没有别的原因，只是因为相对完整的项目我只在python上做出来过。在上大学的时候用ai写过python代码，那个时候的AI只有chatgpt3，还得挂个梯子。当时每天要两个小时通勤去实习，但是也不得不完成相关的毕业论文，很不幸的是我还遇到了很严格的老师（这个老师是因为被抽查到翻车了，所以很严格）。每天白天通勤到实习单位和学校的老师远程对线，晚上熬夜修改白天对线的成果，时不时还得联系单位的领导带我去采集一些数据。还有一个重要的原因，是晚上的时候chatgpt3的网速一点都不卡，可以非常顺畅的帮我解决一些问题。

就用这一点经验，我打开了kimi，想让它帮我搭建一个框架。我的要求是“有GUI界面，能够建立项目，左侧为项目列表，右侧为版本列表，可以支持注释”，就这样写出来了第一个版本的，代码版本管理软件。当然，说起来简单，第一个版本也重复修改了很多次，才把基本功能给实现。在这个基础上，我又给支持了一键上传和版本回滚的功能。差不多就这些功能，用了我大概一周时间。大概70个版本的修改。实现了一个可以在本地以项目为单位进行管理代码版本的软件。

我开始在自己的项目和工作中去实际的使用这个软件，真的很不错，在用了一周之后又更新了一些功能，然后我把这个软件分享给了我的朋友，希望他们也能够使用，然后给我踢出一些建议。过了几周之后，我收到了一些正反馈，他们都觉得这个软件对于我们现在的工作有很大的帮助。当然，也有提出了一些他们的小众需求，但是我的能力似乎没有办法去解决，这也是遗憾。

上边所写的，蚂蚁搬家式的版本记录，我不知道why，我们的团队做不到。也没有人去主导这些事情。也许船大难掉头，也许是从上至下的没有奖惩措施，像吃大锅饭一样，没有些许的按劳分配。

下边是这个软件的界面：

对于这个ai写代码的看法，在这个项目之后也有了一些认识。实话实说，这很难，让ai做事简直像开盲盒一样，你不知道他会做成什么样子。ai写代码的水平。豆包>kimi>deepseek。

感谢大佬，灵感来源：https://fpga.eetrend.com/blog/2023/100568659.html