寻根究底，QA参与代码走查能做什么？
对多时区的场景一直不是很了解，前几天跟波总梳理过一次，当小伙伴们遇到问题，再一起讨论时，发现有些问题依然回答不上来。遂又用案例的形式和师傅探讨了一番，结合实际的生效场景从用户使用的角度去理解，按客户端、按网元、按服务端生效究竟应该是什么样的，应该如何来理解，并和团队QA进行了探讨，更进一步的理解了几个场景。探讨过程中发现，刚开始的时候，是大家把问题想得太复杂，掺杂了太多代码实现层面的业务搅在一起。绝大部分开发人员喜欢从代码层面去细抠，代码自然是很重要的，但比代码更重要的是对业务的理解，对功能场景的理解。这让我想起最近遇到的几单外场故障的复盘，很多改进措施都跟代码走查相关，但代码走查真的就能解决问题么？QA参与代码走查，真的可以很好的防范住问题么？用一个具体的场景来聊聊这个话题:
- 代码走查的时候，开发是对着代码在讲，大家的关注点主要是代码的逻辑是否正确，代码可读性和可维护性是否好，QA虽然参与代码走查，但提问并不多，很难起到我们在故障复盘时，期望能做到的那些点，比如:QA需要时时洞察到代码对功能的波及影响，并根据波及影响去评估是否需要补充测试用例和完善需求或故障验证的波及范围。再比如:看到常量的时候，需要警惕，常量是否意味着边界或异常的场景，是否需要有相关的用例或测试？
要想做到这一点，QA在代码走查过程中，一定要有很强的参与感，并在做代码走查时，多提问，引导开发人员在讲解代码的同时去关注和讲解业务，这样QA也能更好的评估出对功能的影响。有的时候，如果开发人员讲不清楚业务，往往说明这段代码的修改他并没有把业务彻底搞清楚，这样的修改往往是有隐患的。提问的过程，会引导开发人员去反思代码的业务，并引导团队逐步把代码的业务梳理和共享得更好。久而久之，这样的代码走查过程，能引导团队对业务更多的关注，对自己的代码修改也能做到更加心里有数，能更有效的避免问题的泄露。
所以，各位QA同学，下次参与代码走查的过程中，请有意识的尽可能多问一些业务相关的问题，尽可能搞清楚修改代码所波及到的影响，我们才能真正把代码走查的作用发挥得更好。
另外，可以尝试《最重要的事情，只有一件》里面的方法，一段时间只关注一件事情。比如，这个月，QA参与走查时，就有意识重点关注常量、魔法数字的定义。从这里去关注代码修改引发的用例补充和需求测试。当你认为在这个点上的关注已经养成固定的很好的习惯了，再换一个关注点，这样的尝试，坚持下来。QA在团队代码走查中一定能起到很好的作用，而且也更利于QA对团队的整体业务的把控。
筱晓喝橙汁
晚上用榨汁机给筱晓榨了橙汁，放到给她新买的吸管奶瓶里面喝，由于她还不是很熟练，吸了半天也没办法把橙汁吸到嘴里喝，咿咿呀呀着急得不得了。弄了半天，最后把吸管奶瓶的头去掉。直接拿着杯子往嘴里倒，就喝得很过瘾。
妈妈的爱
下班回家，妈妈正在捏荞麦做的饼，煮的正香，我放下东西，确认她不需要我的帮忙，便到房间里开始整理冬天的衣服。整理了一部分，妈妈便夹着刚煮好的荞麦饼到房间里喂我。肚子正饿，荞麦饼很好吃，我给她一个大大的赞。自从妈妈过来带筱晓，每天早上都会记得帮我倒好一杯水，下班回去也基本上就可以直接吃饭了。如果离吃饭还距离，也会提前做点吃的垫肚子。“世上只有妈妈好，有妈的孩子像块宝……”感恩妈妈的悉心照顾，感恩妈妈的爱。
图片发自简书App
