说出来你可能不信，上一秒我还在赛道刷圈速，下一秒就想到了这个话题...
其实这个话题在我待整理列表里躺了挺久的，今天恰好周六，那就静下来谈谈我个人的一些感受。
就以题目里的 2 个问题进行展开吧。
一、是否有必要看开发代码？
对于这个问题，我觉得回答“必要”或者“不必要”都会不太恰当，具体因人而异。
觉得“不必要”
- 对于测试工程师的日常工作，我只要弄得清业务逻辑，通过各种方法论以及测试工具的辅助，一样可以完成需求的测试上。
- 另外，很多时间点都点不过来了，哪有时间去看开发代码呀？
- 再说了，我要是会看代码，那直接去做开发好了。
这是我曾经看到或听到过的一些观点，有主观、也有客观的，对此我个人表示非常理解。
阅读开发代码，这事情其实不在我们常规定义和理解的本职工作范围内。而且，当工期紧，压力大，点都点不过来的时候，面对这些事情，就会更加心有余而力不足。
一心只想快点把用例执行完，回归完毕顺利上线，我自己有时候也是这个样子。
还有，对于有些代码基础薄弱的童鞋，对代码会有一定的“恐惧感”，这就更正常了。人对未知事物的恐惧是与生俱来的，但是我们要去接触学习它，否则就陷入死循环了。
觉得“必要”
我个人是比较偏向于这个答案的，但是前提条件肯定还是得时间允许，当然这个时间也可能是挤出来的。这些我自己都有过经历，先来回顾一下。
有时间
最近参与了一个比较大的项目，负责其中部分模块的测试工作。对接的人，都是来自别的事业部的同事，我一个都不认识。
所幸现在还留有一定的测试点梳理时间，我于是申请了项目代码权限，拉取代码到本地，重点浏览了我要测试的接口相关代码。
因为要测试的接口中，很多底层处理涉及到另一份外部文档里的接口调用，但是我发现，存在好几个接口是没接入的。立马整理出来确认，明确是不接入的，也就是说我是不用测的。
但是这个事情在产品和开发提供出的文档里是没有说明的，这里就不去说谁的责任问题，或许是太忙忘记了，也都可以理解。
如果我不读代码，我对着文档写用例，必然把这几个也写进去了，大概率是要到评审用例时候才会发现。
没时间
领导有布置大家整理各自业务的文档，从系统交互、业务逻辑、场景构造、监控报警等方面，这个事情是有积极意义的，但是需要我们“合理”安排时间来做。
合理就是，不忙的时候工作时间整，忙的时候下班抽空整，大家都懂得。
我拿到一块不熟悉的业务，所幸这个业务逻辑不是很复杂，重点是接口逻辑的梳理。
首先肯定还是先把能搜集到的文档先浏览一遍，再去找开发问一些疑问点之类的。但是开发很忙（或者假装忙），如果不当面问，大概率回复得晚，咱也不能怪人家。
那我就要了项目权限，找到相关接口的代码，看下里面的是否存在一些特殊处理需要校验，是否有涉及到缓存，MQ 等。所幸这个开发的代码注释写的还比较详细，所以看起来比较轻松。
如果我不读代码，可能整理的进度大概率变慢，而且老是问开发，说不定人家会很烦。
但并不是说烦我就不问了，最好的办法是你可以抓住重点，高效的提问。
所以，我个人感觉去看开发代码还是受益多多的：
- 尽早的发现一些不必要的问题，更精确的确定测试范围。
- 可以更加了解开发的实现逻辑，有利于有的放矢，高效提问。
- 知道开发本次改动的范围，有助于判断是否有其他不必要的改动（或者带上线的别的内容）。
- 更精准的定位开发问题，有助于分析问题根因。
- 倒逼自己学习更多的开发知识。
二、如何能看懂开发代码？
相信有不少童鞋也想去阅读开发代码，但是不知道该学习到什么程度才可以看得懂。
不要怕
首先我觉得是不要怕。
其实，对于很多常规的项目，抛开一些架构模式设计的话，要看懂后端代码逻辑其实并不难。
比如我测试的项目中就有使用 C# 语言写的，我之前看都没看过，但是没办法，网上了解了一点语法之后就硬着头皮看，配合开发注释大概也可以了解7788。
代码学到何种程度？
当然，如果是一门你不了解的语言，还是要进行一些基础知识的学习的，但是肯定不需要全面学习完之后才可以。
比如你写自动化用例用 python，而开发使用的是 java ，就觉得学习 java 是一个从0开始的事情。其实不然，各种编程语言除一些设计理念外，核心点不外乎就是那几个。
更何况像 python 和 java 都是面向对象的，它们有很多地方都比较接近，所以说，能看懂 python 代码，学习一下后也能看得懂 java 代码。
除了语言基础知识之外，再了解下开发框架相关知识（比如 spring），了解下分层和常规用法，基本上也就可以了。
有条件的，也可以自己参考开发的项目，自己按照分层来写个接口来进一步理解。
看代码的心得
要看代码，首先最重要是你得能找到目标代码。
最省事的方法是：问开发。
然后就是自己动手了。以我的经历来看，通常我肯定是有个关注的接口，我知道接口的路径名称，也大概知道开发的代码项目分层，基本上就可以找到接口入口了。
以之前java的测试平台项目为例，当我找到了入口，就可以进一步找到这个接口的 service 层，里面有更多的实现细节。
再通过 idea 工具的辅助，不断的跳转里面各种调用的方法，查看逻辑实现情况。
另外，我推荐使用 idea 的代码定位功能，可以帮助你了解项目的层级结构。
但是也不是所有项目都是像上面这样简单，有些项目就有很多的子模块，每个子模块下面也有很多的代码；还有项目是 dubbo 服务，结构又不一样了。
这种情况我会使用 idea 的全局搜索，去查接口名称，基本上都可以搜到，最次也可以搜小排查范围。
总结
说了这么多，最后总结下吧。
个人觉得有条件的（没条件的可以创造条件），还是尽量去尝试阅读开发的代码，从目前来看，除了需要你挤出一些时间也没啥别的毛病了。
更何况，你挤出的这点时间是有收获的，不是浪费时间。
至于代码要看到多细，那还是取决于你个人的目的了。总之，多学学没坏处。