a8c工作文化的原罪？
source link: https://softman.blog/2020/05/07/a8c-working-culture-drawback/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
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吱吱叫。
這聽起來很美好，但有個問題：calypso.live相當不穩定，所以就會常常發生automated e2e tests不過，打開一看是calypso.live起始失敗：
這造成很多問題。開發人員常常被迫去檢查這個false negative，一開始大家還會想說重跑一下，久而久之大家就開始留下「此錯誤與本PR無關」等話，然後就忽視過去了。結果呢？曾經發生過有些不該忽視的也被忽視，造成好一段時間帳號註冊無法使用。由於一旦出錯，CircleCI會自動通知該repo的所有人，這類訊息看久了大家紛紛設inbox filter直接把它濾掉，試問這樣CI的意義還剩下多少？
這樣天天在用的東西，應該很快就會被修好吧？很遺憾，大概快一年了都還是這樣。像這樣即使很多人在用仍然成為維護孤兒的內部工具多到不行，今天舉calypso.live為例只是它會出現在公開的源碼庫中，比較方便講而已。
換個角度想，這也是為什麼一旦組織大起來，自幹前要三思 —— 長期維護成本難以估計，自己能投入多久亦未知。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK