首先，不可否认的是这个世界上有许许多多优秀的人、与众不同的机制、出类拔萃的软件工具；尤其是，当我们的目光集中在开源世界，show me your code，能够合法地、极客地去了解所有这些 Fancy 事物背后的设计艺术、运行机制。

  这个过程，就好像去参加展览，欣赏不同风格、不同手法的艺术画作；又好像是工程师去五金店，在各种各样的工具之间挑挑捡捡。这个过程就是 Tooling。我还没能在中文语境中找到一个很好的词来概括这个过程，准备？打磨？都不是一个好的翻译。

  这里有一段关于 tooling 有趣的论述。 From chmanie.com

Tooling is hard.

It always was. All these things that you spend so.much.time. on even without having written a single piece of code towards your actual goal. But I like tooling. The power, the convenience of automation it provides once it’s set up properly can make many tasks quite joyful. Coming from the JavaScript TypeScript world, I’ve been quite spoiled with helpful tools lately.

There’s the TypeScript language server, providing you with fantastic insights about your code and tools to refactor it. Then there’s eslint which, leveraging its great community has evolved into the de-facto standard of JavaScript code-style-checkers (if I can even call it that still). Honestly, when I start writing a new programming language, I check what kind of tools are out there to make my life easier in that realm. I felt I learned a lot from the seemingly arbitrary error messages that these tools provided, making my code style prettier and my implementations much more resilient.

Also, I love (neo)vim. Yes, you can (and have to!) spend a huge amount of time to bend it to your liking. But I feel like once you and vim got acquainted and to like each other, it’s a bond for life. I won’t write more about my relationship with vim. As you’re reading this I assume you have made up your mind already.

So when I started getting into C(++) development on microcontrollers, I naturally asked myself: “What’s out there?”. The answer lead me down a dark and extensive rabbit-hole of joy and frustration. Quite a couple of times I just felt so tempted to “just use VSCode” as many people suggested. But I don’t want to. As of this writing I’m still using vim, hoping to continue this endeavor. In the following text I’m aiming to share my findings with you, not aiming for completeness or trying to cover all the use-cases. I’ll try to keep it as general as possible though.

  Tooling，对于任何系统的工程，都是一个必不可少的重要过程，工作流和工作机制的设计好坏和整个工程的效率直接相关。但是我现在想说的不是 Tooling 是怎么影响系统和具体工作的——我现在的经验也不足以支撑起自己的观点，而是想说警惕“虚”的、空洞的 tooling，把精力拉回到工作本身之中。
Stop Tooling and Do Coding !

  这个想法来自对最近一段时间在各种工具上折腾的反省，从一点上我也看到了自身完美主义的缺点。反省下来，一个阶段性的观点是： Tooling 是很重要的，但是这个过程不应该由他人经验驱动、和具体相关的工作分离，而是随着工作的进展，根据具体的需求进行迭代更新。例如，完全照抄其他人的 dotfiles，并不能很好地提高自己的效率，因为学习和适应其他人的使用习惯也是需要很高的成本的。一种个人认为好的做法是：参考其他人的实现，根据自己的需要选择其中部分，毕竟使用习惯也是一种因人而异的东西；这也算是一个求同存异、取其精华的过程。

  马克思的观点，事物的发展都是螺旋上升式的。批判性的 tooling，也就是一个和完美主义矫情斗争的过程。 在对瑕疵的妥协和克服的交替过程中，实际的工作和自身的能力都得到了提升。

  值得一提的是，对瑕疵和问题的妥协，不是一种舍弃，反而是一种更高层的思考，我们需要去客观实证或者直观感知，对这些表象瑕疵妥协的背后是对哪种问题特质的透视。正如 No Free Lunch Theorem 表述的那样，一种称为“有所进展的”工作总是带有偏向性，这种工作的好坏只不过取决于我们认识和掌握这些偏向性的程度。

  或者说，真正的完美，不是也不可能是无懈可击、无可挑剔的，而是局限的、可控的、边界明显的。完美的关键不在于事物能做什么，而在于事物不能做什么。