對于我們開發(fā)验靡，誰也不能保證自己永遠不會出現(xiàn)BUG，然而怎樣盡可能的避免BUG呢消约？從自己的一些角度出發(fā)記錄下晴叨，最近自己所犯的錯誤, 不談具體的出現(xiàn)場景舟陆，但開發(fā)中確是可以謹記的。
- iOS 最常出現(xiàn)的 BUG
- 具體編寫代碼時的容易忽略的問題
一敏沉、 iOS 最常出現(xiàn)的 BUG
1-1果正、EXC_BAD_ACCESS 訪問了一個不存在的對象
感覺這個 BUG 出現(xiàn)的幾率應(yīng)該是最高的吧， 各種提前釋放啊
或者說忘記給對象做防空處理啊盟迟，涉及到到東東好像太多了1-2秋泳、-[__NSArrayI objectAtIndex:] 數(shù)組越界
很多時候后臺返回的不一致，或者說自己某處寫死了攒菠，
所以這個錯的第一原則迫皱，就是相對應(yīng)的數(shù)組長度不要寫死了
另外注意可變數(shù)組不要添加空的對象
在具體使用時，長度判斷是很有必要的辖众，常常注意的卓起。1-3、unrecognized selector sent to instance 該對象找不到其方法
例如 viewController 沒有直接的 Push 方法凹炸，需要 viewController.navigationController 才有戏阅，而 viewController 直接調(diào)用 Push 方法就會出現(xiàn)這個錯誤的。
就是該對象不具備該功能啤它，我們卻莫名其妙讓其干了這個事情奕筐，該對象干不了舱痘，系統(tǒng)自然生氣了。
平常中我們可能是直接引用的時候离赫，對象不知不覺成了我們不想要的對象啦芭逝。。渊胸。
個人認為這是線上最容易出現(xiàn)的三種問題旬盯，其他內(nèi)存暴漲，多線程相關(guān)翎猛、堆棧等問題倒還是相對來說是少的瓢捉。
這就是我們對于臨界條件需要注意判斷，畢竟常見的 UI 問題 或者流程問題办成，基本測試還是可以發(fā)現(xiàn)的。
二搂漠、 具體編寫代碼時的容易忽略的問題
2-1迂卢、調(diào)用公共代碼時
很多時候我們會調(diào)用一些公共的模塊，一些老的通用代碼桐汤，正常操作下都是好的而克，但是假如不能跑遍所有情況的流程下，卻是可能有問題的怔毛，畢竟不是自己寫的嘛
例如這次我們的一個跳轉(zhuǎn)模塊员萍，就是因為我寫的新需求切換了一個新的 TabBar, 導(dǎo)致個別跳轉(zhuǎn)直接崩潰，但是之前測試的時候拣度，又沒有測試到位碎绎，畢竟跳轉(zhuǎn)類型是很多種的，我在測試其4種類型后就沒有測剩余的兩種抗果，然而就這樣漏了筋帖，這樣出問題了。
所以這也是很多大公司一般不輕易用他人的第三方庫的原因之一咯2-2冤馏、發(fā)版本前的改動
在發(fā)版本前日麸，一般之前已經(jīng)有啦一個完整的測試驗收了。
但是不排除測試或者自己突然發(fā)現(xiàn)一些地方流程或顯示是可以優(yōu)化的逮光，突然要改的
此時怎么辦呢代箭？我一般也會去操作，覺的自己是可控這塊代碼的涕刚，但是此時卻是要小心咯
因為我們第一次完成時整個的思路通常是更完整的嗡综，到驗收之后的再改，很可能漏掉一些細節(jié)的副女，當(dāng)然這也不是我們應(yīng)有的工作流程蛤高。
這也就是很多時候蚣旱，我們改一個 BUG 時，卻莫名的產(chǎn)生了新的BUG戴陡，就是同樣的理由吧塞绿。
而且這個時候，無論是測試和個人都不是最好的工作狀態(tài)恤批，急于上線异吻，時間緊迫的那種感覺。
很多時候你覺自己是可控的喜庞，但是事實并不如此诀浪！
此時你我應(yīng)該注意，一般的不影響主流的問題在此時可以是不改的延都！
