[[327222]]

情緒化不是一個成熟的職場人士所應(yīng)有的處事方式，但在我們技術(shù)人員中間卻可能更容易的出現(xiàn)。

　　有一個技術(shù)人員都知道的很老的段子。如果我們想將一個技術(shù)論壇搞火起來，那么我們只需要發(fā)一篇帖子——php 是世界上最好的語言。雖然是很老的段子，但現(xiàn)在還常常被人提起，很有意思。

　　不僅僅是在論壇中，在我們?nèi)粘５膱F(tuán)隊(duì)合作中，其實(shí)也常常有這樣的事情?；貞浺幌?，在 Code Review 中，是不是常常有某一行代碼引起了大家的廣泛討論，把整個會議給“搞火”了？大家可能就一個問題討論很久，爭執(zhí)不下。

　　對于這樣的討論，如果大家能心平氣和，互相理解，可能能較快的達(dá)成一致，但事實(shí)上常常會出現(xiàn)這樣的情況，雙方爭論很久爭執(zhí)不下，后來可能有人說，“這你都不知道啊”，或者“這我理解不了，你這里明顯有問題”，或者“你說的都好，我用我的方式”，或者“你這里就明顯是在#define true=false”等等。

　　在這樣的討論中，我們比較容易情緒化（可能沒有情緒化這么嚴(yán)重，這里姑且先用這個詞），演變到最后，原本心平氣和的討論就變成了針對某個個人的互懟，或者直接拒絕交流。一旦情況變成這樣，那么不僅討論效率會大大下降，還會使得彼此心生芥蒂，影響后面的高效合作。

　　情緒化不是一個成熟的職場人士所應(yīng)有的處事方式，但在我們技術(shù)人員中間卻可能更容易的出現(xiàn)。因?yàn)榇蠹疫壿嬆芰?qiáng)，，思維也都很敏捷，追求高效率，相對更缺乏耐心。如果大家還能回憶得起來，《社交網(wǎng)絡(luò)》中的扎克伯格的形象可能是一個典型的高效技術(shù)人員的形象，說話滔滔不絕，做事雷厲風(fēng)行。我發(fā)現(xiàn)身邊的技術(shù)人員多多少少都具有點(diǎn)這樣的特質(zhì)。我自己反思下來，也常常發(fā)現(xiàn)自己有不夠耐心的時候。比如某次在和他人交流的時候，對方話還沒說完，我就著急開始講話，然后對方不得已也跟著著急的說“你先聽我說完嘛”。

　　正因?yàn)槿绱耍覀兗夹g(shù)人員可能更需要有一顆耐心和包容心。在沒有寫代碼，而是跟其他人討論交流時，我們有沒有即時的切換狀態(tài)，更耐心的對待他人的問題？我們在看別人的代碼的時候，當(dāng)發(fā)現(xiàn)有一些不是自己所推崇的模式的時候，有沒有仔細(xì)想一下別人為什么要這么做？我們在遺留代碼上面工作的時候，是不是一邊工作一邊吐槽代碼寫得太爛，而沒有考慮到當(dāng)時可能有各種各樣的原因？我們是不是只一味的自己講話，而沒有仔細(xì)傾聽對方的話？

　　一個例子

　　印象較深刻的有這樣一個例子，我們的代碼里面有這樣的一段邏輯：

class Something { 
   private Map<String, Object> attributes; 
   public <T> T getAttribute (String name) { 
       return (T) attributes.get(name); 
   } 
   ... 
} 

　　當(dāng)我們在 review 代碼的時候，有人一看到上面這行代碼，還沒等人解釋為什么要這么做就直接說，“這個地方明顯有問題啊，更好的方式是返回一個Option，讓調(diào)用方去處理異常”。當(dāng)作者開始要解釋的時候，他又表現(xiàn)得聽不進(jìn)去，始終堅(jiān)持自己是對的。最后由于這個小問題，可能要討論十分鐘。

　　這個問題的原因是什么呢？原來是由于Something里面的屬性其實(shí)是調(diào)用方自己定義的，由于業(yè)務(wù)的要求，調(diào)用方可以定義各種類型的屬性，而當(dāng)調(diào)用方想要獲取某一個屬性的時候，就通過getAttribute獲取。作者的設(shè)計(jì)意圖是提供一個便捷的類型轉(zhuǎn)換功能，封裝這類類型強(qiáng)制轉(zhuǎn)換的代碼，避免這類不好的代碼泄漏到每一個調(diào)用此方法的地方，而假設(shè)調(diào)用方確定的知道所查詢的屬性是什么類型（屬性是調(diào)用方自己定義的）。如果這里的類型轉(zhuǎn)換出錯，那么會拋出一個運(yùn)行時異常，這是寫代碼時就必須要處理的 bug。

　　這里的分析合情合理，在我看來是完全可以接受的。試想，如果我們返回一個Option，每一個調(diào)用的地方都需要處理類型轉(zhuǎn)換失敗的情況，而調(diào)用方要如何處理呢？似乎也只能將其拋給更上層。其實(shí)這里作為調(diào)用方可能會很奇怪，為啥我明明知道不會拋出異常，還需要顯示的處理異常呢？而且由于這樣的調(diào)用方可能很多，每個地方都需要處理這樣的異常，我們的代碼其實(shí)是變得更糟糕了。
回過頭來看這樣的討論，且不說它有沒有價(jià)值，至少在我看來是低效的。如果我們有更多的耐心和包容心，我們先聽作者把話說完，仔細(xì)傾聽他人寫代碼時的考慮，是不是可以直接避免這樣的討論呢？我們的合作是不是更加順暢呢？

　　耐心、包容心對于我們的 TL 其實(shí)有更高的要求，在面對一些經(jīng)驗(yàn)稍差的團(tuán)隊(duì)成員寫出來的代碼，有時即便是有非常明顯的問題，我們也需要虛心的耐心的傾聽作者的解釋，包容他的問題，然后合理的給出建議。只有這樣，團(tuán)隊(duì)成員才能感受到自己是受重視的，自己哪里經(jīng)驗(yàn)還比較欠缺，要往哪方面去努力。

　　幾個小建議

　　我們每天和不同背景不同經(jīng)歷的團(tuán)隊(duì)成員進(jìn)行合作，大家可能很容易的產(chǎn)生分歧，我們無意間發(fā)表的觀點(diǎn)也可能會傷到他人的自尊。如何讓自己有更好的耐心和包容心？這個問題可能是每一個作為成熟的職場人所必須要經(jīng)常思考和練習(xí)的。只有每個人都做好了這些，我們在日常工作中才能更順暢的交流，更高效的合作，更和諧的相處。

　　ThoughtWorks 是一個反饋文化很濃厚的公司，反饋的技巧對于培養(yǎng)自己更好的耐心和包容心同樣適用。要想有好的反饋效果，我們通常不是直接指出對方的問題，因?yàn)槲覀冇^察到的對方的問題一般都只是根據(jù)事實(shí)的推測，內(nèi)在原因我們未必知道。那么第一步是講事實(shí)，傾聽他人的解釋，然后驗(yàn)證自己的假設(shè)。如果對方根本沒有這個問題（先前的假設(shè)不存在），那么我們的反饋?zhàn)匀灰簿筒淮嬖?。如果真的存在問題，應(yīng)該適當(dāng)引導(dǎo)他，讓他自己發(fā)現(xiàn)做的不對，然后主動的去改正，我們當(dāng)然也可以在這個時候分享一些自己的經(jīng)驗(yàn)，給出一些自己的建議。這樣的反饋其實(shí)很需要耐心和包容心。

　　我個人的另一些經(jīng)驗(yàn)來自卡耐基《人性的弱點(diǎn)》這本書。相信很多同學(xué)們都看過這本書，書中對于如何指出別人的錯誤，如何提出建議給出了很多很有效的方法。這本書并不是像很多“成功學(xué)”的書一樣，似乎我們看了就能成就多么偉大的一番事業(yè)。這本書更多的是教會大家如何去追求內(nèi)心的平靜，如何將自己的社會關(guān)系建立得更加和諧?？赐赀@本書，我們可能會更少的抱怨，更多的付出，同時也更滿足，更幸福。

　　這里有一些書中內(nèi)容的引用，與大家共勉。

　　如何指出別人的錯誤？

• 用稱贊和真誠的欣賞開始
• 教導(dǎo)他人時，要做到讓別人不覺得在被教導(dǎo)
• 提出別人不知之事要像是提醒別人遺忘之事
• 尊重他人，間接的指出人們的過錯，使用“如果 xx 那么 xx”
• 在批評對方之前，不妨先談?wù)勀阕约旱腻e誤
• 使錯誤看起來容易改正
• 用請求、建議、商量、贊美、提問的方式進(jìn)行，別用命令的口吻，保全他人的面子