怎么开好代码交流会

代码交流会不是一个什么新概念，很多做开发的人都应该听说过，但应该很少有公司把这个当作一个例行的事情来做，本文就从多个方面讲讲代码交流会。

为什么要开代码交流会

代码交流会可以提升技术人员的沟通表达能力，而这是团队协作的最基础的技能。如果沟通能力不强，相互不能理解对方意图，即使好像相互理解了，又出现”产品设计是A，开发做出来是B”的情况。

开发人员通过写技术交流文档，可以帮助自己梳理思路，发现自己思路当中的问题。而且文档写出来后，讲给团队成员听，也可以让团队成员协助发现问题，所以写交流文档不光是给自己看的，也是给团队成员看的。在公司的代码交流实践当中，程序员普遍有个思想，”到时候照着代码讲解好了”，这是一个非常错误的思想。因为团队成员的技术领域是不同的，其他人不一定可以看懂你的代码，但如果你能把自己的思路变成一种流程图或者各种表格展现方式，然后再经过你的讲解，其他人就相对毕竟容易理解你的思路，发现其中的问题。所以，文档作为团队交流中的一个公共语言，是必须要磨练熟练的，关于文档的能力，请您参看"为啥开发的文档能力是核心竞争力之一”。下图是本人和一个团队成员就这个文档问题的交流沟通，通过代码交流会这种培训形式，提升他们的团队协作意识和能力。

通过技术交流会，可以加强团队成员之间的理解，是一个团队成员之间相互教育的过程。比如UI和产品设计前端产品的时候，很多时候是不知道或者不理解技术上存在的困难的。通过技术交流分享，前端程序员可以讲解一些前端设计为啥不能实现的原因，以及今后产品设计需要注意的地方，比如，为了提升前端性能，不能使用大图片，最好使用文字按钮，使用图片自动拉伸功能等。开发和产品之间交恶的故事很多，根本上还是大家不能相互了解和理解对方工作的原因。

通过技术交流会，可以发现一些设计上的潜在问题，把问题扼杀在设计阶段，而不是应用了以后才发现。当然有些问题是必须具备丰富的实战经验才能发现的，但发现一些总比没有发现要好，而且这种能力也是需要时间来逐步锻炼的，不是一下子就能实现的。下面结合2个实际案例，讨论一下这个问题，一个是洗车机嵌入式编程问题，一个是消息队列使用问题。嵌入式编程部分涉及到外包团队，他们在协议设计阶段，没有考虑到模块升级和IP地址远程变更问题，导致后续真机测试和嵌入模块升级都很麻烦，每次都需要人亲自跑过去。

 

分布式系统在设计阶段一定要考虑自动化升级和自动化测试问题，因为是外包团队，所以他们设计协议之前也没有跟我们仔细交流，导致没有帮助他们发现这个致命的问题。

还有一个案例是公司后台程序员的问题，居然不知道自动创建队列，每次服务重启，都需要手工创建消息队列。该程序员表达思路一直不是很清晰，每次交流文档思路也混乱，自己也缺少精益求精的态度，在本人看来，每次手工创建队列，这个难道不麻烦吗？自己操作几次也该发现这个不方便了吧，如果当初他能够提出这个问题，也就能帮他把这个问题消灭在设计阶段了，也不至于其他后台成员花半天时间来查找问题了。

上面两个案例中，开发本身都缺乏测试思维，想当然的认为发生概率不高，就不重视，甚至没有提出潜在问题的意识，最后导致后续开发，测试和维护成本的提高。因为技术领导不可能，也没有时间去时时刻刻监控团队每个人的工作，所以就需要培训团队提出问题的意识，通过技术交流会，不断的去复盘之前出现的问题，让大家去思考，怎么在今后的工作中，避免类似问题的出现。让大家有质量的意识，不要想当然的自己认为是低概率事件，就去忽略，起码应该把问题提出来，让大家讨论，让技术领导帮助分析利弊后再决定。这样，一方面可以大大降低团队的开发成本，另一方面也可以锻炼自己思维的严密性。

代码交流会是发现人才的机会，让每个人的思路经常暴露在团队的眼光之下，哪些人思路缜密，思路活跃，做事态度积极，就一览无余了，可以是技术人员晋升的一个非常客观的指标，让公司的绩效评定更加公平合理。下面举一些在代码讨论会期间发现的重大的隐性设计问题，这些问题被消灭在萌芽阶段，大大节约了企业的开发成本和后续的维护成本。一个程序员在实现”可提现金额”需求上面使用了大SQL计算，导致每次查询都需要重复计算，而且JOIN了多个表，虽然这些表现在数据量不大时，不能体现出来性能问题，但交易表是非常容易快速增长的表，后面会有明显的性能瓶颈。如果后期发现再修改，不但影响正常业务，而且处理数据兼容问题也是比较棘手的。当时，为了让该程序员心服口服，本人让他制造几百万条虚假交易数据，测试一下效果，不但很好的培训了后台程序员，而且也为企业节约了成本，赢得了宝贵时间。

怎么开好代码讨论会

代码交流会一定要解决实际问题，不能停留在形式上面，去讨论团队正在做的事情，存在什么问题，怎么样可以做的更好，或者需要引进什么新技术来解决当前的问题。开了几次代码讨论会以后，大家感觉到没有东西可以讲了，然后就去网上找了一些时髦的但不相关的技术来讲，几个甚至去大讲Swift和Kotlin，和现在使用的技术和工作离得太远太远。本人及时制止了这种情况蔓延，这完全是形式主义，不需要对自己工作认真思考，到网上抄抄就可以完成任务，对大家都是浪费时间。经过几次对优秀者进行表扬鼓励，对敷衍者指出批评，形式扭转了过来，大家开始学会去认真思考自己的工作。很多时候，我们没有发现问题，是因为我们没有提升自己的标准，没有去仔细发现问题，如果没有问题，岂不是说明已经非常非常优秀了吗？但既然已经非常非常优秀了，为啥还总是出那么多问题呢？我告诉大家，去认真思考，去向做的好的人学习，把讨论会当成提升自己的机会，而不是负担。

开好交流会一定要持续锻炼大家的表达能力和写文档的能力，否则开会都讲不清楚问题，重点问题不知道讲，非重要问题讲个不停，浪费时间。多数开发技术人员在这个方面都非常差，所以这种能力是需要持续的有意识的培养的，不是讲几次课就能够解决的，具体对这方面的论述，请您参看”为啥开发的文档能力是核心竞争力之一”。

交流会需要有一个非常好的技术领头人，能够引导和激发大家，能够及时发现问题解决问题，让大家在交流会中感觉到持续成长，才会有持续的兴趣投入到里面来。

总结

软件开发是一个极其需要团队协作的工作，交流就是提升大家协作的能力，让团队协作能够持续提升，效率持续提升，所以，任何优秀的技术团队都应该重视技术讨论会。