What is Modest
谦逊是什么，其实我很难给出文学上的解释。从百科上释义如下：
谦虚、不浮夸、低调、为人低调，不自满。是一种自我的认识，良好的品德
我理解的谦逊就是 Modest，是对于身边人或者个人习惯的一种尊重。为什么会谈到这个问题，是因为最近在工作中遇到一些事情，让我开始了自我反思。
场景一
我在和 Mike 结对编程时，我会提前看一下他的工作年限。从工作简历上看起来，此人工作了五六年，应该是个大神。于是我和他工作时倾向于被他带着走，逐渐的缺少思考。因为我觉得他就是个大神，大神做得应该都是对的。
场景二
我在和 Allen 结对编程时，我注意到 Allen 其实只工作一年，看起来工作年限并没有我时间长。这时候我在和她结对时，会倾向于表达自己的观点，并且有些时候对于自己的观点更是根深蒂固的坚持，很少去考虑她的想法。
场景三
我和 Mike 正在为一个按时间分类的问题犯愁，Mike 想了好一会儿，好像没有好的结果。于是我自己在纸上画了画，似乎有点想法了。于是我问 Mike 我是不是可以试试。Mike 也友好的示意我试试。所以我一股脑儿把自己的想法用代码实现出来了，用几个测试用例跑了下，似乎结果还可以。于是 Mike 从简单到难，用一个个测试了来覆盖。最后我们再重构了下代码。
场景四
我和 Allen 就多环境一个URL的配置问题，引起了讨论。我坚持认为直接把整个的URL配置放在配置文件中就可以了。 Allen 认为把URL的域名部分放在配置文件中，具体的页面放在代码中，这样别人更容易看懂。当然我在尽力告诉她我这样是最好的，因为她那样并没有提高重用性等等。
似乎 Allen 也没有被我说服，午饭时我又在思考这个问题。我想到了什么，下午开始工作时，我说我们先按照你的方法做吧，因为我觉得两者差别不是太大。当然我不想为了一个问题请第三者仲裁，这样没有被采用方案的哪一方岂不是很尴尬。通过 Allen 的做法，在最后资源命名时，我们发现这种做法，最后命名时的尴尬揭露了这种做法的不合适。最后我们愉快的采用了另外一个方案。
反思
为什么我在开始合作时，会先看同事的简历？
这是个很错误的习惯，因为我潜意识里会把一个人的项目经验作为一个人资质的评判。似乎这样子能让我“知已知彼，百战不怠”。但是事实似乎并不是如此。
首先，做决策沟通过程中，我们应该充分考虑互相的想法。因为我们永远不能说，经验丰富的人说的话就一定是对的。特别是在写代码过程中，每个人看到的问题角度不一样，所以每个人处理问题的手段也可能有差异。结对编程的目的就是帮助你们作出最好的决策。
其实，要敢于发声。强者不必咄咄逼人，弱者也不必一言不发。你不说出口，没人知道你的想法。同样，你有不懂的问题，憋在心里也永远没有答案。所以你应该借助结对编程这个合作形式，把想问的，不懂得，想说的都及时的抛出来。才能给同伴一个反馈。
理解
Mike 遵循严格的 TDD
Mike 在写代码时，遵循很严格的 TDD，Java 里面的一个注解都需要用测试覆盖。如果没有测试覆盖的情况下，你添加的任意一行代码，他会立马给你删掉。也就是如果按照这种方式写代码，测试率百分百应该不是问题。
Mike 认为单元测试就应该测单元
和 Mike 同学结对过程中，发现他对单元测试的界定很严格。比如 A 类的职责是调用 API 获取数据，调用 B 类处理一个复杂的分组处理，然后简单的过滤进行返回。首先我们给 B 类这个分组器添加了严格的单元测试，确保其功能的正常。当我给 A 添加测试时， Mike 坚持将 B 类这个分组器给 Mock 掉，因为在给 A 类测试时，我们不希望受到 B 类的影响，所以即使 B 类只要一个简单的方法，他也需要保证 A 的测试只是在测试 A。
对于以上两种情况，你很难说这样有什么问题。因为测试驱动开发或者单元测试不就是应该这样吗？所以当你尝试去遵守时，却发现比如确保每一行代码都有测试，真是太难了。
这时候，首先我理解 Mike 这么做的初衷，他看起来是一个完美主义者，而且是一个资深的 TDD 捍卫者。我应该尊重他的这个习惯，因为这的确是个好习惯。问题在于我们在平时做事过程中，是不是要严格这样遵守呢？其实这就要看项目里面的 “潜规则”。一般大家都会达成共识，比如怎样的代码块需要严格测试的，什么样的代码只需要稍微测试下即可的。有了共识，其实按照大家的工作习惯来，就基本没什么问题。
开放
除了上面具体的编程习惯，不知道你是不是遇到了下面这些问题：
- 产品代码没有单元测试的公司不是好公司
- 编写 Java 还在使用 Eclipse 的
- 还在用 Windows 机器开发应用程序
- 竟然还在使用 SVN 进行代码管理
- 只知道 CSDN，不知道 Github 的开发人员
- 公司内部网络访问不了 Google
- 手工部署，没有使用过 Jenkins 等工具
- 传统的瀑布流开发方式
- 每天有上司盯着你，公司有严格的 KPI
- 开发 Android 竟然还在使用 Eclipse，说好的 Android Studio呢？
多少次，我尝试去了解一家公司时，会使用这些指标给一家公司定性。似乎只有和我现在的公司开发方式以及文化相似的公司才是好公司。现在想来也有点过了。
毕竟，任何一家公司都有自己的做事方式，其实你很难评价这种方式是好还是不好。比如下面几种：
- 扁平化组织一定比传统的层级化组织有优势？
- Mac 就一定比 Windows 高效？
- 所有的互联网公司都应该使用 TDD？
- Eclipse 真的就是一坨渣，好程序就应该使用 Intellij？
其实上述问题，大家每个人都有每个人的看法。拿扁平化组织而言，我司难道就比组织层级化的华为优秀？
对于 TDD 而言，国内的创业公司节奏很快，当你的 APP 还在写测试时，别人的产品也许早就上线了。等你花了三倍的时间把产品开发完，发现别人早就验证这个市场不靠谱。然后你一堆代码就烂在那里。
对于操作系统，Mac 和 Windows 各有优势，相信每个人都有自己的偏好，并且每个人都会根据自己的实际财力情况，进行取舍。
当我们在喷 Eclipse 时，其实我自己当时也是用 Eclipse 来写 Java 程序，来写 Android 程序的。后来工作后，在新公司的要求下，才放弃 Eclipse。
谦逊
恰巧前段时间读到了陈先生公众号里面一篇文章，讲的是一个年过半百的老者去面试的故事。文中老者在面试时表现的恭敬与认真的态度着实给我上了一课。因为我曾经也有个面试，那个意外的面试纯粹是为了探探其他公司招人的要求，因为我根本没有想到去那家公司。于是面试时表现的可漫不经心了。没有简历，随便的自我介绍，其实完全是一种无所谓的态度。
细思极恐，面试官看到我这个样子该是多么的嫌弃。我竟不曾想到我这样留给别人什么印象。虽然我没有想过得到别人的认可，但是我应该给予每个人应有的尊重。应该时刻保持谦逊。这样我才可能在花甲之年，成为文中那个受人尊敬的老者。
结语
当你遇到不同的人，不同的公司时，千万不要见怪。其实一切的不适应都只是你不喜欢变化的烂借口。而且当你足够牛逼时，你可以影响他人，当你有足够的影响力的时候，你有能力改变一些事情。
网友评论