說出來你可能不信，上一秒我還在賽道刷圈速，下一秒就想到了這個話題...
其實這個話題在我待整理列表裡躺了挺久的，今天恰好週六，那就靜下來談談我個人的一些感受。
就以題目裡的 2 個問題進行展開吧。
一、是否有必要看開發程式碼？
對於這個問題，我覺得回答“必要”或者“不必要”都會不太恰當，具體因人而異。
覺得“不必要”
- 對於測試工程師的日常工作，我只要弄得清業務邏輯，通過各種方法論以及測試工具的輔助，一樣可以完成需求的測試上。
- 另外，很多時間點都點不過來了，哪有時間去看開發程式碼呀？
- 再說了，我要是會看程式碼，那直接去做開發好了。
這是我曾經看到或聽到過的一些觀點，有主觀、也有客觀的，對此我個人表示非常理解。
閱讀開發程式碼，這事情其實不在我們常規定義和理解的本職工作範圍內。而且，當工期緊，壓力大，點都點不過來的時候，面對這些事情，就會更加心有餘而力不足。
一心只想快點把用例執行完，迴歸完畢順利上線，我自己有時候也是這個樣子。
還有，對於有些程式碼基礎薄弱的童鞋，對程式碼會有一定的“恐懼感”，這就更正常了。人對未知事物的恐懼是與生俱來的，但是我們要去接觸學習它，否則就陷入死迴圈了。
覺得“必要”
我個人是比較偏向於這個答案的，但是前提條件肯定還是得時間允許，當然這個時間也可能是擠出來的。這些我自己都有過經歷，先來回顧一下。
有時間
最近參與了一個比較大的專案，負責其中部分模組的測試工作。對接的人，都是來自別的事業部的同事，我一個都不認識。
所幸現在還留有一定的測試點梳理時間，我於是申請了專案程式碼許可權，拉取程式碼到本地，重點瀏覽了我要測試的介面相關程式碼。
因為要測試的介面中，很多底層處理涉及到另一份外部文件裡的介面呼叫，但是我發現，存在好幾個介面是沒接入的。立馬整理出來確認，明確是不接入的，也就是說我是不用測的。
但是這個事情在產品和開發提供出的文件裡是沒有說明的，這裡就不去說誰的責任問題，或許是太忙忘記了，也都可以理解。
如果我不讀程式碼，我對著文件寫用例，必然把這幾個也寫進去了，大概率是要到評審用例時候才會發現。
沒時間
領導有佈置大家整理各自業務的文件，從系統互動、業務邏輯、場景構造、監控報警等方面，這個事情是有積極意義的，但是需要我們“合理”安排時間來做。
合理就是，不忙的時候工作時間整，忙的時候下班抽空整，大家都懂得。
我拿到一塊不熟悉的業務，所幸這個業務邏輯不是很複雜，重點是介面邏輯的梳理。
首先肯定還是先把能蒐集到的文件先瀏覽一遍，再去找開發問一些疑問點之類的。但是開發很忙（或者假裝忙），如果不當面問，大概率回覆得晚，我們也不能怪人家。
那我就要了專案許可權，找到相關介面的程式碼，看下里面的是否存在一些特殊處理需要校驗，是否有涉及到快取，MQ 等。所幸這個開發的程式碼註釋寫的還比較詳細，所以看起來比較輕鬆。
如果我不讀程式碼，可能整理的進度大概率變慢，而且老是問開發，說不定人家會很煩。
但並不是說煩我就不問了，最好的辦法是你可以抓住重點，高效的提問。
所以，我個人感覺去看開發程式碼還是受益多多的：
- 儘早的發現一些不必要的問題，更精確的確定測試範圍。
- 可以更加了解開發的實現邏輯，有利於有的放矢，高效提問。
- 知道開發本次改動的範圍，有助於判斷是否有其他不必要的改動（或者帶上線的別的內容）。
- 更精準的定位開發問題，有助於分析問題根因。
- 倒逼自己學習更多的開發知識。
二、如何能看懂開發程式碼？
相信有不少童鞋也想去閱讀開發程式碼，但是不知道該學習到什麼程度才可以看得懂。
不要怕
首先我覺得是不要怕。
其實，對於很多常規的專案，拋開一些架構模式設計的話，要看懂後端程式碼邏輯其實並不難。
比如我測試的專案中就有使用 C# 語言寫的，我之前看都沒看過，但是沒辦法，網上了解了一點語法之後就硬著頭皮看，配合開發註釋大概也可以瞭解7788。
程式碼學到何種程度？
當然，如果是一門你不瞭解的語言，還是要進行一些基礎知識的學習的，但是肯定不需要全面學習完之後才可以。
比如你寫自動化用例用 python，而開發使用的是 java ，就覺得學習 java 是一個從0開始的事情。其實不然，各種程式語言除一些設計理念外，核心點不外乎就是那幾個。
更何況像 python 和 java 都是物件導向的，它們有很多地方都比較接近，所以說，能看懂 python 程式碼，學習一下後也能看得懂 java 程式碼。
除了語言基礎知識之外，再瞭解下開發框架相關知識（比如 spring），瞭解下分層和常規用法，基本上也就可以了。
有條件的，也可以自己參考開發的專案，自己按照分層來寫個介面來進一步理解。
看程式碼的心得
要看程式碼，首先最重要是你得能找到目的碼。
最省事的方法是：問開發。
然後就是自己動手了。以我的經歷來看，通常我肯定是有個關注的介面，我知道介面的路徑名稱，也大概知道開發的程式碼專案分層，基本上就可以找到介面入口了。
以之前java的測試平臺專案為例，當我找到了入口，就可以進一步找到這個介面的 service 層，裡面有更多的實現細節。
再通過 idea 工具的輔助，不斷的跳轉裡面各種呼叫的方法，檢視邏輯實現情況。
另外，我推薦使用 idea 的程式碼定位功能，可以幫助你瞭解專案的層級結構。
但是也不是所有專案都是像上面這樣簡單，有些專案就有很多的子模組，每個子模組下面也有很多的程式碼；還有專案是 dubbo 服務，結構又不一樣了。
這種情況我會使用 idea 的全域性搜尋，去查介面名稱，基本上都可以搜到，最次也可以搜小排查範圍。
總結
說了這麼多，最後總結下吧。
個人覺得有條件的（沒條件的可以創造條件），還是儘量去嘗試閱讀開發的程式碼，從目前來看，除了需要你擠出一些時間也沒啥別的毛病了。
更何況，你擠出的這點時間是有收穫的，不是浪費時間。
至於程式碼要看到多細，那還是取決於你個人的目的了。總之，多學學沒壞處。