a8c工作文化的原罪?

過去寫了這麼多在Automattic工作的好事,今天趁著在等程式碼發佈的空檔,來寫個數年來懸宕未解的問題:維護孤兒 —— 發佈之後,儘管使用者眾多,也永遠拿不到資源維護的專案。

會下這麼聳動的標題,是因為我覺得這是我們鬆散、高彈性、強調速度、根源於開源專案的工作文化的一體兩面。我們內部同時啟動的專案非常多,一個專案也通常短則1~2週,長則2~3月就發佈了,發佈之後呢?人就四散去做別的事情去了。在剛開始的一兩個月,要找到原班人馬處理後續維護還算可行,但隨著時間過去,要追溯愈來愈困難,優先序也逐漸受到新的專案擠壓;issue延宕的時間從本來可能2到3週,逐漸推進到2到3個月,當開始出現超過半年也沒人解的issue,我們便又多得到一個維護孤兒,可喜可樂、可喜可樂。以前曾讀過某篇文章論中國的高速經濟擴張弊病,裡面有一句神比喻:「步子邁太大,扯到蛋了」,差不多就像這種感覺吧?衝太快,掉好多包了。

一個很好的例子是calypso專案的自動化end-to-end測試。概念上,每當有一個PR被標上"needs review",我們的系統會自動在calypso.live上設立起一個docker container來跑該分枝的calypso,再用tests/e2e下分類為canary tests的自動測試去確認基本的正確性。如果進一步標上"needs e2e tests",那就會有好幾卡車的桌面版與行動版end-to-end測試對它這捏那拉、上沖下洗的,跑到PR吱吱叫。

matticbot會負責通知各PR的calypso.live專屬實體URL

這聽起來很美好,但有個問題:calypso.live相當不穩定,所以就會常常發生automated e2e tests不過,打開一看是calypso.live起始失敗:

這造成很多問題。開發人員常常被迫去檢查這個false negative,一開始大家還會想說重跑一下,久而久之大家就開始留下「此錯誤與本PR無關」等話,然後就忽視過去了。結果呢?曾經發生過有些不該忽視的也被忽視,造成好一段時間帳號註冊無法使用。由於一旦出錯,CircleCI會自動通知該repo的所有人,這類訊息看久了大家紛紛設inbox filter直接把它濾掉,試問這樣CI的意義還剩下多少?

這樣天天在用的東西,應該很快就會被修好吧?很遺憾,大概快一年了都還是這樣。像這樣即使很多人在用仍然成為維護孤兒的內部工具多到不行,今天舉calypso.live為例只是它會出現在公開的源碼庫中,比較方便講而已。

換個角度想,這也是為什麼一旦組織大起來,自幹前要三思 —— 長期維護成本難以估計,自己能投入多久亦未知。

發表留言

Please log in using one of these methods to post your comment:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.