今天測試的同事給我提了乙個bug，bug內容是在當設定工作流條件為某個數字、貨幣、百分比型別的字段『發生改變』為『0』時，這個工作流在該字段發生任意變化時被觸發了，而原本應該是只有在該字段變為0時才可以觸發。
接手這個bug,我先自己建立了乙個工作流，分別用數字、貨幣、百分比在裡面新增了3個條件，然後設定了通過條件組後執行的 任務。
因為我之前有修改過工作流和字段公式以及貨幣數字欄位的bug，而且我們的工作流模組很複雜，所以我一開始為了節省時間，直接找到最後執行這段條件組的檔案中。 列印並且測試，忙活了半個小時，無果，沮喪+20。
然後只能老老實實的從儲存操作開始找起，通過列印測試發現 欄位的資料被儲存了兩遍，只有在第二遍中才儲存了錯誤的值。然後從執行第二次儲存的檔案中往前查詢，時間流逝。。。沮喪+30。 然後，通過跟正常儲存的流程進行對比，發現是因為當改變任意數字時進行驗證的時候直接驗證為true然後直接執行了工作流中的任務。 進入這個驗證當中查詢，最終發現，是因為在裡面的乙個函式當中有乙個判斷
if (empty($value) else其中$value 是我們在條件組中設定的滿足當前單個條件的值， $fieldvalue是我們填充的值。
在這裡我們設定的值為0，眾所周知(很慚愧，我不知道)，在php中，0會被判斷為空 和false。
所以，在這個條件當中，當值為0的時候，我們直接進入了前面那個判斷，返回了錯誤的值。最後我在判斷中，新增了不為0的情況。bug果然沒有被重現。
歷經2個小時，終於把這個bug解決。
總結：雖然模組確實比較複雜，但是這其實只是乙個比較簡單的bug.那麼為什麼會花費這麼多時間呢，我總結了幾點：
1.沒有在完全理解bug的情況下就直接抄起鍵盤開始幹，在我們看到這個bug的時候，第一時間思考的應該是為什麼0才會出現錯誤，而其他值不會。執行這個條件組的操作會在哪一步進行，驗證又是在哪一步（這方面涉及到不清楚當前功能的邏輯結構）。
2.基礎知識不足。如果是大神的話，一眼就能知道這個bug是由什麼造成的。
所以，這個bug又給我上了一課，要加強基礎知識，多思考。
使用mjrefresh遇到的坑爹bug
在下拉重新整理的方法中，如果寫成這樣 self objectarray removeallobjects self tableview mj header endrefreshing self objectarray addobject.self tableview reloaddata 會出現如下...
2020 12 05 今天遇到的乙個坑
public class aistatemove aistate space 10 go to this state if passive event occures public aistate passiveaistate end point for moving hideininspector...
今天遇到的乙個算發
encode 一字串 如果字元小於0則直接拷貝 如果是數字則拷貝當前數字加乙個後繼字串 如果是其他字母等直接拷貝 如果是 下劃線則轉換成 ul decode 解碼 encode 部分 strold this.textbox1.text strleng strold.length char a str...