程序員又要背鍋了，但是這次的鍋背得不冤！

作為程序員，尤其是工廠自動化領域的程序員，有一個詞我們必須要熟悉，那就是“互斥”，互斥是什么意思呢？簡單地說，就是A事件的發生與B事件的發生不應該同時進行，這在軟件開發領域其實非常常見，自動化領域你不做好互斥，那就是人命關天的事情你沒去做，最終可能攤上大事。

為什么要說互斥呢？不知道大家看新聞了沒有，那就是夜晚有一輛正在高速路上高速行駛的車輛，駕駛人使用車內智能語音功能想要關閉車內燈光，結果，智能語音助手直接把全車燈光都關了，其中就包括前大燈。此時，高速路上黑漆漆一片，包括駕駛人在內的全車人員都陷入了恐慌之中……

這件事情本身我不評論，我不是搞車子的，什么為什么沒有實體按鍵，我都不關心，我關心的是，寫這個車機的項目團隊此時一定如履薄冰，因為他們犯了一個軟件開發的基本錯誤，那就是沒有互斥！

首先，時間節點是晚上，其次車輛正在高速行駛（掛在D檔），那么，此時關閉車輛大燈有沒有隱患？駕駛員要求正在高速行駛的車輛關閉車輛大燈這個要求有沒有問題？

顯然，在大部分情況下是有問題的，我們還得假設一些特殊情況，比如說有些地方的夜晚的確比較明亮，不需要開大燈，或者駕駛員選擇在高速行駛時關閉大燈有他自己特殊情況存在，那么此時如果車機就硬性規定不讓關閉大燈，似乎也不合理。

那么，常年做軟件開發的人一定知道，那就是敏感操作需要做一次確認，比如說，當駕駛員要求車機關閉車內燈光時，車機如果有確認功能，那么車機應該詢問：“是否確認關閉全車燈光？”

注意，這么做的好處是，讓駕駛員知道車機是怎么理解自己的命令的，如果車機當時有向駕駛員確認，當駕駛員聽到“關閉全車燈光”，注意“全車”這兩個詞很重要，說明車機理解的是它收到的命令是把車子所有燈光全關掉。

此時，駕駛員聽到車機是這么理解的，自然會選擇重新糾正自己對車機的命令了！

這就像現在很多車子在行駛過程中車門會自動落鎖一樣，如果你真的要開門，通過駕駛員側的解鎖按鈕也是可以開門的，因為一定是有特殊情況支撐著這套邏輯的。

像這種既互斥，又可以解的情況一般都是需要做二次確認的，我們叫“主動互斥，敏感操作，二次確認”。

有人會說：如果他通過物理按鍵或者在車機屏幕上操作關閉車子大燈呢？

沒必要杠，有人還把油門當剎車使呢！

總得來說，我覺得這次事件把整個車機團隊都開除我都覺得不為過，因為他們已經犯了一個軟件開發最危險的錯誤，一般這種情況，如果是在自動化行業，沒有做互斥，你都過不了項目驗收！

軟件開發的基本原則其實就是把用戶當傻子，一個傻子會做出任何事情，因此，我們寫軟件時做好防呆的同時，也要做好互斥！

此次事件，首先車機測試人員估計是要下崗了，因為作為一名測試人員，你就是要以傻子的角度去看待車機的每一項功能，把任何可能出現的工況都考慮進去，而不僅僅只是測試軟件有沒有BUG、會不會崩潰。

然后寫這個功能的程序員估計也是要下崗了，但凡是一個稍微有點經驗的程序員，寫這塊邏輯的時候就應該會想到這個互斥邏輯，那就是高速行駛并且是晚上的情況下，是否應該向駕駛員確認，甚至于，有些車機可以識別是否是主駕命令，非主駕命令在此時如果理解的是關閉全車燈光時應該不予理會！

這是一個程序員的基本職業素養，高層次的邏輯你可能想不到，但是這種稍微想下就能想到的問題，即使產品經理沒有提，你也應當能想到！而不是產品文檔上怎么寫，我就怎么寫！

我們過去在軟件開發過程中很多需要互斥的情況，基本上都不是產品經理或者測試提出來的，基本上都是我們這些當程序員的自己憑借自己的職業經驗和常識得出來的，最后再反饋給項目組確認是否需要添加這些互斥的情況。

其他人我不說了，基本上都是連帶關系，出了這種事情，我估計在車機項目這塊是很難混下去了！

自動化行業尤其是這樣，比如你操作一臺機器手，如果你只是僅僅操作一臺機器手去動，完全不考慮其他的話，作為一名程序員，這種項目我都不敢做！

就像我們公司之前設計的一個機器手項目，為了安全，在機械手的行程之內加了圍欄，我就問他們，圍欄只是一層保障，萬一人進入圍欄里面怎么辦？

所以，我們最終在機械手圍欄四周還加裝了雷達以及電子門鎖，雙重保障，操作機械手的時候必須保證電子門鎖是關著的，雷達是檢測是否有阻擋的（比如說人），兩種情況任何一種被觸發都會觸發互斥！

結語

總之，不管這個車機是誰寫的，或者說是誰寫的這個模塊，他真的要反思一下自己，為什么這么簡單的工況他都沒有考慮到？當然，責任肯定不是他一個人的，但是從我的角度來說，這個程序員如果當初沒有提過自己的意見，那么這個程序員一定不是一個好的程序員，至少現在不是！

當然，也不排除有些犟種項目經理，因為我們以前經常遇到自己提出的合理問題被否決的事情！只能說遇到這種項目經理，那是整個公司的悲哀！

最后，我還要補充一句∶我們是不是對現在的語音識別準確度太過自信了？