所謂的確定原則，指的是對於開發過程中遇到的問題，我們解決問題的思路應該是從勝利走向勝利、從確定走向確定，而不是相反，即從失敗走向勝利、從不確定走向確定。這個原則雖然說起來簡單，但能成為習慣，遇到問題就按照這個原則去解決卻不太容易。
舉個例子來說明，比如某軟體的 v 0.66版本發現某 bug，而回歸到 v 0.60 版本卻無此問題，對這個bug ，我們的工程師應該怎麼查呢？經過觀察，一般有三種思路：1 是根據bug的現象推測問題在哪，然後根據推測調整**，接著發布版本進行測試；2 從 v 0.66 版本開始，接著 v 0.65 等等到 v 0.60，看哪個版本開始沒問題，然後再進行分析和調整**； 3 從 v 0.60 版本開始，接著 v 0.61 等等到 v 0.66，看哪個版本開始出現問題，然後再進行分析和調整**。
第一種思路是程式設計師的第一感覺，如果簡單的bug，這種思路是最好最快的解決問題思路，但是對於比較困難的 bug，這種思路就會顯示出它的弊端，常常效率會比較低。我一般是建議先允許工程師花2天的時間按照自己的推測來查詢bug，兩天過後如果還沒定位問題，則要求工程師採取最穩妥的版本回歸的方式進行bug的修復。
第二種思路相對而言，比第三種思路更常見，給我的感覺是程式設計師潛意識裡就喜歡這種方法。其實，根據前面所說的確定原則，我們應該選擇的版本回歸方式是第三種思路。
初看起來，第二種思路和第三種思路差別不大，甚至有人會說，如果bug僅發生在 v 0.66 版本時（即 v 0.65 版本仍然是好的），第二種思路僅需做一次回歸即可定位問題，而第三種思路卻要回歸五個版本才可以定位問題版本。
我的意見是，如果造成該 bug 的錯誤僅僅是一處（即某個版本），確實兩種思路區別不大，但是如果造成某個錯誤現象的原因超過一處的話，那毫無疑問第三種思路比第二種思路要好太多了。
舉個極端的例子，假設系統在輸入變數值為10 的情況下，輸出的正確值是 100，也就是 v 0.60 版本（正確版本）的輸出是 100；然後很不幸，v 0.60 後的每個版本新增模組都有些問題，並且導致每個版本的輸出都不一樣，他們分別是 v 0.61 輸出 150， v 0.62 輸出 180，v 0.63 輸出 200，v 0.64 輸出 250，v 0.65 輸出300，v 0.66 輸出 500。在這種極端情況下，如果用第二種思路去解決問題，我們看下解決問題的過程。首先，因為從 v 0.65 版本開始找，找到了第乙個沒問題版本，即 v 0.60，然後修復 0.61 版本中的問題，修復之後，發現 v 0.66 版本的值仍然是錯誤的（因為 v 0.62 到 v 0.66 的錯誤並未被修正），這時候工程師就會陷到乙個糾結的境地，即如果認為是 v 0.61 新增模組導致的bug，那麼修復之後bug應該消失，可是現實是沒有消失；如果認為 v 0.61 沒問題，那問題到底出現在哪兒？實際上在這個例子中，單純修復任意乙個版本的bug 都無法最終解決問題。
對付這樣的極端例子，按照確定原則來做的話，bug總是可以很容易的解決的。首先，找到第乙個出錯版本即 v 0.61 版本，然後專心修復該版本的 bug，即確保 v 0.61 版本的輸出是正確值 100。這時候把修復過的**合併到 v 0.66 版本測試，此時依然會發現 v 0.66 版本無法輸出正確值。但是沒關係，此時只需要迭代的運用第三種思路即可，直到問題的最終解決。
確定原則是乙個很重要和實用的工作原則，在實際開發工作中，遇到問題一定要有意識的把這個原則運用起來，否則的話，就很容易跑到潛意識中的第二種思路了。
gradle開發之除錯
關於gradle plugin的開發方式，網上可以搜到很多，也都講的很詳細。但是我在開發的過程中，發現除錯是個很困難的問題，於是我跑的官網找了一下gradle的test，確實有 傳送門 裡面講的很詳細 如何使用gradlerunner來寫測試 1 如何除錯gradle的外掛程式 1.先要debug模...
ios開發之 除錯方法
在開發專案的工程中，肯定會遇到各種各樣的bug，且大多數的bug都和自己有關 那麼在和bug鬥智鬥勇的過程中，如果能快速準確的一擊斃命呢，這個時候充分利用斷點除錯的優勢，可以讓我們能更加快速的定位bug，進而解決掉。如圖1 以上就是打斷點的基本操作。這是建立，再次點選就是臨時取消這個斷點，注意不是刪...
神經網路引數確定原則
網路引數確定原則 網路節點 網路輸入層神經元節點數就是系統的特徵因子 自變數 個數，輸出層神經元節點數就是系統目標個數。隱層節點擊按經驗選取，一般設為輸入層節點數的75 如果輸入層有7個節點，輸出層1個節點，那麼隱含層可暫設為5個節點，即構成乙個7 5 1 bp神經網路模型。在系統訓練時，實際還要對...