code review和ci的一点点小体会

本文由Markdown语法编辑器编辑完成。

最近这段时间，工作稍显繁忙，没有太多的时间，进行系统性的总结，仅以最近的一些code review和ci, 写一点小体会。

1. CodeReview:

CodeReview, 代码审查，即在将自己的代码merge到主分支之前，程序员将自己的分支，与服务器上的代码主分支，创建一个merge request，指定给有相应权限的同事。该同事在收到merge request的请求后，对提交者的代码进行审查，对代码规范，逻辑问题，以及其他代码问题，提出修改建议。提交者在收到意见后，针对意见修改后，再次提交merge request. 直至所有的代码问题都解决后，将本次merge request的分支合并到主分支。

另一种CodeReview, 是我所在的工作组内的一个传统活动，主要是全组的同事，每周选取一个特定的时间，然后针对某个同事在某个项目中的代码，进行全体的review。一方面是让大家彼此都能了解各自在做哪方面的工作，另一方面，构建一个相互之间，切磋编码水平，相互学习，相互提高的平台。

我依然记得，在我刚参加工作的那一年，公司就有code review的机制。我将自己参加工作后，第一次写的项目代码，提交code review后，收到的上级给我的代码评审意见。代码量可能也就是100行左右，提的审查意见就有10多条，涉及到了编码的方方面面的问题。当时，在收到代码评审的内容后，真的是有点无地自容，也暗暗的鼓励自己，以后在提交代码时，一定要注意自己的代码质量，多多测试，对自己交出去的代码负责任。随着工作的深入，在项目的后期，当我再次提交代码审查的时候，已经很少再有需要修改的地方了，很多都可以直接通过审查，合并到主分支。现在想到自己的代码，已经在很多的医院的服务器上，每天在稳定运行着，心里面还是有很多成就感的。

组内的code review, 一般则是负责分享的同事，对着代码，先讲一遍逻辑。然后接下来一周，其他同事进行线下的code review, 然后第二周再集体进行分享，对之前同事的代码提出修改建议。

对于自己了解逻辑的代码，review起来，更多地是看一些语法方面的问题。

2. CI (Continuous Integration)

CI的字面意思就是持续集成，主要用于敏捷开发中。由于敏捷的项目是在持续地进行迭代，因此随着项目不断地深入，功能特性会越来越多，相应的测试用例也会成倍地增加。
如何能够保证项目在不断地迭代开发中，不会因为增加某一个新的特性而影响原来的功能点；或者是在修复一个代码的bug时，不至于时间太紧迫或别的原因，而导致引入新的bug。
因此，引入持续集成的概念。这样，每当有新的代码提交后，就会触发代码仓库，对当前的代码进行集成，运行过去撰写的测试用例。这样，如果某一条测试用例，在前一个版本的代码中可以顺利通过；而运行新版本的代码后，就无法通过时，就很容易地定位到问题点——到底是，由于测试用例没有根据新的需求进行更新；还是由于增加新的特性，而影响了原来的逻辑。

CI到底有多么有用呢？这个或许只有真正体验到它给自己的工作带来多少便捷，才有话语权。
就我们项目组而言，自从在某一个迭代中，专门增加了CI的机制后，大概一个多月的时间内，已经至少帮我们预防了四五个重要的bug。试想，如果不是CI帮我们测出了问题，一旦项目代码部署到生产环境后，造成的损失和修复的成本都会成倍增加。因此，花费一定的时间，在自己的项目中，引入持续集成，将会是一个事半功倍的选择！

当然，CI也不是万能的，也不能把全部的希望都寄托在CI上。因为毕竟CI的代码，也是开发撰写的。CI到底能够在多大程度上覆盖所有的测试case，决定了CI的可信度。因此，并不是CI通过了，项目代码就一定没有问题了。因此，我们需要辩证地看待这个问题。