什么是更好的解决方案

最近总有一些问题困扰着我，而这些问题又是那么的相似。所以我决定要在这里把它记录下来，顺便再把自己的想法清清楚楚的表达出来。

这个问题源自于一次和同事的闲聊。他以前所在的组是做一个基础的通用组件，这个组件维护起来甚是心累。不仅要修以前的bug，还要为使用方增加新功能。我当时一听，就忍不住和他吹嘘了一下vs code的做法。vs code做法的核心思想就是：纵使是再完备的IDE也难以覆盖每一个开发者的需求，因此它选择把皮球踢给开发者自己，让他们自己实现自己想要的功能：搞插件商店，完善插件生态，优化开发插件的体验、降低门槛。这种就是我想要说的，一种彻底解决问题的解决方案。

与之类似的，我还想到了WSL的例子。最开始微软通过在windows nt内核上完全实现一遍linux system api的方式来实现linux子系统。结果就是那边linux每增加一个特性/功能这边WSL都要去用windows nt适配一下，工作量可想而知。于是乎，像这种问题[点击这里]从2015年一直拖到了现在...这次WSL2就学乖了，换了一种方式：用虚拟机跑linux，以此来替换掉原来的WSL。想必他们的开发终于可以为不用修bug而松一口气了 :-P

这次写这篇博客，还有一个原因就是，我发现身边也有一些这样的例子。比如说，我们有一个检查配置表的程序使用vc++ 2008编译的，而我们服务器的代码是g++ 4.8.4并且支持c++11标准。最致命的是，这两个项目是公用代码的，通过不同的编译方式来做到在windows上运行这个程序。于是乎，在写检查配置表相关代码时，我需要：

（1）小心翼翼的编写兼容vc2008的代码，不能引人c++11相关的代码；

（2）小心翼翼的维护引入的头文件、需要链接的库文件；

上述第(2)点尤其难受。一般情况下引入一个新的头文件还需要考虑是不是在头文件里是否还简洁的隐含了其它头文件，因此头文件搜索目录的复杂度是不可控制的。引入新的头文件带来的修改是没有边界的。

可以看到，上面就是一个典型的反例。每当有代码修改时都需要去“照顾”一下这个检查配置表的程序。这个程序的维护完全就是补丁式，哪次改了不兼容就打打补丁修改一下编译参数。

相比而言，我觉得一种比较好的做法应该是，在linux上把这块代码编译成一个库文件。在编译服务器和配置表检查程序时引入这个库文件，来做到代码级别上的复用（类似于pythoncore工程和python命令行工程那样） 。为了跑在windows上可以使用虚拟机运行，win10系统可以用WSL，win7就装一个别的：P

想起同事说的一句话：有问题就改，有bug就修。没做过、没试过、没见过这种不应该成为我们不追求更好更优的借口。