對于那些不知道程序員/開發者的時間都去哪了的人，本文可能會提供一些線索。我記錄了這份日志不僅是為了看看時間都花費在哪了，也是為了看看我都做了些什么，檢視下自己是否偷懶了。當回顧之后，我發現花這些時間都是值得的。

作為開始，下面是我在前一階段追蹤的bug，（假設）你應該可以看到其中的錯誤。僅僅拿出這10行JavaScript并找到錯誤在哪里并不難，但要在茫茫的代碼中定位這10行并證明那些就是bug，這就有一定的難度了。

如此寧靜的一天。通常情況下，有三個人可能打斷我工作的連貫性，因為11：30之前，我要不時的與他們通過語音或文字信息交流和討論。把這些過程以log記錄下來，實際上是對我工作的推進是有幫助的。這使得我能端坐在鍵盤前專注于我的工作，以免被別的問題分心。

09:50 收到了一封來自團隊成員的郵件，內容是關于一些可能會產生問題的代碼。我看了一下，并把目前解決不了部分整理起來。

10:10 繼續昨天IE7虛擬機的下載（4gb）。

10:15 由于IE7下載的時間比較長，我趁著下載的時候，申請了TestingBot的賬號。

10:20 與一名開發者Skype語音，討論關于他新添加的功能。

10:21 由于設計師沒有正確的把圖片上傳到網站，產生了大量的報錯郵件。我花費了兩天的時間讓設計師掌握源代碼控制軟件。由于有些設計師沒有Visual Studio，我也建立了一些用來存儲特定內容的文件夾，這些文件夾可以自動發布問題給這些設計師。我有沒有提到，無論是在測試中，鏡像模擬階段還是已發布的產品中出現的每一個錯誤我都會記錄下來。我認為這些設計師都應該看一看。

10:22 一名開發者要與我進行Skype語音。為了防止下載軟件占據網速，而影響通信，我不得不暫停下載IE7。

10:45 完成與那名開發者的語音通信。

10:50 由于持續的退信錯誤，250個報錯郵件不能夠正常工作。我繼續了IE7的下載。放棄刪除報錯郵件，手動連接Azune并刷新那些設計師之前沒有正確上傳的圖片。

10:55 通過網絡服務器繼續測試IE7瀏覽器。查看日志中IE7報錯的部分并找到錯誤發生的原因。

11:00 測試位置出現了新的錯誤。我發現是由于某一名開發者的原因，如果他能修復錯誤，測試將會繼續進行。我發現缺失圖片錯誤的原因是設計師仍然沒有圖片添加到源碼中。由于仍然報出大量的錯誤，Will不得不提醒那名設計師。查看進度服務器（設計師的樂園）上的圖片，我發現設計師還是沒有上傳。我為設計師收集了一份錯誤列表，其內容是由于缺少圖片而產生的錯誤。我提取了這些錯誤，記錄在一份Excel中，這里提取的僅僅是關于圖片的報告。我創建了一個支持工單（譯者注：support ticket 支持工單系統），并發郵件給設計師。

11:11 回到IE7的錯誤上。通過查看日志，我找到了錯誤的原因。

11:16 在日志中找到IE7的錯誤并下載下來。由于文件比較大，下載花費了一點時間。

11:21 從日志中提取50個IE7的JavaScript代碼錯誤。追蹤Excel中的錯誤并試圖減少這50行代碼的錯誤。

11:23 發現錯誤出現在日志的起始處，而不是最近的記錄。我對日志進行時間倒序排序并找到更多的錯誤。

11:26 不再查找Excel中新加入的錯誤，僅僅查看現在已經記錄下來的。

11:30 第一個錯誤是無法加載谷歌的網站分析服務。原來又是那可惡的百度搜索引擎。

11:31 在開發過程中修復了下一個錯誤。

11:32 下一個問題發生在Mac中的FireFox瀏覽器。我想在上Mac需要建立一個完全單獨的測試計劃，因此我創建了一個支持工單。

11:35 余下的50個錯誤都是由于同一個Mac系統的問題，我不得不去找一些較早時間發生的錯誤。

11:37 在錯誤搜索中，用“或”取代“與”，并試著取消搜索過程，但無反應。

11:42 一封報錯郵件提醒我，測試位置發現字體缺失的問題，我將此問題發郵件給設計師。

11:43 之前的搜索過程被取消，開始重新搜索。

11:45 設計師回郵件說，那些文件出現缺失并非偶然，現在問題已經解決了。

11:46 在等待下一批錯誤的時候，已發布產品又出現了一個不可思議的IE7錯誤。我用支持工單記錄下了這個錯誤。如果當初我能有時間（5分鐘），我絕不會去考慮其他錯誤細節。

11:50 最后，通過使用textingbot.com網站去查看IE7的錯誤，我現在知道為什么IE7不得不被淘汰了。除了提示一個模糊的行數、字符位置信息和“期望一個標識符，字符串或數字”這類日志中已經有的信息，再也沒有什么可用的開發工具可以幫助提供更多的錯誤信息了。

11:52 借助IE7測試瀏覽器的“查看源碼（View source）”功能和之前記錄錯誤的行數，我發現少了幾行。再試一次，提示超時。我想我并沒有少了那幾行，因為IE7報告有一行沒有JavaScript代碼，這個功能一定被行數和空白符（空格、Tab和回車）干擾了。

11:57 我剛注意到某頁的中間幾段JavaScript時，再次被設計師打斷。通過查看這段代碼，我發現它們主要負責處理移動端顯示的問題。我試著直接在測試服務器上編輯這段代碼，看看能不能注釋掉這些錯誤。

12:04 不能直接編輯。由于測試服務器需要密碼，網絡蜘蛛程序禁止我建立索引。這意味著測試瀏覽器服務無法進入測試服務器。

12:06 哦！！！我進入測試服務器發現錯誤還在那里。哦不，測試服務器崩潰了。

12:08 重啟IE7的測試并再次執行測試，日志上沒有出現任何JavaScript錯誤。

12:09 刪除那些可能有問題的代碼的注釋，我發現錯誤再次出現在日志中。接下來要縮小范圍查找錯誤。

12:10 測試服務器又開始無反應，無法刷新頁面。啟動另一個服務器，并登入，我發現依然會出現錯誤。注釋掉一些代碼后，我發現錯誤是由于最后10行代碼。為了確定，我們將這10行代碼頁注釋掉，發現可以運行了。我們再縮小一下范圍，加一些alert函數。IE7再次崩潰。

12:26 一些嘗試之后，我重啟了IE7測試服務器，我發現了錯誤的原因。由于一段腳本代碼使得IE7崩潰，我想這段代碼也可以造成其他瀏覽器崩潰。這些代碼不算很糟糕，我也不會（太）責備設計師。但是，這些代碼本來不應該在任何瀏覽器上運行，更確切的說，進入到產品運行的環境中。它被嵌入到那頁代碼的中間部分。這屬于JavaScript代碼的問題，設計師用它們做一些黑客行為的事情，比如隱藏移動設備的菜單，而且這些JavaScript代碼被藏在一頁中的中間部分。這些代碼附近并沒有放置測試代碼，沒人會在最初的快速瀏覽中發現它們。但它們帶來的后果顯而易見。

12:30 我在源代碼中修復了這個bug，并記錄下這個過程。接著，我開始解決其他IE7的bug。它們是。。。

12:34 我意識到，我必須將這段經歷告訴開發團隊，因為他們都可能會寫上面那種代碼（除了IE7，哪里都可以運行），而且仍然有相當多的用戶在使用著這個功能。

12:45 完成這個bug的修復。

上面提到的bug，都是由那些初始化語句中的一個逗號引起的。

一定是有人復制粘貼了這段代碼，一天之后，我又在其他地方發現了它們。