今天讀到了《程序猿的修煉之道》關於“正交的優點”一節，突然間想起了一件事情。
關於當年參加飛思比賽的故事。
話說參加完這個比賽之后，最引以為豪的作品還是由我們隊一路摸索建立起來的無線通信上位機調試技術（就姑且稱之為技術吧），這項技術帶來的優點是顯而易見的，方便的查看各項執行數據為調整策略提供根據，方便的設置關鍵變量以盡快獲取最佳執行參數。方便的檢查各類傳感器狀態以確定其執行是否正常。
因此，我多次建議后來的師弟將這一成果沿用下去。並進行必要的改進。
在為他們提供的技術資料中，以及在后來的口頭交流時，我發現自己當時忽略了非常重要的一點。
作為打着醬油便成為學校 LabVIEW 俱樂部的創立人員之中的一個的我。過分地強調了使用 LabVIEW 來開發上位機程序方面的優點，提供了大部分的 LabVIEW 文檔和參考實例程序而忽略了其它細節。
同一時候在幫助師弟調試時也把重點放在了怎樣在 LabVIEW 上呈現數據以及呈現哪些數據的問題上。也怪不得后來有些師弟抱怨說在調試過程中出現了非常多困難。以至於有些連無線通信模塊都沒有順利調通，我但是還附帶了測試通過的源碼的啊。
回到重點，我究竟忽略了什么——編程中的正交原則。
其實，調試模塊的最核心部分——通信模塊——的代碼不是我自己編寫的，我僅僅定義了通信過程採用的協議，然后就把沉重的實現任務交給了我們英明神勇的隊長了。這個協議不是說智能小車封裝數據和上位機解碼數據時採用的協議，而是指通信模塊怎樣將小車上依據不同任務要求封裝的不同長度數據轉運到上位機上（原理很easy，實現應該也不會太復雜）。就是這個部分，無意間滿足了正交的原則（當時我自己是不知道的），它跟兩端數據的詳細封裝解碼方式是不相關的，所以在 LabVIEW 不同的 Tab 里面，我能夠隨意的定義須要完畢的任務。僅僅接收呈現數據。還是僅僅發送設置參數，或是兩者兼有，又或者示波器僅僅顯示兩組數據。還是顯示八組數據，都不會產生錯誤。而實現過程，僅僅需調整上位機界面的安排和小車相應的參數，而無須去修改通信模塊中的不論什么一行代碼（這部分代碼的核心在連接電腦 USB 接口的用 AVR 實現的子模塊上），從而最大程度保證了其靈活性。了解了這一塊的設計原理。基本上就了解整個調試模塊的精髓。至於 LabVIEW 程序這部分，反倒變得相對簡單了（事實上我當時編寫的程序還包括了一個 Bug），而它之所以看起來像個龐然大物。則全然是出於我當時這門語言沒學好（如今也沒學好）的緣故（沒有依照生產者-消費者模式設計，沒有使用事件結構，沒有狀態機，沒有封裝子 VI 等，后面自己又寫了一個精簡版的才大致上融入了這些特性）。
這里，正交強調的是獨立性，而這樣的獨立性經常能夠帶來通用性。所以，在模塊化設計漸成主流的今天。我們更要強調的是模塊之間的正交性。