批量发布软件 软件研发的这些误区，你中了吗？
专业出黑
僵尸式站会，指的是那种照搬方法论框架，追求形式主义的站会现象。这一现象，人们往往会面临“站会是要站着开，还是坐着开？计划会议需要分上下午两场，还是集中在下午？”这样的问题。过分关注活动的形式，而忽略了问题本身就是本末倒置。
方法论框架的目的是为了交流理解的需要，而不是生搬硬套，照本宣科。软件项目协作，应该关注问题的解决，阻塞的移除，关注需求如何快速从前一道工序流动到下一道工序。项目协作中，应该关注：
我们建议的站会 6+1，是对协作中关注问题的一个指南。
我们不建议照搬哪个方法论的框架，如站会是要站着开，还是坐着开？计划会议需要分上下午，还是一个下午？过分强调活动的样式，就是形式主义。方法论框架的目的是为了交流理解的需要，而不是生搬硬套，照本宣科。
一切不以解决问题为目的的形式主义都是耍流氓。
【要诀】站会 6+1。
跨职能团队 vs 单一职能团队
以需求价值驱动，流动效率为核心，意味着在协作过程中，必须以业务驱动，拉通从业务、产品，到开发和测试的各个职能，跨职能协同。单一职能的团队，容易形成职能竖井，导致各个职能在局部繁忙，但是整体系统协作效率低下。
我们假设团队内部的沟通效率始终大于跨团队沟通的效率，通过组建跨职能团队，可以有效提升在协作中的等待问题，让整个团队关注在需求的交付上，而不是任务的完成。跨职能团队可以是实体团队，如果没有条件，组建虚拟的跨职能团队也是一个非常不错的尝试。
【要诀】可以虚拟组建跨职能团队，拉通从业务、产品，到开发和测试的各个职能，跨职能协同。
人们过分强调代码评审（Code ）的作用，而忽视了自动化代码扫描的能力。代码评审本身并不能直接提升代码质量，代码评审是社交化编程的一种手段，旨在代码评审中，形成促进团队内部知识共享，提高团队整体水平，确保团队统一规范。其本身是员工编程技能培养的一种手段。
图片来源于互联网
代码扫描，可以自动化地完成代码质量的检查，借助技术手段，促进代码的高可见性，如代码的重复度、复杂度、扇入扇出依赖度、领域语言识别等等，这远比人工的检查效率高出许多。同时，结合静态代码扫描和规约扫描，把一般性的问题可以快速识别出来，如格式问题、基本的语法错误、潜在的内存问题等等；而对于一些内存问题及性能问题，也可以通过动态检查的手段来检查，如 C/C++ 中，常用 ，llvm-clang， 等等小工具就可以完成相应的动态检查。
对于 Java 开发者而言，Java 开发手册是一个不错的手段，同时，云效代码管理工具，内置代码安全扫描等功能，可以抓出代码的大部分安全问题。
【要诀】代码评审是开发者能力培养的手段、而非质量守护手段。借助代码规约，通过代码扫描完成代码质量检查。
持续发布 vs 批量发布
持续发布，就是持续地发布，即持续、快速、可靠地发布软件。持续发布，有助于问题的快速发现，同样，持续发布有助于工程效能问题的发现，需要做到持续发布，意味着：
持续发布意味着持续获得反馈，每天的工作有反馈。更多的反馈和持续改进的机会，有助于质量及工程效率的提升。基于云的一站式代码托管和持续发布系统，可以快速发现，即时反馈。让在线发布协同成为可能。
批量发布意味着大爆炸式集成，问题集中爆发，传统的以瀑布或大迭代方式的开发方式，一般都是批量的发布方式，在当前业务不确定性如此强，变化如此快的大环境下，这种批量的发布越来越不受待见。
【要诀】建立统一发布流程和规范，通过工具或云原生技术实现一次构建多次部署。
自动测试 vs 人工验证
持续发布的效率，在很大程度上受制于质量验证的效率，人工验证的方式，完全依赖于人工验证的速度，对于互联网多端多环境的开发方式，人工验证的手段完全跟不上工程效率的需要。采用自动化的回归的方式，让开发者每次提交都能快速获得反馈，安全放心，有信心。
常见的自动化测试手段可以用于基于 Robot , 等工具进行接口的自动化测试，服务间调用的契约测试，流量回放等等。
这样，有了自动化的回归手段，开发者提交代码，自动触发持续集成系统的回归验证，在第一时间就能获得反馈，有问题快速进行定位修改，再提交，再回归。
【要诀】自动化回归，自动化测试，持续反馈。
下图为基于云效构建的 协作示例：
