Language

Wednesday, December 12, 2012

寫實驗紀錄或工作日誌的重要性


從退伍之後, 真的開始有寫程式起, 我就開始寫工作日誌, 一直保持習慣到如今。我從中獲得不少的好處, 今天利用這篇文章來跟大家分享一下。



先從我為什麼開始寫工作日誌講起好了。如同 Donald E. Knuth 在 "Coders at Work"1 裡面所講的, 寫程式是一個很耗腦力, 需要全神貫注的一件事。大家應該都還記得大學要交程式作業前, 常常一寫程式就沒日沒夜, 通宵達旦, 不寫到一個段落不善罷甘休, 但是程式設計的一個段落常常又是一兩天的功夫才會到。萬一還沒寫到一個段落就先休息, 等休息回來又忘記本來的思路了, 於是只好重新思考, 如此會花更多的時間寫程式! 正因為害怕這種事情發生, 於是, 熬夜寫程式就變成了交作業前的常態。大學時作業交完了, 可以好好休息一陣子, 不用每天想程式, 一旦開始工作, 平常的週間五天就要每天寫程式了, 遇到趕專案進度的時候, 可能要一週工作六天!2 因此如何保持每天都能夠有效率的寫程式就變成了一個挑戰與學習, 熬夜變成一個儘量避免的事情, 因為熬夜很容易讓第二天的工作效率大幅下降, 而且晚上最好還是要有自己的生活, 工作才能長長久久的。所以, 我開始寫工作日誌的動機, 就是不想熬夜, 因此, 每天在下班之前, 把當天的工作進度以及對還沒實現的部份的所有想法, 儘量的寫下來, 要足夠清楚明瞭到自己心裡覺得沒什麼好寫了, 而且第二天還能夠看懂。如此一來, 一旦闔上工作日誌, 就可以下班而不會一直擔心自己會忘記原本的想法, 下班後就可以好好放鬆。第二天來辦公室工作的時候, 一看昨天的工作日誌, 也可以很快知道昨天的進度在哪裡, 馬上可以接手繼續下去。



那麼工作日誌要如何撰寫呢?工作日誌的內容可以區分成幾類: 1) 設計 2) 當日該完成事項 3) 工作紀錄 4) 實驗紀錄。



在設計的部份, 筆者的建議是儘量用圖形表示, 因為詳細的文字可能會被紀錄在文件或是程式的註解中, 而圖形是一個描述概念非常有力量的工具, 在工作日誌中就儘量以圖形加上一些重點文字來紀錄你的設計, 這樣在實作過程中可以隨時翻閱設計圖, 可以很快的從程式設計的細節中, 再度回到一個高度來鳥瞰整個叢林, 這樣才不會迷失在樹林中(實作細節)。



當日該完成事項是每天一開始的時候, 告訴自己還有哪些工作還沒完成, 每個工作的優先順序是如何, 這樣在寫任何程式之前, 可以在心中先建立一個清單, 工作效率會大幅提升。如果你有使用萬用手冊的習慣, 那麼這部份就不用太著墨, 只要在執行那個工作的時候, 把工作紀錄寫下來即可。



工作紀錄只要把重點記錄下來即可, 不必把每一個動作記錄下來, 但是要把 know-how 記錄下來, 才不會「知其然而不知其所以然。」



在追蹤某個問題的發生點時, 我們常常做的是如同建立樹狀圖一般, 從 root(issue) 一路往下追蹤到真正發生的原因(root cause), 而常常在分支點時, 都有很多個不同的追蹤方向, 有的時候, 我們會懷疑數個分支都有可能發生問題, 或是我們也許會判斷錯誤導致追蹤錯分支, 甚至有的時候, 一個 issue 是由多個錯誤累積產生的, 就有可能有數個 root cause, 所以數個分支都是問題。這時候有實驗紀錄的話, 就有非常大的幫助。實驗紀錄應該儘量詳盡的紀錄日後可能有幫助的細節, 比如說實驗的設定、過程與結果, 這些都要詳盡紀錄。如果是在追某個或某些 bug, 在分支點時, 應該把所有可能的方向、往這個分支追蹤的判斷理由、每個分支需要花費的成本估計記錄下來, 萬一日後發現不是那麼一回事, 還可以回頭往另一個方向追。或是當某個分支解決之後, 回頭來看該分支所屬的 parent, 看看那個 parent 是不是已經也被解決, 如果沒有, 就表示還有其他原因造成那個錯誤, 就要繼續追蹤其他分支。另外, 很多時候我們可以從統計上來了解我們是否解決完所有的問題, 比方說掉封包的機率(packet dropping probability), 在解網路 driver 或 physical layer 那一層相關問題的時候, 是一個頗適合的測量指標, 我們可以從掉封包的機率的改變看出我們解的問題佔的比例有多大, 是否已經解決大部分的問題。當然, 當掉封包的機率很小的時候, 也不代表我們把問題解決完了, 這時候可以用亂數的方式產生封包來找出我們可能沒發現的問題。這些猜測, 以及某個 root cause 解決完之後的掉封包機率的改變都要寫下來。以掉封包機率而言, 某個 bug 解完之後, 如果沒有一個數量級(10 倍)以上的改變, 那這個 bug 可能跟你的 issue 沒有太大相關。再來, 如果你做實驗之後發現傳送 1000 個封包之後, 掉了 1 個封包, 這時候也至少要把測試數量提升一個數量級以上, 也就是至少傳送 104 個封包來測試掉封包機率。



在每天工作要結束前, 重頭再把工作日誌翻閱一遍, 看看今日的工作還有哪些沒有完成, 然後要紀錄腦袋裡對於今日的工作還有什麼想法, 未來該追蹤的方向是什麼, 總之把心中覺得未完成的東西紀錄在紙上, 這樣心中就不會有牽掛, 之後也不會因為忘記某些非常好的想法而扼腕。



手寫的工作日誌最好有索引, 把每天的主題用一句話統一寫到那本工作日誌的開頭或結尾的地方, 以便日後快速翻閱。每個月或每一季再花一點時間把工作日誌重點整理一次, 以供日後學習之用, 如此就可以累積寶貴的經驗。



工作日誌以內頁的記號, 可以分成方格、直線、網點與空白。每個人都有不同的選擇, 方格與網點適合繪圖或實驗紀錄, 直線適合文字比較多的紀錄, 空白是比較少使用的格式, 但是限制也最少。我個人覺得方格頗適合繪圖, 會很鼓勵使用的人用圖形來表示, 比較適合創意多的設計。而直線則比較中規中矩, 會鼓勵使用的人用文字來呈現, 比較適合不需要圖形表現的紀錄。



在今天的文章裡, 我分享了過去十幾年我寫工作日誌的經驗與方法, 我從紀錄工作日誌的習慣, 以及整理工作日誌的重點, 學習到非常多自己在業界的經驗, 這些經驗都非常寶貴。各位在看完之後, 也許能夠從中獲得一些靈感, 也開始寫工作日誌, 並且享受到下班就把一切放下的愜意!有句話說:「經驗是你最好的老師」,在用工作日誌的形式來紀錄與整理你的經驗之後, 經驗絕對會變成你很好的老師!



Footnotes:



1 Peter Seibel 著、蔡學鏞 譯, 「編程的頂尖對話-閱讀 15 位軟體大師的核心思維」, 碁峰, 民 100 年。



2 筆者建議星期天還是好好休息, 以筆者過去的經驗, 如果每週工作七天沒有休息, 兩週之後每一天的工作效率大概就只剩下 50% 不到吧, 終究是要還回去的, 所以還是以每週工作六天為最大限度。





--
Albert Huang
Chun-Chieh Huang(黃俊傑)

No comments: