在GEHC的第一个sprint记录

今天是进入GEHC XR ATX的第25天，是周日，下周二我的第一个sprint也就到期了，幸好在这周五晚上完成了，当然还差个分享。在此记录第一个sprint中两个story过程。

第一个story是操作固定式DR设备进行exposure整个过程。这是所有新人必选story，流程上是我需要先在实验室学习、了解DR设备，包括硬件和软件。熟悉了之后，需要发送邮件预约demo的时间和地点。到点了组内所有成员都会来参加，琼哥会提问题，我根据琼哥提的问题进行操作或解答。这个熟悉的时间还是比较充裕的，差不多从入职第一天开始，当然期间也杂加着各类培训及权限申请。我差不多有两周时间。但其实我熟悉并不够，一方面是我对这方面确实没有一点经验，另一方面就是资料缺乏，基本靠口述和我自己找资料，还有就是不清楚问题范围，不知道我应该关注什么。在做demo的时候，好多细节没有做好，我机器实操的次数也挺少的，因为机器有限，需要主动找测试老师们去借，说实话，我不太好意思，或者我根本不知道我要解决什么问题。最后我还选了比较复杂的DR系统，直至当天上午我才真正接触了该系统，demo结果也就可想而知了，琼哥他们当然最后也给了合格。总结以下，我还没搞清楚我到底要干什么，懵懵懂懂，而且不敢主动问问题，这是不好的，需要改进的，不懂就问。

第二个story是修复SonarQube中关于unit tests数据展示问题，因为coverage都是有数据的，不知道为什么unit tests的数量一直不显示，整个项目组的都是这样。关于这个story，我开始理解的是给SHM项目增加unit tests，然后做一个关于unit tests的设计分享，因为SHM项目中并没有unit testing，在QA数据上说不太过去。我其实之前也没怎么写unit testing，不，应该是不写，写了代码之后，直接用postman做冒烟测试，测试通过，后续的测试工作就交给了测试老师了。现在的团队中没有类似的角色了，所以需要开发人员注重unit testing，而且QA页面也需要展示该数据。当时我看unit testing的coverage是有数据的，但是只有4.5%，unit tests为-，没有数据。我以为我需要增高unit testing的coverage，后来在一次daily scrum上，琼哥问了我，说实话，我当时没听清他的问题，所以回答也模糊的，反正后来就变成了要展示出unit tests的值，当然，这也是忠靖最开始给我设定的目标，但是后来发现要展示这个数据并没有这么简单，我们在排查这个问题时，通过修改sonar.properties配置参数后，test的代码确实可以展示到页面了，但是unit tests数据依然为空，所以推测是jenkins中关于sonar scanner的配置有问题，于是联系DevOps人员进行解决，但是这个问题注定没有太快解决。分配的人员是印度老哥，工作时间就差了2.5个小时，反馈问题后半天都没反馈，最后让提供log，我开始也没搞懂，我理解我只要提供了jenkins的pipeline信息就可以，他应该就能找到，结果并没有这么简单，不过他倒给我提供了问题解决的思路，不过这个简单思路我自己倒是忘了。解决bug的第一要义就是定位bug，也就是通过log去找，于是我又向强哥学习了如何构建pipeline，这样就不用总是麻烦他了，不过构建一次pipeline真是耗时，得一个小时起步，这就很难受了，不过幸好还是熬到了，但是最后发现日志中也没有什么有用的信息，最后还是结合网友的blog和官网文档找到问题，就是自定义sonnar scanner的配置有问题，coverage数据来源和unit tests的数据来源是两个文件，coverage来自jacoco，unit tests来自surefire，所以页面一直有coverage数据，但unit tests数据没有，在配置文件中指定surefire数据源就可以了。所以，自己的命运要掌握在自己手里，等待别人总不是最好的选择，当我告知DevOps的老哥问题已经解决了时，他回复说他很忙在决解其他问题，问我怎么解决的，在我委婉的表达没关系时，他居然急着问我解决方案，说他得用这个来关闭我在channel中提的问题。怎么说呢，打铁还需自身硬吧，我是程序员，这点问题算啥。

上面两个story是常规的，做完也就算合格吧，还有一个隐藏的story，那就是关于unit testing的design分享，这个确实有点难，因为我也没写过unit testing。只能硬着头皮干吧，分享定在了下周一下午4点到5点，也就是明天了，现在整体思路还没有。