學習犯錯

September 04 21:36~23:08

在古早，古早以前，許多人的求學過程中，都經歷過那段『少一分打一下』的不愉快時光。拜託，考 90 分已經很了不起了，為什麼還要被打 10 下？現在回想起來，覺的實在是很可笑。這種『追求 100 分的心態』，某種程度也迫使學生不得不『造假 微調數據』。記得當年 Teddy 在念五專的時候，需要上化學實驗課以及電子實習課。這兩門課，都需要在實驗室做實驗。其實這些實驗也沒什麼了不起的，就是把書本上教過的一些化學現象或是電子特性，到實驗親自動手確認一次。Teddy 依稀記得當時在做實驗的時候，常常會遇到量測出來的數據和課本上面的理論值有一段頗大的差距。『照道理講』，這時候應該是要好好的檢討一下自己做實驗的步驟或是測量方法有沒有錯誤，找出問題的原因，但是 Teddy 當時並沒有認清到這些實驗的重要性，心裡只想著『準時下班 .... 準時下課』，所以 Teddy 就犯了『全天下學生都會犯的錯』... 把實驗數據改成『長得比較接近理論值的樣子』... 順利過關。

其實『竄改...嗯嗯...調整實驗數據』這件事，也不能全怪 Teddy... 想一想，一班有 50 個學生，只有一個助教在帶實習課。做實驗遇到問題的也不只 Teddy 一個人，要是每個人真的都『按照道理』做事，非得把實驗結果失敗的原因給找出來為止，那麼短短三個小時的實驗課絕對是不夠用的。學生們為了『大局著想』，讓助教可以準時下課，實驗室可以準時關門，更重要的一點，讓自己可以準時畢業，只好『想辦法』把實驗給做出來。

想在回想起來，為什麼上這些實習課時，助教們總是期望學生『第一次做實驗就上手』？如果學生很認真的做實驗，但結果失敗，這次實驗拿到 0 分，這樣有誰願意承認自己實驗失敗？反正『正確答案』在書上都有啊，把書上的數據拿來『調整一下』就 OK 了啊，反正助教想看的也只是這些正確答案。

***

假設有一個長成這樣的 story：

As a user, I can modify common attributes of multiple objects.


使用者同時間可以在畫面上選多個『物件』，然後可以一次修改這些物件的『共同屬性』，使用者按下確定之後系統會更新這些物件在資料庫中的值。在討論這個 story 的時候，有人問到：『要不要將多個物件的修改放到一個 transaction 當中』？一開始有人贊成，有人反對，經過一番討論之後，最後大家同意『要用一個 transaction 將多個修改動作包起來』，原因是因為，如果沒有把多個修改動作都放在一個 transaction 當中，那麼假設使用者選了 10 個物件，修改之後 6 個成功，4 個失敗，可是使用者的原意就是要修改這 10 個物件啊，所以最後使用者還要自行去把那 4 個修改失敗的物件再挑出來修改一次（等於手動 retry），這樣感覺不太方便，所以最後大家同意用一個 transaction 把多個修改動作包起來。

這個 story 做完之後功能正常，一直到有人對它做了效能測試，在系統中建了 1000 個物件，然後一次修改這 1000 個物件。由於這 1000 個物件的修改被包成一個很大的 transaction，隨著這個功能的執行，資料庫的幾個 tables 都被 lock 住了（每一個修改動作都需要花一點時間，因此整著 transaction 花了很長的時間才完成）。由於這個系統還有其他幾十個 threads 在執行，也會去更新資料庫，因為需要更新的 tables 被 lock 住了，因此這些 threads 被暫停執行，最後看起來整個系統像是『當機』一樣。

如果鄉民們的團隊發生這樣的問題，要怪誰？怪當初建議這個 solution 的 developer？還是怪 Scrum Master 或是軟體架構師為什麼在 sprint planning meeting 時沒有想到會發生這樣的問題？還是要怪測試這個 story 的人有沒好好測，沒把這個問題給找出來？
 

***

沒什麼好怪的，做軟體就是這樣，『千金難買早知道』。其實把『多個物件的修改放到一個 transaction 中』這件事情本身是沒有錯滴，問題在於在該系統中，每一個修改動作夾帶了另一個修改動作（有點玄...總之就是一個修改動作同時會改到兩個 tables）。這原本也不算是個問題，但是第二個修改動作會隨著『物件數量的增加而變得很慢』。當物件數目很少的時候，整個 transaction 在幾秒內就做完了。但是，當物件數目到達 1000 的時候，每修改一次需要約 25 秒，因此整個 transaction 花了 7 個多小時才完成，整個系統後端的 threads 也被『卡』了 7 個多小時。

昨天在讀 Agile Testing 這本書的時候，看到 p. 25 提到 Have Courage 這一段，其中提到：

We need courage to let ourselves fail, knowing that at least we'll fail fast and be able to learn from the failure. After we've blown an iteration because we didn't get a stable build, we'll start thinking of ways to ensure it doesn't happen again.

We need courage to allow others to make mistakes, because that's the only way to learn the lesson.

傳統上，有些人做事會有『多做多錯，少做少錯，不做不錯』的心態。如果一個 agile team 沒有容許犯錯的空間，也沒有從錯中學習的機制，那麼這樣的 agile team 就很難稱得上是 agile team。

做軟體是沒有『正確答案』可以抄的，所以『答錯也要給分』，因為你已經排除了一種不可能的作法。

最後以 Linda Rising 女士關於 Agile software development 的看法作為結尾（節錄自 Linda Rising 在 Agile 2011 研討會 Keynote speech 的投影片）:

• Fail early, fail often.
• Fail fast, learn constantly.
• Failure *IS* an option.
• Without failure how can learning happen?
• Perfect is a verb.

***

友藏內心獨白：做軟體可不能只是偷改 test cases，把錯的改成對的就沒事了...XD。