软件行业有一个流传很久的笑话：当两个程序员争论使用空格还是制表符进行缩进时，他们去找领导寻求解决方案。领导说：“我们使用空格缩进四个空格。”。

技术偏好造成团队冲突广泛存在于每个软件开发团队，这是一种 Geek 文化。 甚至因为技术偏好，放弃高薪或者因意见不和大打出手的情况。

当团队中资深的程序员越多时，因为技术偏好产生的冲突会越来越多。作为 Tech Lead 如何应对这类情况？

如果将软件团队的治理模式和国家对比来看，可能有这样几种情况：

• 君主：团队领导（PM）拥有绝对的权利，可以开除任何人，下达任何命令，但是自己不太懂技术，但是技术实施需要由技术骨干或者技术经理完成。团队领导可以制定规范和规则，但是自己不用严格遵守。
• 军阀：技术经理拥有绝对的权利，也可以制定规范和规则，也拥有开除人员的权利。
• 民主：技术经理没有绝对的权利，可以制定规范和规则，但是无法让每个人强制执行。

在"君主"和"军阀"这类团队自然不存在意见不同的问题，所有意见都会由领导决定。 在民主团队中（尤其是一些外企），我见到的 TL 往往都是通过影响力来平息技术偏好的争端，这就需要资历和经验都非常充分的人干这个岗位。

我们尝试从流程和机制上找到方法。因此在一些团队上，我们会尝试使用：

用提案+评审的方式处理团队不同意见。

在团队中推广基于流程和规则的方式解决冲突，来解决技术规范和决策的问题。

例如，在项目前期制定如下约定：

• 团队共同维护团队规范、打样工程（Demo）、技术决策记录。
• 团队成员需要遵守团队规范，并参考打样工程实现业务需求。
• 对团队规范有意见的，可以在团队内发起规范调整申请，需要分析调整规范带来优越点和成本，团队一致通过后（比如采用投票的方式）采纳，并创建技术债务修改存量代码
• 对团队技术方案有意见的，可以在打样工程实现可替代的方案，并发起评审

这套约定的逻辑是，对规范和技术方案有意见必须通过更好的代替方案来发起评审，而不是"口嗨"；评审内容需要争取半数以上的人员支持。

这个过程需要进行记录，形成团队的决策过程，对后续的架构溯源非常有帮助。 另外，决策前一定要充分的枚举代替方案，避免陷入为主的想法忽略了更好的替代方案。

提案+评审机制的好处是：

• 避免某个成员之间发生直接冲突。
• 让团队拥抱不同声音，保持对意见、新的想法开放。
• 避免意见提出者提出的只是一个想法，而应该一个可以被执行的方案。
• 团队的重大决策有决策记录。