碼農與程序員區別1——快速定位bug與修復bug

前言

每一個程序員的成長老是伴隨着各類各樣的BUG。在最初階段的語法bug，到後面邏輯繁雜的業務bug，此類邏輯bug若是有跡可查還好，最怕就是它無跡可查，又極難重現。本文根據做者、做者的狐朋狗友一干人等開發經驗，介紹一些bug的快速定位與快速修復。本文主要以PHP爲主，由於做者更多的時間仍是在與最好的語音打交道。本文每一個階段都將分爲三部分，分別是介紹、示例、與解決。

目錄

初級語法bug

介紹

初級語法BUG，就是編寫代碼時候，遇到編譯器報錯。例如PHP的換行沒有加分號，js的無效對象的值得引用。此類的bug是最容易發現而且修復的，畢竟編譯器已經將bug出現的緣由及行數都送到臉上了，這都不會那就須要加緊學習了。下面介紹一些常見實例。

示例

1. 像通常的分號錯誤，稍微有代碼提示的IDE就會進行判斷。

2. 常常會出現的類型錯誤

   $t = '1562996654a';
   echo date('Y-m-d H:i:s', $t);

   這種錯誤的話，只把錯誤內容讀一遍，不懂英文就將錯誤內容翻譯一下，而後對比着行數，就能夠解決了。途中的錯誤信息是A non well formed numeric value encountered，翻譯過來就是遇到格式不正確的數值,因此只需把$t進行一次類型轉換或者字符過濾。就能夠解決掉該錯誤。

   $t = 'aaaaa';
   $t = intval($t);
   if ($t === 0) {
       throw new Exception("時間戳不容許爲0或時間戳類型錯誤");
   }
   echo date('Y-m-d H:i:s', intval($t));

3. 函數類型錯誤與函數缺乏參數

   class Friend
   {
       public $name;
   }
   
   function test(Friend $a, $b, $c, $d)
   {
       echo $a->name;
       return $b + $c + $d;
   }
   
   $f = new Friend();
   $f->name = 'g';
   
   echo test(null, 1, 'a', '2');

   代碼中出現的問題有幾處，其他幾個很普通，有一個須要特別注意的就是null不是對象類型，必須函數參數默承認覺得空才能使用null，否則會出現錯誤。callable同理，

4. 數組下標不存在或對象

   class a
   {
   
   }
   
   $a = new a();
   echo $a->a;

   
   這個類BUG同樣的，翻譯一下錯誤內容，找到相應行數，對對象屬性或數據下標 用isset或empty判斷便可。

總結

示例中不少已經解釋了。對相應的錯誤內容與錯誤行數，進行排查，就能夠修復了。

業務BUG

介紹

代碼在實際運行中，未出現常見的語法問題，可是卻在一連串的業務處理後，沒有獲得相應的結果。例如訂單金額計算，最後少了0.1元；拼團搶購，購買成功人數超過庫存；微信jssdk驗證失敗等等。以上能說出的已是有部分相應解決方案了，畢竟已經碰到了，還有說不出的，沒遇到過的BUG有時候即使最熟悉的業務的程序員，也極爲頭痛。總結而言，就是程序員禿頂的緣由所在。

示例

1. 緩存衝突

   曾今遇到過一個問題，同一套緩存被另一我的偷偷使用，致使微信accesstoken與ticket互刷，沒法使用微信。找BUG找到頭皮發麻，最後發現有人和我一塊兒出現這個問題，才解決。在開發程序時候，尤爲共用某些配置，必定要團隊一些協約好該類配置。

2. 微信jssdk
   通常初學者使用微信sdk時候容易遇到的問題。後端取host與js取host少一個/,致使微信校驗錯誤。碰到此類錯誤，仍是多諮詢已經常常開發的人爲妙。
3. 第三方API 請求body解析失敗
   通常再使用第三方API時候，body主體使用json，然是請求是也使用的json，可是就是請求失敗，不經過。這種必定要多查文檔，由於json對象與json字符串還有body要求格式關係。
4. 拼團，砍價，抽獎等高併發情景超出獎池
   這種問題須要對每一條語句進行排序，主要排查對象仍是再SQL語句，知曉sql update 何如工做以及合理使用事務，通常獎池更新，須要查出符合條件獎品進行更新中獎者，可是新手會在查的時候是對的，可是更新時候，未設置更新條件，sql update 也是有 where 條件的.
5. 多服務協同處理時候，使用同一個數據庫，致使兩邊事務互鎖，一直等待。
   首先，多服務使用同一個數據庫就已是BUG了，已是設計缺陷了。而後，兩邊同時開啓事務更是問題，須要對病句進行出，必需要事務，既然是同一套數據庫，爲什麼不在一塊兒處理。因此服務拆分時候要當心數據庫。

總結

業務BUG更多的仍是團隊溝通與細節，還有經驗的不足致使的，更多的狀況下，遇見這種問題，不能死鑽牛角尖，須要對BUG區域進行逐一排查，一我的思路不清晰，就使用小黃鴨思路。小黃鴨是什麼請自行百度 程序員 小黃鴨

設計BUG

無需多言，要有點本身想法，懟產品就完事。

BUG排查方法

1. 普通BUG看編譯器就好了
2. 一個好的IDE能夠省去80%垃圾BUG
3. 學會善用xdebug
4. 無論如何，日誌不怕多，必定要全
5. 排查BUG要記住 語言執行順序，例如PHP是從上倒下，那麼排查也應該是從上倒下，一步一步，根據日誌數據，進行合理分析，像類的話，記住set與get還有 __construct等特殊方法。
6. 大多數BUG是業務BUG，仍是要提早了解業務需求，不要由於本身的想法，與產品的須要的不一致，致使最後設計出錯。而後就是一步錯，全盤錯
7. 千萬不要過分設計，有時候過分設計，也是bug出現的緣由之一
8. 排查BUG不能心急。容易禿頂
9. 全部BUG理論上不該該重複出現，重複出現就是自身的緣由，若是說是一個團隊，那麼重複出現，其實也是團隊的問題。

結論

總的來講，全部的bug更多的仍是經驗不足，與開發時候考慮不周致使出現的問題。在修復BUG的同時，咱們還須要在本身信用的小本本上記上一筆，防止之後重複出現，畢竟每個程序員都有一個偉大的夢。若是說各位有什麼本身特殊的技巧與經驗，歡迎分享！