从反馈bug到想造轮子
开发者的自己的项目中，是否应该在第三方类库的引用上保持最大程度的洁癖呢？
自从宇宙第一 Markdown编辑器Typora宣布收费后，我始终没有下定决心购买正式版，一是由于付费后获得的能力和解锁的功能并不是我必须的，二是因为我发现了不错的 vscode插件，基本可以胜任我写内容的场景，并且Markdown对我来说目前的作用就是写博客，而在vscode中事实上能够更加一体化地管理博客。
然而用了几个月我都没有发现这个插件居然不支持用于设置摘要的 <!-- more -->，发现时是因为看到首页中所有文章的摘要都失效了。
在文章中使用
<!-- more -->，那么<!-- more -->之前的文字将会被视为摘要。首页中将只出现这部分文字，同时这部分文字也会出现在正文之中。
因为我习惯于为文章添加一句引子，也就是正文的第一句，不支持摘要的结果是引擎会截取尽可能多的字数作为摘要，虽无伤大雅，但总归不爽。不过我发现作者更新频率还是很高的，于是便打算等几天，但并没有发现更新了对Hexo摘要的支持，看来我这个社恐只能发邮件向作者反馈一下了，可是得到的回复是：
插件的原理是解析 Markdown语法，因此一切非Markdown语法的内容都会被忽略。
很可惜，看来作者的开发思路跟Typora有所不同，但这也怪不得开发者，毕竟是用爱发电的作品，作者必然是以满足自己的使用需求为第一要义，除非给钱让开发者定制，不然也很难去提什么主观的要求。
虽然还在学习前端的我在开发vscode插件这方面没什么能力，但是此刻却萌生了想要开发一款Markdown编辑器的欲望。
不过很幸运，我发现了另一款插件，同样能够满足我写博客的需求，然而在更新了一个版本之后出现了一些主题适配的问题，并且同样没有发现修复更新，很无奈我再一次发邮件向开发者反馈，这一次的反馈很顺利，作者也是邮箱高强度在线，讲清楚问题后20分钟就修复了bug并推送新版。
很开心，但同时我也在思考，如果这位开发者没有排查出问题，甚至没有回复我，那么这些插件对我来说使用体验就会大打折扣了，所以我还是有想自己开发Markdown编辑器的欲望。
这就是程序员们常说的“造轮子”了，而且是重复造轮子，因为已经有了功能相似甚至相同的产品出现。造轮子的初衷实际上是源于自己对现有产品的不满足，比如功能无法完整覆盖自己的需求，比如已经失去维护很长时间，甚至是业界并没有符合自己设想的项目……但是我时常在想，当在自己的项目中引入了这些开源的库之后，如果这些库出现了问题，就像fastjson频繁曝出安全漏洞，此时该自己从头实现一套专属当前场景的工具库还是继续另寻其他开源库呢？
对我来说，我觉得自己是有一些代码洁癖的，对源码的好奇让我时常会思考某个功能在底层是如何实现的，有时还会尝试去实现标准库的某个函数，但是当我在前几个学期完成大作业的过程中，却对手写工具类有所排斥，果断地暂时将底层原理抛诸脑后，对现成的工具和类库，只要能实现需求，便只管拿来主义。事实上我是有些惭愧的，然而大作业是要实现需求的，需求只是一句话，是不会考虑业务逻辑的复杂度的，此时实现需求才是第一要义，调用的库存在什么关键细节并不需要考虑，因为类库就应该由它的开发者来维护。
不过我总觉得这看来像是自己的项目中有一些关键内容被别人握在手里，虽然开源协议可以保护自己的软件不会遭到类库开发者的“制裁”，但调用别人写的代码总是感到不够安心，如果是一些嵌入项目比较深的组件，原作者进行了改动后很可能自己要跟着修改很多逻辑，这种被动想必不会那么自在。
就我个人的感受来看，这是一种复杂的心理，当在完成一个任务的过程中，我通常是属于只看结果的那一类人，只要有可以实现需求的方案，那就可以拿来用，而不考虑是否有必要总结出一套代码库出来，在当下的网络世界，几乎所有在开发过程中遇到的问题都能够寻找到答案。
而当我在酝酿自己的项目时，往往想要追求每一行代码都来自于自己的双手在键盘上的敲击，不论业界是否存在一些成熟的解决方案。自己的项目，我就希望所有的东西都是我自己手搓出来的，当然，即便一时半会为了开发进度而需要引入一些现成的库，在未来我也愿意重新实现项目中调用的函数，当项目中所有的代码都是我自己的劳动成果，我才踏实地感到这是我自己的产品，我是有完整的决定权和发言权的。
所以我觉得对于个人项目而言，引用官方的开源库自然不会有太大问题，但是我觉得对于别人的开源项目的引用还是要保持一定的克制，毕竟不知道开发者会维护多久，这意味着很有可能在未来你依然需要基于人家的项目做维护，而理解别人的代码对任何人来说都绝非易事。事实上基于现有的开源库来开发应用就像拼图一样，或许拼图很简单，但一旦丢失了一块碎片，整张拼图将不能再复原，而从开发者的角度来说，如果你对技术有兴趣，那么设计一款属于自己的“拼图”一定会比单纯的“拼图”更有趣。