这里是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 不主动推进项目进度/
资深的程序员身上会有那种领袖气质，这种领袖气质并不是凭空出现的，而是需要有主动推进一件事往前发展的意愿。
而那些有资历却缺乏经验的程序员们则完全相反，只着眼于自己的一亩三分地，其它的都与我无关。如此一来他们也错失了快速扩大自己能力圈的机会。
从资历的这个角度上来说，作为团队里懂得最多的人，是推动项目往前的最佳人选。
所以，我们可以建议他们多给出自己积累多年的经验，因为“你是专家”。
怎么样？是不是很多现象都很熟悉？
其实还有很多其它的现象，只是上面这些是比较常见的。
其实我们不是在吐槽他们，而是希望他们能够发挥自己真正的价值，这不仅仅是为了整个团队创造更好的工作环境，也是为了避免他们迷失在走向中年危机的道路上。
希望大家能够多多转发，能叫醒一个算一个，帮助他人，也是帮助自己，不香么。
原创文章，转载请注明本文链接: https://zacharyfan.com/archives/1523.html
关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描二维码~
定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。
如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。
如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。
