第三篇，得益于混合编程

目前做自动驾驶，“被迫”改行MATLAB/Simulink。MBD有很多优势，但缺点也很明显，高度的应用化、泛化、淡化数据类型，导致容易出现效率瓶颈。拿一个例子来说，做ALC（自动变道）的时候要做轨迹规划，一个常用的方法是五阶多项式拟合，在MATLAB中用polyfit()实现，受限于MATLAB基于矩阵的计算和内部不为人知的拟合细节，空间效率时间效率严重拉跨，一度出现了代码空间不足、CCS无法编译、编译后无法运行等critical bug。
怀念起我熟悉的C/C++的好，我料定找一段C代码替换掉MATLAB built-in的polyfit()将带来解放，而且经过大神优化的C代码肯定控制在100行以内。皇天不负有心人，感谢CCTV感谢CSDN，闲话少说，代码奉上：
多项式拟合C代码
把里面一些data type、parameter name等做了适配性修改后，使用原场景原数据测试，跟MATLAB的polyfit()比较，精度上肉眼无差！再小用一下MATLAB内嵌C代码的技术，一次跑通，完全没有压力！
在这里我看到了混合编程之美，见识到了“互补”的妙处，回想当年在学校、在54所，做过VC/C++/C#调用MATLAB engine做混合编程的经历，计算、绘图方便了很多，但仅适用于事后处理，对实时性要求较高的场景不适用，毕竟MATLAB的运行耗时摆在那里，不generate code的话它本就只是为数据处理而生。
做自动驾驶、做ADAS，这种特别吃数据的活儿，MATLAB是个天生的好工具。在那里，MBD是新引入，大部分项目还是纯C的解决方案，这就有了路线之争，我们也曾有过争论。虽然没有人拍板下结论，但我认为本也不需要结论，因为没有绝对的优劣。C/C++赢在效率，但在图形化、可视化、数据处理与分析就相形见绌，而且编码量大；而反过来又恰恰成了MATLAB的特点，所以我认为，如果能把它俩做到扬长避短、优势互补、综合应用，就完美了。
可以这样，在资源足够的前提下，以MATLAB/Simulink为开发主体，重点借助其一目了然的逻辑展示能力，比如数学运算模块、逻辑运算模块、状态机、PID算法、输入输出排布…拿个别人做的model，很多东西真的是一看就懂，省去了写大量注释的功夫；然后吃效率的点用C/C++重点攻克，像上文说的polyfit()、像目标筛选、像不定长数据集，把各自的优势发挥到极致。
还有就是事后的数据处理与分析、数据回灌与仿真要倚重MATLAB/Simulink，首先来说MATLAB生来就是干这个的；再者，也有纯编程做的，我见过也用过，它的问题一方面编码量大，甚至需要招聘专门的开发人员，上升到系统工程了，再一方面是真不如MATLAB好用，比如画出个曲线来，Simulink的Data Inspector里可以随心所欲的缩放、度量，但自研的软件往往难以做到这个水平。让专业的人去做专业的事，让资源利用最大化。
当然了，这会要求开发人员掌握两项技能甚至综合技能，这可能是很多人不愿意的，搞技术的就这样，都觉得自己牛别人垃圾，再就是懒。不说技多不压身这种鬼话，但至少心态应该是开放的，而且要有追求，对于技术人来讲，这不应该成为问题。
到了大厂，凡事更正规，更追求规模效应，各种工具之间的协作司空见惯，这就更要求我们具备多样融通、一通百通的能力，要能够留出20%~30%的注意力在外围、在协作，可以预想的是，MBD && C/C++ && CarSim && PreScan && Git && Docs && etc.，在核心能力内外，一整套的东西等着去了解去学习去掌握，这，就叫工具链，叫流程。
还记得当年上个新项目，领导问我想怎么做，我说打算沿用原先的架构，领导说可以尝试用用python，领导一句话让我记忆深刻：年轻人不要限制自己。