程序开发中匪夷所思的事情

王媛满

把一群程序员放在一起很多时候他们并不会互相学习，只有平时有共同理想，愿意唠嗑，愿意一起解决难题，愿意听对方的意见和分享的的一群小伙伴，才会在不知不觉中互相学习互相指导。

最近看了一本名字叫《程序开发心理学》的“闲书”，收获满满，润色一下分享给大家。

关于团队的互相学习成长

我们经常都会说，要进入到一个高手比较多的地方去学习。身处一个高手遍地的地方，会发现人跟人差距就是这么大，而且高手做的事情你一点也插手不上，而且很多情况下也没法学习到什么东西，很多时候高手最厉害的地方在于经验和思维。如果只是在一个项目里边分工合作，而除了干好自己的事情以外没什么其他的目标了，那么很抱歉，你可能学不到什么东西。

书中有一段是这么说的：如果一个集体的共同目标仅限于产品的层次，那并不见得会促使其中的程序员互相学习。而反过来，团队内部的成员不仅目标一致，而且其目标与他们具体开发的产品毫无关系，正是在这种目标的引导下，团队的成员才会通过互相学习共同提高。

就本人的经验来看，大部分程序员在一起工作并不会互相学习。如果是导师，那可能会有一些经验的指导。如果是平级，那可能一年下来都不会互相学习。就算是经常有合作，很大可能性也只会在项目功能接口层面进行沟通。一方面是术业有专攻其他领域其实挺难去介入的，另外一方面可能思维上就没想能从A项目、B项目和别人的产出上面学到什么东西。

但是如果，仅仅是如果，如果所有人都有一个评判标准，以及都有一颗想提高自己代码质量的心，会进行代码review。代码review过程其实是能产生很多东西的，同时也能学习到很多东西，但是有个大前提，就是大家的对这个事情本身也感兴趣，而不是为了具体的产品。根据以往的经验，这种事情很快就流于形式，也就是随便看一看，就算是精心准备的分享基本也都会被听众忽略掉，这就没什么意义了。但是如果整个团队对分享和代码review这个事情本身很感兴趣，还是能从中进行查漏补缺得到非常多的信息。

人类总会本能性地，反对别人对自己的负面评价。即使面对来自现实难以接受的反面证据，人们也往往会认定自己的程序完全正确。

“这不是bug，重启一下试试。”

“这不是bug，绝对是使用方式有问题。”

很多时候人类都是会逃避对自己的任何负面评价的，无论这个评价是不是从很多人的角度看来都无可辩驳，毕竟计算机不会骗人，它只会做我们告诉它要去做的事情，但是人对它结果的解读是带有主观性的。一个很好的功能，到了另外的场景可能就是bug。一个很难解决的bug，到了另外一个场景可能就是一个很好的功能。

有这么一个小故事，很久很久以前，我们的程序有一个bug总是找不出来，就是有一段内存总是会随机性丢失。我们就开始查，拼命查，没日没夜地查，程序员走了一波又一波。但是依然都找不到这个问题所在，很是苦恼。突然有一天，咦，有一个地方需要模拟一个场景，就是内存随机性丢失的场景下对程序进行测试。喔吼！这个带“Bug”的程序比任何人为构造出来的内存丢失更加随机更加可以反映事实，而且在很长一段时间里都非常“稳定”。

现在你还觉得这是一个Bug吗？

关于团队的高效

有些主管依然会与高效的程序开发团队发生冲突，并进而又以各种毫不相干的借口，将这些团队解散。而有些主管虽然还是搞不懂这些团队的运行方式，但是他们却至少懂得应该容忍这些团队的存在。

在很多的职场，都会出现这么一个现象就是有其中一个团队效率非常非常高，而且交代的事情也能完成得非常非常好，但是主管看不懂。他不明白为什么这帮人就行，另外一帮人就不行，也不是能力上的问题，因为大家都是同样标准招进来的。

有的主管能很好处理，不理解就不理解，这些事情交给他们就稳了，我对他们也爱护有加就行了。而有的主管则不能，就是希望掌控全局，任何一个小细节都不放过，对于这些超出认知范围的事情很是“扎心”，一定要插一手，所以就出现了上边的情况。

程序开发的社会效应

关于程序开发的社会性。比如程序开发中其中有一个环节就是程序员A口头将信息告诉程序员B，这在以往的运行过程中得到了非常好地效果，这时候如果换掉程序员A或者程序员B，都将带来效率的降低。

很多时候我们都以为我们的程序运行都是靠完美的产品设计，稳定的系统流程，全链路能Cover住。很遗憾不是这样的，我们处在的是人类社会，是人类在使用这些东西。只要有人类介入，那绝对存在一些很“迷”的东西。

比如，有一个功能开发好了，开发的第一反应不是去系统上点一下完成，而是大吼一声：“测试大佬，我那个Bug修好了你验收一下”。

又比如，很多程序員都会去找架构师聊事情，但是我们又发现有很多程序员坐在架构师旁边的咖啡小屋那叽叽喳喳，所以老板决定把这个咖啡小屋干掉。好了事情来了，架构师开始忙不过来，大大小小的事情都找架构师解决。原来有这么一个咖啡小屋，大家看起来叽叽喳喳的很吵，但是其实大家在等架构师空闲的时候，已经在咖啡小屋把很多小事情讨论完了，或者梳理出了一个比较可行的方案，这样会节省架构师的时间，也会节省程序员的时间。

关于程序员的作息

一个老板看到程序员王铁蛋早上十点才到，很是不爽，就跟程序员说啊我不管你明天要早点来。（其实程序员昨天晚上才把某个比较紧急的东西加班弄完到深夜）王铁蛋的反映非常简单，无非是严格按照工作时间正常地上下班。

还是希望小伙伴们，多去健身房，晚上确实要加班也可以，吃完饭健身完再继续加，尽量十二点前睡下，过几年你会回来感谢我的。

希望你们要克服人类的通病———假装自己很努力。

关于民主和集权的领导模式

民主性集体。由于任务是全体成员共同承担的，同时他们之间存在很多交流，所以当某个人离开后，其他的伙伴会根据需要填补它的空缺。但是反过来也证明，如果有一个新来的，由于组织中并不会给他留出一个特定的位置，所以这样的团队很难接受新成员。

集权式集体。任何成员离开后自然就会暴露出任务分工上的空缺，只有其领导者才拥有必要的信息能够在剩余的成员中重新进行任务分配。但是如果有新成员加入，手续会非常简单，直接去找领导人分配任务，然后交接就好了。

关于给项目泼冷水的人

会议上一片和谐，大家都对于接下来要完成的事情胸有成竹，开始小声庆祝除了小乔，嘴上有一点点抿嘴。然而目光尖锐的项目负责人凭经验还是察觉到了这个细节，问小乔：你还有什么问题吗？

“一切都正常，但还是有一点点小问题。”

“有多小？”

“我的任务可能需要延迟一点点。”

“多久？”

“六周。”

“我想……我的小组也需要这么久”，大乔说道。

“我也需要……”孙尚香、曹丕都顺着说道。

这就是刚刚和谐开会的结果？我们刚刚浪费了一个小时在讨论什么？

也许，需要有这么一个提出不同声音的人，来质疑这个计划以及那虚假的和谐，来保证这个项目的正常进行，很多开发对于程序开发中需要消耗的时间还是过于乐观，觉得代码写完就完事了，又或者是对于项目本身不了解的盲目乐观，这就是非常非常多情况下项目延期的原因。如果有一个人，指出这些方案的不合理性，又或者是项目时间的不合理性，可能就不会在项目延期的时候互相推诿了。

然而在现实中，这个人经常被当成喷子，被认为是来破坏和谐的人……

关于天才程序员

优秀的程序员是培养出来的，不是天生的。

程序员其实现在都已经是一个门槛非常低的职业了，但是也存在跟数学一样循序渐进的过程。要知道A定理，才会觉得B推论理所当然。如果不知道A定理，那么“大佬”在说显然可得B推论的时候，你就会觉得很痛苦，这就是先前知识产生的壁垒。

程序员也是一样，要知道足够多、足够底层的东西，你会发现现在所有的技术都只是在层上有一些封装、拓展和易用上的改进，所玩的花样基本都还是几十年前的理论，没什么大的变化。所以要像正常学习的节奏，去学习、去深究，去交流。当然无论是玩耍、游戏还是学习，只要觉得开心都可以去做，能在学习上觉得开心的肯定是少数，毕竟学习很多时候都是一件逆人性的事情。但是一旦克服了，恭喜，你已经比很多人厉害了。

所以你需要大量的练习。平时看到喜欢的东西，就去学就是了，就去练习就是了，管他什么跨界、什么太難，当玩具去玩就是了，再把它总结出来分享给大家，让大家挑刺，有一天你很可能也会成为很多人眼中的“天才”。