「数据库」微服务化的基石——持续集成( 三 ) |Java|美好，一直在身边|DevOps|

本文插图
Scrum
每天早上第一件事情，就是开站会standup meeting ，为什么要站着呢？因为时间不能太长，微服务的一个模块，大概需要5-9人的团队规模，如果团队规模太大了，说明服务应该进行拆分了，这个团队规模，是能够保证比较短的时间之内过完昨天的状态的。
一定要大家一起开，而不要线下去更新Jira ，虽然看起来一样，但是执行起来完全不一样。只有大家一起开，一起看燃尽图，一起说我昨天做了什么，今天打算做什么，有什么阻碍，才能够让大家都了解情况，不要期望大家会去看别人的Jira ，经验告诉你，不会的。
而且这个站会对于开发是比较大的压力，例如你的一个功能block了依赖方的开发，在会议上会暴露出来，大家都知道这件事情了，一天block ，两天block ，第三天你都不好意思去说了，这会强迫你将大任务，比如原来写1周干一件什么事情，写成小时级别，这样每天你都有的说，昨天完成了一个task ，而不是周只在那里说干同样一件事情，而且一旦有了block ， team lead会知道这件事情，会帮你赶紧解决这个事情，推进整个项目的进展。让一个技术人员在团队面前承认这件事情我尝试了几天，的确搞不定了，也是一种压力。
站会中的内容其实在前一天晚上就要开始准备了。
持续集成要求每天都提交代码，这样才能降低代码集成的风险，不能埋头写一周一起提交，这样往往集成不成功。怎么样才能鼓励每天都提交代码呢？一个就是第二天的站会，你这个功能代码提交了，单元测试通过了，第二天才能说做完了，否则不算，这就逼得你，将大任务拆成小任务，每天都多次提交。
而且Git的提交方式，是后提交者有责任去merge ，保证代码的编译通过和测试通过，你会发现，如果你不及时提交，等你改了一大片代码，别人都提交完了，这一大片的冲突都是你来merge ，测试用例不通过的你来fix ，所以逼的你有一个小的功能的改动，就尽早提交， pull一下发现没有人提交，赶紧提交。
提交不是马上进入主库，而是需要代码审核，这是把控代码质量的重要的环节。
代码质量的控制往往每个公司都有文档，甚至你可以从网上下载一篇很长很长的Java代码规范。但是我们常常看到的例子是，规范是有，但是虱子多了不咬人，规范太多的，谁也记不住，等于没有规范。
所以建议将复杂的规范通过项目组内部的讨论，简化为简单的10几条军规，深入人心，大家都容易记住，并且容器执行。
代码审核往往需要注意下面的几方面：

代码结构：整个项目组应该规定统一的代码组织结构，使得每个开发拿到另一个人的代码，都能看的熟悉的面孔。这也是scrum中提倡的每个开发之间是可替代的，当一个模块有了阻碍，其他人是可以帮上忙的。至于核心的逻辑，估计审核人员也来不及细看，这不要紧，核心逻辑是否通过，不能靠眼睛，要靠测试。
有没有注释，尤其是对外的接口，应该有完善的注释，方便自动生成接口文档。
异常的处理，是否抛出太过宽泛的异常，是否吞掉异常，是否吞掉异常的日志等。
对于pom是否有修改，引入了新的jar 。
对于配置文件是否有修改，对外访问是否设置超时
对于数据库是否有修改，是否经过DBA审核
接口实现是否幂等，因为Dubbo和springcloud都会重试接口。接口是否会升级，是否带版本号
是否有单元测试

当然还有一些不容易一眼看出来的，可以通过一段时间通过统一的代码review ，来修改这些问题：