十个现象，识别程序员的“水份”

这里是Z哥的个人公众号

每周五11：45 按时送达

当然了，也会时不时加个餐～

我的第「210」篇原创敬上

大家好，我是Z哥。

下周五正好是国庆，我也给自己放个假，就不发文了。所以今天是节前最后一篇文章，先提前祝大家国庆快乐，可以好好放松一下。

今天我们不聊干货了，聊点轻松的，来吐槽一下程序员的那些事儿。

在软件开发领域一直流传着一句话，它说明了程序员的水平和资历之间并不存在着相关性，并且可能相差特别大。

到底是货真价实的十年经验？还是一年经验重复用了十年？

随着我在工作中遇到过的人越来越多、面试过的人越来越多，发现这句看似夸张的话讲述的的确是事实。

有些人工作了 7、8 年，所表现出来的专业性就像刚入行 1、2 年的新人。并且,比新人还不如的是，他们身上往往也没有了新人的那种学习欲望。

与之相对的，我也与刚毕业就加入公司的应届生共事过，他们身上所表现出的惊人成长能力，让他们在不到一年的时间内就挑起了项目组的大梁。

经过我对所接触过的程序员们的观察，我总结出了一些“信号”，他们可以帮助你识别出与你一起工作的同事到底是不是“货真价值”。

然后，你就可以与那些“货真价实”的资深程序员们多打交道、多交流，与厉害的人多在一起，自己也更容易变得厉害。

好了，下面开始。

如果你发现某位工作多年的程序员身上有这些现象出来，那么他大概率就是一位“有水份的高级程序员”。符合的现象越多，水份越大……

/01 总是喜欢“攒”一些代码后再提交代码/

不知道你有没有留意过，一个团队里只要有一个人喜欢“攒”代码，那么这个项目的代码合并将会长期面临代码冲突的痛苦。

道理很好理解，两个胖子之间的碰撞面积，总比两个瘦子大吧。

而且喜欢这么干的人往往也不太认可 CodeReview 这件事，为啥？

因为他大概率没有想过，做 CodeReview 的人，一次性看到几十上百个变更文件时的感受。

我们可以建议他们，实现或者修复一个完整的小问题和小任务，就提交一次代码。最差也得每天提交一次，当然，需要将未实现的部分做好处理，避免编译报错。

/02 很早就开始 coding，但是很晚才通过验收/

用马保国老师的话来说，“有些程序员写代码很快啊，pia 一下，我都来不及闪，他就写了好几行代码了。”

他们实现功能很快，不熟悉的人还以为是高手。但是实际上，他们修 bug 的时间往往会明显多于其他人，最终可能反而导致拖整个项目进度的后腿。

虽说不一定非得每次花时间正儿八经的画图，做设计。但是真正有经验的程序员，他们写代码之前脑子里是会先梳理好思路的，有一个清晰的达到终点的“路线”。这样他在写下每一行代码的时候，都知道他在做什么，而且下一步是什么。

所以，我们可以建议他们写代码之前，稍微多花点时间去搞清楚一些业务问题，梳理清楚需求。并且在写代码之前做一下规划，避免后来你的代码只有你自己看得懂，甚至是自己都看不懂。

/03 看上去很忙，在多件事之间来回奔波/

在团队里越是核心的人员总是越忙的，但并不是所有忙的人都是核心人员。因为有些忙是自己导致的。比如，当我们面前有多个问题需要处理的时候，不是谁来催得紧，你就先处理哪个。还得自己心里有一杆秤，根据优先级来处理。

否则，花费了大量时间在多个事情之间切换，实际真正的有效工作时间可能连一半都不到。

我们可以建议他们不管是做任何还是修 bug，搞定一个之后再进行下一个，除非每次新来的问题都比之前的优先级高。但是，应该没那么巧吧？

另外，将任务分解成小任务，也更有利于自己掌控时间。

/04 固执己见/

如果一位缺乏经验的程序员恰好又是团队里资历比较老的，那就很容易出现固执己见的情况。

这会使得他进入一个不太好的循环里去。自我感觉良好 -> 无法改掉身上的坏毛病 -> 资历老，听不进别人的 -> 自我感觉良好。

但是往往获取经验最快的方式是以开放的心态与别人交流，学习别人的长处，补足自己的短处。

所以，我们可以建议他们多考虑一下事物好坏的另一面，毕竟任何事物都有两面性。

/05 不断地重复掉进同一个坑/

毕竟有了不少工作年限，所以当遇到生产环境的 bug 时，不会出现真正的新手那样不知从何下手的情况。他们会祭出打 log 大法，或者是调试大法，用最快的速度解决问题。然后，就没有然后了。

从别人眼中看来，他们这是头痛医头，脚疼医脚。但是在他们眼里，没有任何两个“坑”是一样的，每个都不同，所以，下次相同的问题再次出现也是正常的。这种做法真的难以给人靠谱、放心的感觉。

所以，我们可以建议他们。在出问题后，先通过逻辑分析思考一下问题可能出在哪里，梳理相关的信息和思路。然后，即使解开了 Bug ，也应该多思考一下是否其他部分也有类似的问题。

/06 盲目追逐技术潮流/

你说他们完全不学习吧，也不是。当从身边很多人的嘴里听到同一个技术名词的时候，他会视该技术为传说中的“ SliverBullet ”，赶紧去学习官方教程。

但是，往往跟着入门教程走完一遍之后，就觉得这也没什么难的，自己已经掌握了。实际上，没有经过实战的使用就觉得掌握，仅仅是一种幻觉而已。因为一旦实际进行落地，往往会出现各种意料之外的问题等待着你去解决，甚至有些是连官网都未发现的bug。

他们对新技术的崇拜，其实是他们觉得，如果自己不了解这个新技术，会觉得错过些什么。

所以，我们建议他们抱着学以致用的心态去学新技术，或者至少不要只停留在官方教程上，找一个自己工作或者生活中的场景，用新技术来实现一个功能。

/07 代码写得很随意/

写代码随意的场景有很多，小到变量、方法的命名规范与否，大到整体的架构设计上是否有考虑到一些非显性的问题，如性能、扩展性等等。

缺乏经验的程序员，不但全部命中上面这些点，而且写出来的代码，其他人很难看懂，特别在一些业务本身就有一定复杂度的场景中。

相反，优秀的程序员们在编写自认为复杂的代码段的时候，会写下清晰的注释来帮助后来人理解。因为他们知道代码不仅是让计算机执行，更是需要让别人也理解的，因为项目开发大多是团队协作。

所以，我们可以建议他们在写代码的时候考虑一下，如果两年后回头来看今天写下的代码，还看得懂吗？

/08 总喜欢直接调试生产环境/

“线上有问题？来说下你怎么操作的，我调试一下。”

“接口报错？参数发我，我调试一下。”

这些是他们的口头禅。不可否认，从理论上来说，直接调试线上必然是解决问题最快的方式，毕竟直接面对案发现场。但也正是因为解决过于容易，导致自己不容易“长记性”，下次大概率还会犯一样的错误。所谓，“捷径走多了，人就废了。”

另外，一旦对项目不是100%的熟悉，那么搞不好在调试的过程中，不知不觉给生产环境产生了垃圾数据，可能进一步导致埋下了新的隐患。

所以，我们可以建议他们，遇到问题先思考，用你的专业知识和业务经验进行逻辑分析，如此，也能提炼出一些普适性的规律避免自己后续再犯相同的错误。

/09 不做自测/

前面提到过有些伙计写代码很快，其实他们之中的大部分也不会做自测，毕竟这会降低他们的开发速度。而且，在他们心里可能觉得测试嘛，不是应该测试工程师干的么，我都自测过一遍的话，不是抢他们饭碗么。

当然，如果有些公司有明确的工作要求需要自测，他们也会做，但不是去尽量模仿真实的数据，而是用很随意的数据来测试，效果其实是很差的。

自测的好处有很多，最直接的就是可以降低修复bug总时间，毕竟，开发和测试之间沟通bug的时间肯定就节省掉了。

所以，我们可以建议他们做自测，因为这不但可以让整个项目的工期得以更快完成，也能让自己和其他人摆脱加班、摆脱996，不香么。

/10 不主动推进项目进度/

资深的程序员身上会有那种领袖气质，这种领袖气质并不是凭空出现的，而是需要有主动推进一件事往前发展的意愿。

而那些有资历却缺乏经验的程序员们则完全相反，只着眼于自己的一亩三分地，其它的都与我无关。如此一来他们也错失了快速扩大自己能力圈的机会。

从资历的这个角度上来说，作为团队里懂得最多的人，是推动项目往前的最佳人选。

所以，我们可以建议他们多给出自己积累多年的经验，因为“你是专家”。

怎么样？是不是很多现象都很熟悉？

其实还有很多其他的现象，只是上面这些是比较常见的。

其实我们不是在吐槽他们，而是希望他们能够发挥自己真正的价值，这不仅仅是为了整个团队创造更好的工作环境，也是为了避免他们迷失在走向中年危机的道路上。

希望大家能够多多转发，能叫醒一个算一个，帮助他人，也是帮助自己，不香么。

原创不易，如果你觉得这篇文章还不错，就「点赞」或者「在看」一下吧，鼓励我的创作 ：）

也可以分享我的公众号名片给有需要的朋友们。

如果你有关于软件架构、分布式系统、产品、运营的困惑