Development Insights

本人从事自动驾驶行业，主要承担运动控制框架的开发，期间积累了一些开发经验。

原本我是不太愿意把这些东西落成文字的，因为此前我认为这些东西可以记在心里并不断内化形成一种类似于肌肉记忆的东西。不过随着我开发的框架体系越来越复杂，具体的工作越来越多，我会不断学习新的知识，接触新的技术栈，也会觉得心力不够用，或许是时候把一些东西落成文字了。

即使是落成文字的东西，也不要当作类似“公理”的东西去对待，因为开发经验只是基于过往的总结，每次进行新的开发工作是都应当实事求是。（当我想要记录经验时，第一个想到的就是不能被经验束缚）

实事求是

这对于我来说是“价值观”层面的东西。人是很主观且情绪化的动物，一个模块的表现不及预期甚至相反时，承认自己对理论理解不够透彻，应用存在缺陷并不是一件容易的事（有的时候还会受限于工作场景不适合直接给出“不好”的答案）。所谓实事求是就是直面事情本质，探索问题根源，而不是只对问题表象做一些修修补补的工作。

是否要使用最优秀的技术栈

要！有更优秀的凭什么不用？ 但这并不容易。

我是一个想要追求完美的人，即使是模块中最小的组成单元，我也希望使用最优雅的技术去实现，使其在兼容性、功能、性能综合达到最优。一般来说，我会去调研各种可用的技术栈或实现方法（有了AI之后调研工作变得更加高效），这之后还要去做一些不同方法的尝试和对比，总之要消耗不少时间。然而这还不是真正让我头疼的，最麻烦的是在面临一些复杂问题时，可能找不到一个能让我满意的方案。比如说我为了一个配置文件系统纠结了很久，一方面我希望能够尽量使用现成的库或框架来大幅降低开发时间，一方面我又希望这个配置文件系统能够同时满足开发人员和用户的需求，能够本地修改也能够远程分发，还要有动态调参的能力，同时还要配备GUI系统，事实上至今我也没找到一个让我真正满意的方案，总会面临功能性、易用性、开发时间上的取舍。

完美总是存在限制条件或是仅在特定情境下存在的，不存在真正意义上的完美，我们始终追求我们的问题边界内的最优解，但即使是有前提条件的最优解，也够让人纠结的了。

• 最优解付出的代价相对次优解付出的代价大太多怎么办？
• 考虑寻求最优解本身的时间成本呢？

总之呢，或许我们在寻求某个具体问题的最优解，但我们需要解决的不是一个问题，我们如果考虑整个系统的最优性，同时我们自身付出的代价也应当是代价的一部分，甚至于我们可以考虑解决这个问题对于我们的职业生涯的意义。

所以说是否要使用最优秀的技术栈？要！如果这个问题对你来说并不困难的话。但如果这个问题需要纠结很久的话，不妨考虑一下整体，选择系统内的核心部分有的放矢，非核心部分退而求其次或许效果更好呢？

以及，上面提到的优秀以及完美都只不过是我们的主观定义，是我们认知内的优秀和完美，不断的探索和学习，才能让我们不断接近客观的优秀和完美。