夢斷程式碼--一個程式設計師的自白（九 完）
阿新 • • 發佈：2019-02-08
從11月份開始，我就在息壤中做準備工作。為息壤寫document comments，寫設計文件，sample文件，寫一些Protein--版本4.0--的高層設計。這個新設計有一個讓人非常痛苦的約束，就是檔案格式和API不能做任何改變。後來在我們的爭取之下，API放鬆一點點，只要不要求修改使用者程式碼就行--實際上，我們後來還是順便糾正了一點點細小但很噁心的API問題，比如列表的元素個數至少是1這樣詭異的設計。我把這種限制下的設計叫做戴著鐐銬跳舞。寫文件和設計花費了大量的時間，後來還是W全部整理了之後給美國的架構師S看（當時美國那邊只剩S一個人了）。不可能設計全部做完了才開始編碼，美國那邊也需要一個嚴肅的原型，以便可以測量出可能的效能改進，進而評估專案是不是要做。因為當時轉向到雲端計算的氛圍已經很濃了，要不要繼續做Protein已經打上了問號。從11月中下旬開始，我和另外兩個同事開始為Protein寫基本的runtime的支援部分。差不多到元旦，執行時管理的部分就已經寫完了。這時TD做了幾個美國那邊最關心的case的效能測試，最好的情況快了兩個數量級。除了一個預期不會有改進的部分（實際上也是改進巨大，只是在當時的case裡無法反映），其他的case也基本上快了一個數量級，這讓美國那邊非常興奮。雖然當時公司要把大量的資源抽去做Cloud相關的專案，但是因為這個極好的效能報告，Protein 4.0還是立項了。這是我們第一次爭取到一個本來很可能取消的專案，也是第一次，在我們這個部門內，由中國這邊全權來做全部設計的專案。這對我們當然是個巨大的鼓舞。現在想來，之所以能拿到主動權，是因為我們做的早，美國那邊還忙的不可開交的時候，我們已經為第二年的事情開好了頭。如果沒有息壤，也很難在這麼短的時間裡做出可以提供這麼多效能測試的結果。
接下來的就是寫檔案包管理的部分，到春節前就基本上完工了。考慮到我們並非整個團隊全部投入到4.0上，新的4.0能工作，並全部跑通，只花了整個團隊1個半月的工作時間。這是我在公司所有專案中從未有過的速度。高峰時期，我們平均每個人一天可以提交四五次程式碼。雖然我們仍然會罵Protein API的設計很爛，會批評以前的實現程式碼為什麼那麼糟糕，但是我們還是盡力在允許的範圍內做大最好。接下來的任務是通過迴歸測試，這花費了我們相當多的時間和資源。這是以前的設計中各種特例的惡果，還有就是針對實現和現狀測試，而不是針對預期和設計來測試帶來大量的虛假錯誤。為了通過那幾百個迴歸測試，我們還是付出了相當多的努力的。到迴歸測試差不多都通過時，我發現因為前期為了能夠表現給美國那邊看，和M一味地趕進度，程式碼的質量很讓人不滿意。在相容以前各種奇怪的邏輯和行為的時候，我們已經不得不引入了許多混亂和複雜性，如果我們不能把這些混亂和複雜性控制住的話，就會傷害到軟體的質量和阻礙我們進一步的改進。程式碼改進越困難，我們就越容易喪失對程式碼質量的警惕性。我批評的第一個目標是單元測試。
在xirang中，我寫了比較完整的UT，我想這足以作為如何寫UT的範本了。但是，同事們完全沒有正確地去寫UT，即對每一個API，都要根據給定的輸入，檢測期望的輸出。仍然按照以前的路子，以寫功能測試和整合測試的方法寫UT，既不在意測試用例的獨立性和隔離性，也不在乎是否做了IO和執行時間。還是使用了我一再強調並反對的一杆子到底的測試方法，那會遇到執行路徑的組合爆炸問題。測試資料也不是那種精心製作的，而是隨便抓來的摻雜大量噪聲的資料。當時的UT時間已經100多秒，而且還有快速上升的勢頭。我當時和M提出來，質量有問題，必須停一下，補上質量的欠債，否則後面的工作可能會遇到很多麻煩。但是M強烈反對，他打算投入更多資源去完善迴歸測試。這在我看來是及其低效和不可行的。當時還有一個開發X，也支援M，這讓我很意外，也很難理解--我們過去的質量聲譽並非很好，也為此飽受折磨。我們在之前的Protein開發中，單元測試最快的也要40分鐘。我不能理解，為什麼程式設計師能忍受？為什麼不把這個看作是一種致命的錯誤？我是每次必抱怨的，從不掩飾。