今天读到了《程序员的修炼之道》关于“正交的好处”一节，突然间想起了一件事情。

关于当年参加飞思比赛的故事。

故事要从一次师弟的反馈说起。话说参加完这个比赛之后，最引以为豪的作品还是由我们队一路摸索建立起来的无线通信上位机调试技术（就姑且称之为技术吧），这项技术带来的好处是显而易见的，方便的查看各项运行数据为调整策略提供依据，方便的设置关键变量以尽快获取最佳运行参数，方便的检查各类传感器状态以确定其运行是否正常。

因此，我多次建议后来的师弟将这一成果沿用下去，并进行必要的改进。

在为他们提供的技术资料中，以及在后来的口头交流时，我发现自己当时忽略了很重要的一点。

作为打着酱油便成为学校 LabVIEW 俱乐部的创立人员之一的我，过分地强调了使用 LabVIEW 来开发上位机程序方面的好处，提供了大部分的 LabVIEW 文档和参考实例程序而忽略了其他细节。同时在帮助师弟调试时也把重点放在了如何在 LabVIEW 上呈现数据以及呈现哪些数据的问题上，也怪不得后来有些师弟抱怨说在调试过程中出现了很多困难，以至于有些连无线通信模块都没有顺利调通，我可是还附带了测试通过的源代码的啊。

回到重点，我到底忽略了什么——编程中的正交原则。事实上，调试模块的最核心部分——通信模块——的代码不是我自己编写的，我只定义了通信过程采用的协议，然后就把沉重的实现任务交给了我们英明神勇的队长了。这个协议不是说智能小车封装数据和上位机解码数据时采用的协议，而是指通信模块如何将小车上根据不同任务要求封装的不同长度数据转运到上位机上。就是这个部分，使用了正交的原则（当时我自己是不知道的），它跟两端数据的具体封装解码是不相关的，所以在 LabVIEW 不同的 Tab 里面，我可以任意的设计需要完成的任务，只接收呈现数据，还是只发送设置参数，或是两者兼有，又或者数据包只包含两组数据，还是包含了八组数据，都不会产生错误，而实现过程，只需调整上位机界面的安排和小车对应的参数，而无须去改动通信模块中的任何一行代码，从而最大程度保证了其灵活性。了解了这一块的设计原理，基本上就了解整个调试模块的精髓。至于 LabVIEW 程序这部分，反倒变得相对简单了，而它之所以看起来像个庞然大物，则完全是出于我当时这门语言没学好（现在也没学好）的缘故（没有按照生产者-消费者模式设计，没有使用事件结构，没有状态机，没有封装子 VI 等，后面自己又写了一个精简版的才大致上融入了这些特性）。

这里，正交强调的独立性，而这种独立性常常可以带来通用性。所以，在模块化设计渐成主流的今天，我们更要强调的是模块之间的正交性。