芯耀
703
来源：公众号【鱼鹰谈单片机】，作者：鱼鹰Osprey，ID ：emOsprey
大家好，我是鱼鹰。今天和大家聊聊鱼鹰自己经历的情况。
从毕业到现在，鱼鹰也换了不少公司。从私企到外企，代码审查一直都在变化。
实习那会，基本没有代码写，也就无所谓代码审查。
毕业后在一家上市公司的子公司，第一次知道原来代码是需要定时上传到公司服务器的，而不是留在自己电脑中，当时用的 svn。
而当时自己还接了一个遗留的项目，看到里面的工程文件夹占用空间特别大，还以为是代码本身就很大，后面才知道，原来是使用 git 管理的，里面的 .git 文件夹占用很大（后面直接删掉了，因为那个时候鱼鹰管理版本的方式是复制粘贴文件夹），但那个时候自己不是很懂 git，不然看看前同事写的提交记录也是不错的学习机会。
后面入职一家创业公司，第一次用上了 git，那个时候好像没什么代码审查（可能待的时间短），修改后直接上传了。
后面在一家上市公司，可能是因为项目处于开发阶段，因此项目审查比较简单。
刚开始只有 leader 会简单看一下，一般提了 PR （pull request）一天内可以合并到主分支，如果比较着急的话，和 leader 说一声，一小时以内就可以合并。
后面项目到了小批量的生产阶段，开始组织大家一起开会看大家提交的代码，但是都是先很快合并后再具体看代码的。
大家聚在一起查看各自代码提交，提交的同事负责讲解功能和代码，大家一起听是否有问题。
感觉那个时候主要是自检，同时其他同事根据自己的经验看他的代码是否对自己或他人有影响。
什么空格、大小写、空行，换行，都不管。
只要你的功能没有问题就可以。这得益于我们测试团队的充分测试。如果有问题，基本在各种测试中就发现并快速解决了（机器基本是24小时不间断运行的）。
所以那个时候，大家的效率很高，个人感觉开发起来很顺畅，有一些想法也可以很快验证并集成到代码中测试。
后面到了外企，感觉各种限制。测试只有一个人白天测试，晚上基本不会进行测试。很多新开发的功能，稍微复杂一点，就很难合并到主分支测试。合并时，要求有一个同事查看并同意才能合并。因此代码质量，基本是靠自测来保证，而往往自测是不够充分的。嵌入式开发自测有哪些局限性？
后面换项目后，和老外合作开发，限制更多了。
首先是时差，我们上班时，他们一般下班了，所以很难及时沟通问题，现场找人更不现实。
其次是感觉老外是一个严格的机器，一个空格、空行，函数名、变量名、大括号另起一行等等细节都有要求（神奇吧，很多细节问题竟然是靠人而不是靠自动化检测）。
所以即使是简单的改动，也可能需要一两周甚至一个月才能合并到主分支。
这就导致一个问题，我们不可能等这个功能合并之后再测试，因此我们有单独的测试分支，先自行提交到测试分支后，再提 PR。
这又会导致另外的问题，由于 PR 可能被审查者要求修改，因此会导致测试分支渐渐的和主分支开始出现差异，加上合并时间的延长，我们会积累很多提交在测试分支还未提 PR（我们要求一个功能一个提交，不能合并一个提交）。
而已提交的 PR，因为拖的时间太长，有可能和主分支产生冲突，因为有可能其他人在你之前合并同一个文件的代码。
我们需要花大量的时间来回解决修改意见，如果产生冲突，还需要解决冲突问题，如果多个 PR 有依赖关系，需要顺序提交才可（由于测试分支和主分支的差异，又需要花时间整理 PR 该如何提才合适），这又进一步延长了功能的合并时间。
总之，提交 PR 与鱼鹰而言是一件非常痛苦的事情。
渐渐的，你发现自己没有什么开发热情了，因为即使你开发了代码，也不知道猴年马月可以合并进去。更何况你需要花精力处理冲突、反复关注 PR 的最新评论。
在鱼鹰看来，合并时很多细节是不用管的，只要保证功能运行正常就行。那些细节问题只是锦上添花，可有可无（当然基本的开发习惯过得去，别像初学者一样，全局变量一堆、变量名就一个字母，空格、空行不舍得用）。
不知道各位道友，你的公司是如何合并代码的？对此又有何看法？
