今天读到了《程序猿的修炼之道》关于“正交的优点”一节，突然间想起了一件事情。
关于当年參加飞思比赛的故事。
话说參加完这个比赛之后，最引以为豪的作品还是由我们队一路摸索建立起来的无线通信上位机调试技术（就姑且称之为技术吧），这项技术带来的优点是显而易见的，方便的查看各项执行数据为调整策略提供根据，方便的设置关键变量以尽快获取最佳执行參数。方便的检查各类传感器状态以确定其执行是否正常。
因此，我多次建议后来的师弟将这一成果沿用下去。并进行必要的改进。
在为他们提供的技术资料中，以及在后来的口头交流时，我发现自己当时忽略了非常重要的一点。
作为打着酱油便成为学校 LabVIEW 俱乐部的创立人员之中的一个的我。过分地强调了使用 LabVIEW 来开发上位机程序方面的优点，提供了大部分的 LabVIEW 文档和參考实例程序而忽略了其它细节。
同一时候在帮助师弟调试时也把重点放在了怎样在 LabVIEW 上呈现数据以及呈现哪些数据的问题上。也怪不得后来有些师弟抱怨说在调试过程中出现了非常多困难。以至于有些连无线通信模块都没有顺利调通，我但是还附带了測试通过的源码的啊。
回到重点，我究竟忽略了什么——编程中的正交原则。
其实，调试模块的最核心部分——通信模块——的代码不是我自己编写的，我仅仅定义了通信过程採用的协议，然后就把沉重的实现任务交给了我们英明神勇的队长了。这个协议不是说智能小车封装数据和上位机解码数据时採用的协议，而是指通信模块怎样将小车上依据不同任务要求封装的不同长度数据转运到上位机上（原理很easy，实现应该也不会太复杂）。就是这个部分，无意间满足了正交的原则（当时我自己是不知道的），它跟两端数据的详细封装解码方式是不相关的，所以在 LabVIEW 不同的 Tab 里面，我能够随意的定义须要完毕的任务。仅仅接收呈现数据。还是仅仅发送设置參数，或是两者兼有，又或者示波器仅仅显示两组数据。还是显示八组数据，都不会产生错误。而实现过程，仅仅需调整上位机界面的安排和小车相应的參数，而无须去修改通信模块中的不论什么一行代码（这部分代码的核心在连接电脑 USB 接口的用 AVR 实现的子模块上），从而最大程度保证了其灵活性。了解了这一块的设计原理。基本上就了解整个调试模块的精髓。至于 LabVIEW 程序这部分，反倒变得相对简单了（事实上我当时编写的程序还包括了一个 Bug），而它之所以看起来像个庞然大物。则全然是出于我当时这门语言没学好（如今也没学好）的缘故（没有依照生产者-消费者模式设计，没有使用事件结构，没有状态机，没有封装子 VI 等，后面自己又写了一个精简版的才大致上融入了这些特性）。
这里，正交强调的是独立性，而这样的独立性经常能够带来通用性。所以，在模块化设计渐成主流的今天。我们更要强调的是模块之间的正交性。