謙遜是什么陪汽，其實我很難給出文學(xué)上的解釋。從百科上釋義如下：
謙虛莺褒、不浮夸掩缓、低調(diào)、為人低調(diào)遵岩，不自滿你辣。是一種自我的認識，良好的品德
我理解的謙遜就是 Modest尘执，是對于身邊人或者個人習(xí)慣的一種尊重舍哄。為什么會談到這個問題，是因為最近在工作中遇到一些事情誊锭，讓我開始了自我反思表悬。
場景一
我在和 Mike 結(jié)對編程時，我會提前看一下他的工作年限丧靡。從工作簡歷上看起來蟆沫，此人工作了五六年，應(yīng)該是個大神温治。于是我和他工作時傾向于被他帶著走饭庞，逐漸的缺少思考。因為我覺得他就是個大神熬荆，大神做得應(yīng)該都是對的舟山。
場景二
我在和 Allen 結(jié)對編程時，我注意到 Allen 其實只工作一年，看起來工作年限并沒有我時間長累盗。這時候我在和她結(jié)對時寒矿，會傾向于表達自己的觀點，并且有些時候?qū)τ谧约旱挠^點更是根深蒂固的堅持若债，很少去考慮她的想法符相。
場景三
我和 Mike 正在為一個按時間分類的問題犯愁，Mike 想了好一會兒拆座，好像沒有好的結(jié)果主巍。于是我自己在紙上畫了畫冠息，似乎有點想法了挪凑。于是我問 Mike 我是不是可以試試。Mike 也友好的示意我試試逛艰。所以我一股腦兒把自己的想法用代碼實現(xiàn)出來了躏碳，用幾個測試用例跑了下，似乎結(jié)果還可以散怖。于是 Mike 從簡單到難菇绵，用一個個測試了來覆蓋。最后我們再重構(gòu)了下代碼镇眷。
場景四
我和 Allen 就多環(huán)境一個URL的配置問題咬最，引起了討論。我堅持認為直接把整個的URL配置放在配置文件中就可以了欠动。 Allen 認為把URL的域名部分放在配置文件中永乌，具體的頁面放在代碼中，這樣別人更容易看懂具伍。當然我在盡力告訴她我這樣是最好的翅雏，因為她那樣并沒有提高重用性等等。
似乎 Allen 也沒有被我說服人芽，午飯時我又在思考這個問題望几。我想到了什么，下午開始工作時萤厅，我說我們先按照你的方法做吧橄抹，因為我覺得兩者差別不是太大。當然我不想為了一個問題請第三者仲裁惕味，這樣沒有被采用方案的哪一方豈不是很尷尬楼誓。通過 Allen 的做法，在最后資源命名時赦拘，我們發(fā)現(xiàn)這種做法慌随，最后命名時的尷尬揭露了這種做法的不合適。最后我們愉快的采用了另外一個方案。
反思
為什么我在開始合作時阁猜，會先看同事的簡歷丸逸？
這是個很錯誤的習(xí)慣，因為我潛意識里會把一個人的項目經(jīng)驗作為一個人資質(zhì)的評判剃袍。似乎這樣子能讓我“知已知彼黄刚，百戰(zhàn)不怠”。但是事實似乎并不是如此民效。
首先憔维，做決策溝通過程中，我們應(yīng)該充分考慮互相的想法畏邢。因為我們永遠不能說业扒，經(jīng)驗豐富的人說的話就一定是對的。特別是在寫代碼過程中舒萎，每個人看到的問題角度不一樣程储，所以每個人處理問題的手段也可能有差異。結(jié)對編程的目的就是幫助你們作出最好的決策臂寝。
其實章鲤，要敢于發(fā)聲。強者不必咄咄逼人咆贬，弱者也不必一言不發(fā)败徊。你不說出口，沒人知道你的想法掏缎。同樣皱蹦，你有不懂的問題，憋在心里也永遠沒有答案御毅。所以你應(yīng)該借助結(jié)對編程這個合作形式根欧，把想問的，不懂得端蛆，想說的都及時的拋出來凤粗。才能給同伴一個反饋。
理解
Mike 遵循嚴格的 TDD
Mike 在寫代碼時今豆，遵循很嚴格的 TDD嫌拣，Java 里面的一個注解都需要用測試覆蓋。如果沒有測試覆蓋的情況下呆躲，你添加的任意一行代碼异逐，他會立馬給你刪掉。也就是如果按照這種方式寫代碼插掂，測試率百分百應(yīng)該不是問題灰瞻。
Mike 認為單元測試就應(yīng)該測單元
和 Mike 同學(xué)結(jié)對過程中腥例，發(fā)現(xiàn)他對單元測試的界定很嚴格。比如 A 類的職責是調(diào)用 API 獲取數(shù)據(jù)酝润，調(diào)用 B 類處理一個復(fù)雜的分組處理燎竖，然后簡單的過濾進行返回。首先我們給 B 類這個分組器添加了嚴格的單元測試要销，確保其功能的正常构回。當我給 A 添加測試時， Mike 堅持將 B 類這個分組器給 Mock 掉疏咐，因為在給 A 類測試時纤掸，我們不希望受到 B 類的影響，所以即使 B 類只要一個簡單的方法浑塞，他也需要保證 A 的測試只是在測試 A借跪。
對于以上兩種情況，你很難說這樣有什么問題缩举。因為測試驅(qū)動開發(fā)或者單元測試不就是應(yīng)該這樣嗎垦梆？所以當你嘗試去遵守時匹颤，卻發(fā)現(xiàn)比如確保每一行代碼都有測試仅孩，真是太難了。
這時候印蓖，首先我理解 Mike 這么做的初衷辽慕，他看起來是一個完美主義者，而且是一個資深的 TDD 捍衛(wèi)者赦肃。我應(yīng)該尊重他的這個習(xí)慣溅蛉，因為這的確是個好習(xí)慣。問題在于我們在平時做事過程中他宛，是不是要嚴格這樣遵守呢船侧？其實這就要看項目里面的 “潛規(guī)則”。一般大家都會達成共識厅各，比如怎樣的代碼塊需要嚴格測試的镜撩，什么樣的代碼只需要稍微測試下即可的。有了共識队塘，其實按照大家的工作習(xí)慣來袁梗，就基本沒什么問題。
開放
除了上面具體的編程習(xí)慣憔古，不知道你是不是遇到了下面這些問題：
- 產(chǎn)品代碼沒有單元測試的公司不是好公司
- 編寫 Java 還在使用 Eclipse 的
- 還在用 Windows 機器開發(fā)應(yīng)用程序
- 竟然還在使用 SVN 進行代碼管理
- 只知道 CSDN遮怜，不知道 Github 的開發(fā)人員
- 公司內(nèi)部網(wǎng)絡(luò)訪問不了 Google
- 手工部署，沒有使用過 Jenkins 等工具
- 傳統(tǒng)的瀑布流開發(fā)方式
- 每天有上司盯著你鸿市，公司有嚴格的 KPI
- 開發(fā) Android 竟然還在使用 Eclipse锯梁，說好的 Android Studio呢即碗？
多少次，我嘗試去了解一家公司時陌凳，會使用這些指標給一家公司定性拜姿。似乎只有和我現(xiàn)在的公司開發(fā)方式以及文化相似的公司才是好公司。現(xiàn)在想來也有點過了冯遂。
畢竟蕊肥，任何一家公司都有自己的做事方式，其實你很難評價這種方式是好還是不好蛤肌。比如下面幾種：
- 扁平化組織一定比傳統(tǒng)的層級化組織有優(yōu)勢壁却？
- Mac 就一定比 Windows 高效？
- 所有的互聯(lián)網(wǎng)公司都應(yīng)該使用 TDD裸准？
- Eclipse 真的就是一坨渣展东，好程序就應(yīng)該使用 Intellij？
其實上述問題炒俱，大家每個人都有每個人的看法盐肃。拿扁平化組織而言，我司難道就比組織層級化的華為優(yōu)秀权悟？
對于 TDD 而言砸王，國內(nèi)的創(chuàng)業(yè)公司節(jié)奏很快，當你的 APP 還在寫測試時峦阁，別人的產(chǎn)品也許早就上線了谦铃。等你花了三倍的時間把產(chǎn)品開發(fā)完，發(fā)現(xiàn)別人早就驗證這個市場不靠譜榔昔。然后你一堆代碼就爛在那里驹闰。
對于操作系統(tǒng)，Mac 和 Windows 各有優(yōu)勢撒会，相信每個人都有自己的偏好嘹朗，并且每個人都會根據(jù)自己的實際財力情況，進行取舍诵肛。
當我們在噴 Eclipse 時屹培，其實我自己當時也是用 Eclipse 來寫 Java 程序，來寫 Android 程序的曾掂。后來工作后惫谤，在新公司的要求下，才放棄 Eclipse珠洗。
謙遜
恰巧前段時間讀到了陳先生公眾號里面一篇文章溜歪，講的是一個年過半百的老者去面試的故事。文中老者在面試時表現(xiàn)的恭敬與認真的態(tài)度著實給我上了一課许蓖。因為我曾經(jīng)也有個面試蝴猪，那個意外的面試純粹是為了探探其他公司招人的要求调衰，因為我根本沒有想到去那家公司。于是面試時表現(xiàn)的可漫不經(jīng)心了自阱。沒有簡歷嚎莉，隨便的自我介紹，其實完全是一種無所謂的態(tài)度沛豌。
細思極恐趋箩，面試官看到我這個樣子該是多么的嫌棄。我竟不曾想到我這樣留給別人什么印象加派。雖然我沒有想過得到別人的認可叫确，但是我應(yīng)該給予每個人應(yīng)有的尊重。應(yīng)該時刻保持謙遜芍锦。這樣我才可能在花甲之年竹勉，成為文中那個受人尊敬的老者。
結(jié)語
當你遇到不同的人娄琉，不同的公司時次乓，千萬不要見怪。其實一切的不適應(yīng)都只是你不喜歡變化的爛借口孽水。而且當你足夠牛逼時票腰，你可以影響他人，當你有足夠的影響力的時候匈棘，你有能力改變一些事情丧慈。
