對(duì)于我們開發(fā)，誰也不能保證自己永遠(yuǎn)不會(huì)出現(xiàn)BUG，然而怎樣盡可能的避免BUG呢？從自己的一些角度出發(fā)記錄下，最近自己所犯的錯(cuò)誤, 不談具體的出現(xiàn)場景，但開發(fā)中確是可以謹(jǐn)記的。

• iOS 最常出現(xiàn)的 BUG
• 具體編寫代碼時(shí)的容易忽略的問題

一、 iOS 最常出現(xiàn)的 BUG

• 1-1、EXC_BAD_ACCESS 訪問了一個(gè)不存在的對(duì)象
  感覺這個(gè) BUG 出現(xiàn)的幾率應(yīng)該是最高的吧， 各種提前釋放啊
  或者說忘記給對(duì)象做防空處理啊，涉及到到東東好像太多了

• 1-2、-[__NSArrayI objectAtIndex:] 數(shù)組越界
  很多時(shí)候后臺(tái)返回的不一致，或者說自己某處寫死了，
  所以這個(gè)錯(cuò)的第一原則，就是相對(duì)應(yīng)的數(shù)組長度不要寫死了
  另外注意可變數(shù)組不要添加空的對(duì)象
  在具體使用時(shí)，長度判斷是很有必要的，常常注意的。

• 1-3、unrecognized selector sent to instance 該對(duì)象找不到其方法
  例如 viewController 沒有直接的 Push 方法，需要 viewController.navigationController 才有，而 viewController 直接調(diào)用 Push 方法就會(huì)出現(xiàn)這個(gè)錯(cuò)誤的。
  就是該對(duì)象不具備該功能，我們卻莫名其妙讓其干了這個(gè)事情，該對(duì)象干不了，系統(tǒng)自然生氣了。
  平常中我們可能是直接引用的時(shí)候，對(duì)象不知不覺成了我們不想要的對(duì)象啦。。。

個(gè)人認(rèn)為這是線上最容易出現(xiàn)的三種問題，其他內(nèi)存暴漲，多線程相關(guān)、堆棧等問題倒還是相對(duì)來說是少的。
這就是我們對(duì)于臨界條件需要注意判斷，畢竟常見的 UI 問題 或者流程問題，基本測試還是可以發(fā)現(xiàn)的。

二、 具體編寫代碼時(shí)的容易忽略的問題

• 2-1、調(diào)用公共代碼時(shí)
  很多時(shí)候我們會(huì)調(diào)用一些公共的模塊，一些老的通用代碼，正常操作下都是好的，但是假如不能跑遍所有情況的流程下，卻是可能有問題的，畢竟不是自己寫的嘛
  例如這次我們的一個(gè)跳轉(zhuǎn)模塊，就是因?yàn)槲覍懙男滦枨笄袚Q了一個(gè)新的 TabBar, 導(dǎo)致個(gè)別跳轉(zhuǎn)直接崩潰，但是之前測試的時(shí)候，又沒有測試到位，畢竟跳轉(zhuǎn)類型是很多種的，我在測試其4種類型后就沒有測剩余的兩種，然而就這樣漏了，這樣出問題了。
  所以這也是很多大公司一般不輕易用他人的第三方庫的原因之一咯

• 2-2、發(fā)版本前的改動(dòng)
  在發(fā)版本前，一般之前已經(jīng)有啦一個(gè)完整的測試驗(yàn)收了。
  但是不排除測試或者自己突然發(fā)現(xiàn)一些地方流程或顯示是可以優(yōu)化的，突然要改的
  此時(shí)怎么辦呢？我一般也會(huì)去操作，覺的自己是可控這塊代碼的，但是此時(shí)卻是要小心咯
  因?yàn)槲覀兊谝淮瓮瓿蓵r(shí)整個(gè)的思路通常是更完整的，到驗(yàn)收之后的再改，很可能漏掉一些細(xì)節(jié)的，當(dāng)然這也不是我們應(yīng)有的工作流程。
  這也就是很多時(shí)候，我們改一個(gè) BUG 時(shí)，卻莫名的產(chǎn)生了新的BUG，就是同樣的理由吧。
  而且這個(gè)時(shí)候，無論是測試和個(gè)人都不是最好的工作狀態(tài)，急于上線，時(shí)間緊迫的那種感覺。
  很多時(shí)候你覺自己是可控的，但是事實(shí)并不如此！
  此時(shí)你我應(yīng)該注意，一般的不影響主流的問題在此時(shí)可以是不改的！