程序员又要背锅了，但是这次的锅背得不冤！

作为程序员，尤其是工厂自动化领域的程序员，有一个词我们必须要熟悉，那就是“互斥”，互斥是什么意思呢？简单地说，就是A事件的发生与B事件的发生不应该同时进行，这在软件开发领域其实非常常见，自动化领域你不做好互斥，那就是人命关天的事情你没去做，最终可能摊上大事。

为什么要说互斥呢？不知道大家看新闻了没有，那就是夜晚有一辆正在高速路上高速行驶的车辆，驾驶人使用车内智能语音功能想要关闭车内灯光，结果，智能语音助手直接把全车灯光都关了，其中就包括前大灯。此时，高速路上黑漆漆一片，包括驾驶人在内的全车人员都陷入了恐慌之中……

这件事情本身我不评论，我不是搞车子的，什么为什么没有实体按键，我都不关心，我关心的是，写这个车机的项目团队此时一定如履薄冰，因为他们犯了一个软件开发的基本错误，那就是没有互斥！

首先，时间节点是晚上，其次车辆正在高速行驶（挂在D档），那么，此时关闭车辆大灯有没有隐患？驾驶员要求正在高速行驶的车辆关闭车辆大灯这个要求有没有问题？

显然，在大部分情况下是有问题的，我们还得假设一些特殊情况，比如说有些地方的夜晚的确比较明亮，不需要开大灯，或者驾驶员选择在高速行驶时关闭大灯有他自己特殊情况存在，那么此时如果车机就硬性规定不让关闭大灯，似乎也不合理。

那么，常年做软件开发的人一定知道，那就是敏感操作需要做一次确认，比如说，当驾驶员要求车机关闭车内灯光时，车机如果有确认功能，那么车机应该询问：“是否确认关闭全车灯光？”

注意，这么做的好处是，让驾驶员知道车机是怎么理解自己的命令的，如果车机当时有向驾驶员确认，当驾驶员听到“关闭全车灯光”，注意“全车”这两个词很重要，说明车机理解的是它收到的命令是把车子所有灯光全关掉。

此时，驾驶员听到车机是这么理解的，自然会选择重新纠正自己对车机的命令了！

这就像现在很多车子在行驶过程中车门会自动落锁一样，如果你真的要开门，通过驾驶员侧的解锁按钮也是可以开门的，因为一定是有特殊情况支撑着这套逻辑的。

像这种既互斥，又可以解的情况一般都是需要做二次确认的，我们叫“主动互斥，敏感操作，二次确认”。

有人会说：如果他通过物理按键或者在车机屏幕上操作关闭车子大灯呢？

没必要杠，有人还把油门当刹车使呢！

总得来说，我觉得这次事件把整个车机团队都开除我都觉得不为过，因为他们已经犯了一个软件开发最危险的错误，一般这种情况，如果是在自动化行业，没有做互斥，你都过不了项目验收！

软件开发的基本原则其实就是把用户当傻子，一个傻子会做出任何事情，因此，我们写软件时做好防呆的同时，也要做好互斥！

此次事件，首先车机测试人员估计是要下岗了，因为作为一名测试人员，你就是要以傻子的角度去看待车机的每一项功能，把任何可能出现的工况都考虑进去，而不仅仅只是测试软件有没有BUG、会不会崩溃。

然后写这个功能的程序员估计也是要下岗了，但凡是一个稍微有点经验的程序员，写这块逻辑的时候就应该会想到这个互斥逻辑，那就是高速行驶并且是晚上的情况下，是否应该向驾驶员确认，甚至于，有些车机可以识别是否是主驾命令，非主驾命令在此时如果理解的是关闭全车灯光时应该不予理会！

这是一个程序员的基本职业素养，高层次的逻辑你可能想不到，但是这种稍微想下就能想到的问题，即使产品经理没有提，你也应当能想到！而不是产品文档上怎么写，我就怎么写！

我们过去在软件开发过程中很多需要互斥的情况，基本上都不是产品经理或者测试提出来的，基本上都是我们这些当程序员的自己凭借自己的职业经验和常识得出来的，最后再反馈给项目组确认是否需要添加这些互斥的情况。

其他人我不说了，基本上都是连带关系，出了这种事情，我估计在车机项目这块是很难混下去了！

自动化行业尤其是这样，比如你操作一台机器手，如果你只是仅仅操作一台机器手去动，完全不考虑其他的话，作为一名程序员，这种项目我都不敢做！

就像我们公司之前设计的一个机器手项目，为了安全，在机械手的行程之内加了围栏，我就问他们，围栏只是一层保障，万一人进入围栏里面怎么办？

所以，我们最终在机械手围栏四周还加装了雷达以及电子门锁，双重保障，操作机械手的时候必须保证电子门锁是关着的，雷达是检测是否有阻挡的（比如说人），两种情况任何一种被触发都会触发互斥！

结语

总之，不管这个车机是谁写的，或者说是谁写的这个模块，他真的要反思一下自己，为什么这么简单的工况他都没有考虑到？当然，责任肯定不是他一个人的，但是从我的角度来说，这个程序员如果当初没有提过自己的意见，那么这个程序员一定不是一个好的程序员，至少现在不是！

当然，也不排除有些犟种项目经理，因为我们以前经常遇到自己提出的合理问题被否决的事情！只能说遇到这种项目经理，那是整个公司的悲哀！

最后，我还要补充一句∶我们是不是对现在的语音识别准确度太过自信了？