背景

随着技术的发展，大至一线互联网公司、小至几十人研发团队的公司都开始开展devops运动。大公司有能力自研，小公司则采用开源解决方案。如何实施devops业界已经有非常成熟的方案，所以本系列不再谈devops工具链以及如何实施。本系列想谈谈在devops中容易被忽略的一些细节，但是这些细节却是非常重要的，提升这些小细节将会提升整个团队的研发效能。

忽视单元测试

很多研发团队每天淹没在无穷无尽的需求中，每天加班加点的开发，但是交付的需求上层也不满意。上层继续施压，底层开发人员再次被压榨，根据我们长期观察发现。很多研发团队每天很忙，其实是因为每天不得不花大量的时间解决各环境包括生产环境的Bug，导致其新需求的研发时间被压缩，为了赶上新需求的进度，开发人员不得不加快自己开发代码的速度，进一步导致代码质量下降，产生更多Bug，长此以往，团队的研发效率大大降低，研发人员苦不堪言。
我们发现，出现这种问题的团队，大多都没有编写单元测试的习惯。很多研发团队其实知道编码单元测试会有效提示团队代码质量，但是他们觉得需求尚且不能按时交付，如果再花时间去编写单元测试，那么将可能导致延期，这个认知其实是不准确的。下面我们看两组数据，第一个图是bug在不同测试阶段被发现时的成本

第二个图详细的展示bug在不同测试阶段被发现反馈周期时长和解决成本，可以看出不论是反馈周期和解决成本，单元测试都是比较低的，所以，投资单元测试来提升团队代码质量是值得且有必要的。

单元测试还有一个非常重要的作用，就是为我们做代码重构提供基础保障。试想一下，当你看到一段祖传代码想重构时，如果没有单元测试，你敢动吗？反正我是不敢，有了高质量的单元测试，你可以大胆的重构来减少团队代码的“屎山”。

忽视需求协作

我见过很多团队在开发需求时，为了追求所谓的快，他们和产品的交流经常采用口头的方式，不是说口头的方式不好，面对面的交流是项目开发必要的，但是我们不能仅采用这种口头的方式来做需求协作，口头的东西缺乏记录，不方便管理、跟踪。
还有些团队初步采用了需求协作管理工具，比如TAPD、JIRA，但是需求拆分的方式不合理，导致开发人员在开发过程中经常困惑。比如没有形成统一的规范，需求的粒度拆分得五花八门，每个人都有自己的一套方式，这种不是协作，协作必须要团队形成一定的共识，知道在需求单中每种需求单代表的意义，以及如何管理一个版本或一个迭代的需求。在后续的文章中，会介绍一些我之前的经验

忽视代码重构

很多开发人员对代码有两个误解，其一“代码是一次编写，永远不变”，其二“代码自己看得懂就OK”。代码是公司的资产，不是个人的。如果是个人的私有项目，你技术好经常在代码写一个比较骚的炫技手段无可厚非，但是在公司项目中，代码不是只有你在看，是整个团队在未来都可能参与维护，如果代码融入太多骚操作，会大大提升他人的理解成本，扯远了
不知道大家有没有感觉，当你一两个月之后回去看自己的代码时，第一反应可能是觉得这代码“真屎”。很多人觉得我们的代码都写好了，线上也运行的好好的，干嘛要重构，可能还会引入风险。但是很多时候我们的代码一开始并不复杂，但是随着业务的开展，它的复杂性随着提升，比如我们之前做互联网金融时的一个场景，一开始我们只有一家支付第三方开发人员可能直接硬编码，但是随着业务增长，我们接入第二家，这时候开发人员可能直接加一个if-else，很多公司是这样的，直到我们接入第三家，这个时候如果还是加一个else，那么代码的理解成本必然大大提升。所以我们要重构代码。
我们平时开发代码时，通常的想法是大致设计一下，然后迅速开发出第一版，这一版通常实现了功能，但是是很粗糙的，然后我们会不断重构打磨代码。这是一个正常的开发流程，并不是每个人都厉害到一遍就可以把代码写好，多数人是做不到的，但是利用代码重构可以让自己的代码质量不段提升

忽视代码评审

最后想谈论的一个话题是代码评审，我见过很多团队在Merge代码时都没有这一步，这一步其实非常重要。如果不做这一步，我们团队代码风格很难统一，代码中的一些问题可能也会漏掉。上边我们提过，代码不是写给自己看的，而是写给团队中所有成员看的，如果加入代码评审环境，评审人如果都看不懂，那多半团队其他成员也很难看懂，那么其实这段代码又是汇入Master分支的“屎”，在未来为了维护这坨“屎”必将花费更多的成本
或者有些公司虽然有代码评审的环节，却只是一种走过场的形式主义，比如很多公司把代码评审放到一周某一天来集中做，每个人可能在这时候提交几千行代码，团队那么多人，仅仅利用短短的几个小时想看这么多代码，根本不可能看完。况且一次性提交几千行的代码，逻辑可能都看不懂，最终导致的结果可能就是只能看出一些代码规范的问题，而更深层次的设计问题可能就漏掉了。
如果有效开展代码评审，在后边会详细讨论，如何在一个完全没有代码评审的团队中如何建立起代码评审机制。

总结

研发效能工程实践远远不止这些方面，我只是想把自己经历的经验分享给大家，希望能给到大家帮助，打造一个敏捷团队，解放生产力，提升团队交付能力。