在企業工作了一年多，發現經常要替別人“擦屁股”，有時候別人也要替我“擦屁股”。這可能是以前我所在的學術圈（或者說學校）很少發生的事。在實驗室里，大家各干各的，相互之間沒什么交集。唯一接觸過有印象的例子是，分析數據的時候，數據本身就不好，甚至是錯誤的。這時不管采用再強大的統計模型、再精良的軟件都不可能分析出有價值的結果。悲劇的是我們數據分析人員往往是不敢質疑數據提供方的，因為現在是數據為王的時代，研究統計的往往得求著別人要數據。

　　還是說說我在公司的事。

　　剛來公司的時候我被分到了游戲邏輯組。游戲邏輯的特點是多變、復雜，因此代碼架構一般并不優雅，模塊與模塊之間耦合度很高，邏輯錯綜復雜。往往我修掉了自己模塊的一個bug，會給別人的模塊帶來另一個bug，甚至引發crash，因為我對那個模塊不了解，可能會破壞那個模塊里的“潛規則”。這時別人就要替我“擦屁股”了。而有時我會突然接到QA提的bug，看了bug描述之后會覺得愕然——怎么會有這樣的事？！我的代碼不可能會這樣的！仔細一查代碼——擦，被某人改壞掉了。

　　有時候這個別人并不是負責別的模塊的同事，而是我所負責的模塊的前任，我只是接手的人。今年初項目內測的時候，我負責的拾取模塊讓服務器崩了很多次（后來匯總崩潰情況，發現一半的崩潰都是我的代碼造成的），就屬于這種情況。前任在代碼中留下了太多我不知道的“潛規則”，而我接手之后各種需求又接踵而來，必須馬上實現。于是只好在對代碼把握不到位的情況下匆忙改代碼，于是就各種崩壞。這時就只好替前人“擦屁股”了。這是最郁悶的情況，沒人能交流沒人能溝通，能交流的人已經走掉了，把攤子留給了我。

　　后來我被調往了服務器組，不過“擦屁股”的事情可一點也沒少。服務器程序員雖然一般不用掌握很具體的游戲邏輯，不用修太多游戲bug，但是卻有一項重要職責：快速響應服務器崩潰——盡管絕大多數崩潰都是由游戲邏輯造成。可能大家對服務器組的期望是：掌握服務器底層代碼，同時對各個游戲邏輯子系統又有一定的了解。當崩潰發生時，運維人員并不知道崩在了什么地方，更不知道是誰的代碼造成了崩潰，所以第一時間只能是通知服務器組。于是我們不得不做好隨時被召喚的準備，甚至三更半夜從睡夢中被叫醒，被抓到公司查看崩潰，提供緊急修復。在這一點上，服務器組組長可謂是悲催到極點。同時悲催的當然還有運維人員。這個月初我們受到了一波黑客攻擊，導致服務器每天都會崩潰。黑客甚至似乎有意挑晚上和凌晨時間發起攻擊。幾天之后運維人員受不了了，抱怨如此頻繁的崩潰很大程度影響了他們的夜間休息，增加了他們操作失誤的概率。這就是運維人員在為程序員不安全的代碼“擦屁股”，而服務器程序員則在為游戲邏輯程序員不嚴謹的代碼“擦屁股”。（當然嘍，絕無對游戲邏輯程序員不滿的意思，事實上我現在仍兼任游戲邏輯程序員，并且我們也要替其他工種“擦屁股”。）

　　最近我還發現，我們不但會在團隊內部相互“擦屁股”，還可能要為和我們團隊沒啥關系的外人“擦屁股”。上周我對客戶端啟動程序做了些更改，發布到外網后，發現一些網吧居然無法啟動客戶端了！大家第一時間自然懷疑是我加的代碼引入了bug。可是當大家折騰幾天之后，卻逐漸發現，罪魁禍首可能是我們用的一個第三方軟件，這個軟件最近升級了……

　　看來，只要活在這個世界上，就不可能不替人“擦屁股”，然而替人“擦屁股”又的確是讓人不爽的。所以——

　　從自身的角度講：盡力做好自己的事，別給人家制造麻煩，別讓人家替我擦屁股。同時，別人有過錯時，也別太苛責；除非“擦屁股”次數多了，那就要提醒下對方了；如果次數很頻繁，或者性質很嚴重，那就要管理者出面了。國慶前我們內網服務器經常出沖內存的bug，全體程序員和QA忙活了一個多星期，差點連國慶休假都要取消。最后發現居然是因為服務器的內存壞了，這時就是由項目經理出面對IT部門發表不滿。

　　從管理的角度講：盡量明確分割各人的職責，并監督其執行狀況。事實上，職責分割越明確，監督起來也越容易。另外，多促進團隊成員之間的溝通和交流，讓大家多多互通有無。這樣才能在不得不耦合的地方盡量減少因不了解對方業務邏輯而造成的錯誤，同時也能在萬一出錯的時候，更容易地協調各方盡快排查錯誤。不過我對管理沒經驗，這些都只是我的設想。

　　從軟件架構的角度講：對一個復雜的軟件產品來說，沒有完美的架構，沒有任何架構能將模塊和模塊之間完全解耦。我們只能“盡量”，但無法“完全”。

　　不寫了，明天上班恐怕還要繼續為那個第三方軟件擦屁股。

總結

以上是生活随笔為你收集整理的替人“擦屁股”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。