开发一个UI框架项目[0]-想法

本文最后更新于:2020年10月25日 晚上

写在前面

近段时间一直有搞个开源项目的想法,思来想去,加上近段时间的一些事情和个人在开发中遇到的一些情况,最终决定写一个UI框架轮子,具体的原因跟分析见下面。

造轮子的初衷

  1. 总结、有目标性地提升自己。这是最根本的原因。大多数前端工程师平时基本都是在写业务代码,这本身没有问题,但是如果我们只是在持续性地写业务,没有给每个阶段的业务、项目还有技术做总结,那我们就是在不断地重复同一件事且没有提升,这种情况就是内卷化。所以我们可以歇息,但是不能停止进步和提升,这是最根本和最核心的问题。

  2. 纸上得来终觉浅,绝知此事要躬行。现在的前端技术日新月异,我们需要学习很多知识,很多人也懂很多理论知识,然后我们会发现在和别人聊天的时候可以侃侃而谈,但在具体实践的时候经常手忙脚乱出问题,这是为什么?我觉得最重要的原因之一就是缺乏实践,将理论付诸行动。基础知识很重要,是我们的“内功”,内功扎实了我们才能更稳定地提升,但同时也只有把掌握的知识发挥出来,知识才算有用武之地,不然我们就是在“纸上谈兵”。造轮子其实是一个很好的实践过程,精进技术的同时还可以锻炼我们的思维和业务能力。从0到1的过程,我们存在的很多问题会在实践中不断暴露出来,那我们要做的就是发现问题->解决问题->总结->发现问题->解决问题。。。如此坚持与循环,那我们肯定会得到很多收获,虽然这个过程确实非常耗费时间和精力。

  3. “拿来主义”下的居安思危。现阶段开源氛围很浓厚,大多数的团队也愿意将他们成熟的解决方案放到github之类的托管网站,在业务和时间排期的影响下,很多人会觉得造轮子是一件费力不讨好的事情,网上资源那么丰富,开源的项目那么多,直接拿来用就好,为啥还要自己造呢?先不说好不好用,光是业务不等人就是个问题。这种想法一般情况下是对的,但考虑以下几种情况:

    1. 定制化的需求。总会有一些定制化的需求是第三方无法满足的,或是公司内部特定业务,或是某些惊为天人的创新想法,第三方不是万能,总有需要自己创造的东西;
    2. 迭代稳定性。我们永远无法保证我们使用的第三方库能一直维护更新,第三方库也不会给予我们这样的保证。比如现在vue比较热门的组件库element-ui,目前已经停止维护,还有mint-ui。热门的框架尚且如此,那么其它的呢?时代一直在前进,我们的产品也终将是要跟随时代的脚步,如果我们依赖的第三方停止迭代了,我们是否变得很被动,也要跟着止步不前?如果每次都要更换第三方,迁移成本是否很昂贵?
    3. 服务稳定性。如果第三方库出于某些因素考虑,强制单方面不再对我们提供服务。这个可能概率比较小,但是也是很现实的问题。就像去年以来,美帝不分青红皂白对华为还有其它中国企业强制采取某些制裁手段,这种情况如果没有备用方案,应急方案,是不是很被动?所谓君子不立危墙之下,平时做到居安思危才不会在出现意外情况的时候被一举击溃。

实践想法

  1. 从0到1。项目会采用软件工程的理论以及当前环境项目的发布,过程大概包含立项需求收集和分析可行性分析功能设计原型设计交互设计功能开发测试功能预演发布,部分步骤会直接采用业界已有的成熟方案,虽然是造轮子,但也不是全部都是从0开始,我们不能这么傻ヽ( ̄▽ ̄)ノ。

  2. 同步记录。由于做的是vue的ui库,所以打算使用对vue非常友好的vuepress来记录整个过程,同时由于vuepress强大的功能,还可以用来展示开发的功能示例,这简直不能太棒ヾ(゚∀゚ゞ)!

  3. 同时部署在github和gitee。本来打算后面项目部署在github这个全球最大同性交友社区的,但是种种原因限制,访问慢,有时还会被限制,特别是这段时间,因为运营商dns污染,github.io也访问不了,需要修改dns或者自己部署其它域名,确实有点坑,所以还是那句话,要居安思危,因此会多部署在gitee

  4. 发布到npm。项目开发过程中会逐步更新并发布到npm上面。虽然该项目用在生产环境的概率比较小,但是趁机体会发布流程也是ok的。

总结

从该想法萌生之后,自己也查阅很多资料做了大致了解,做一个ui库项目会耗费比较多的时间,特别是从0到1,而且后面大概率也不会直接用于生产环境。但是经历过这样的过程,我相信从思维层面来看,我会不再局限于用技术的角度去看问题,从技术的层面来看,这个过程将会让我对所用技术栈有更深刻的理解。如果有一天需要我去创造的时候,这种经历所收获的经验会发挥很大的作用。最后,这项目是第一个但不会是最后一个,我会在空闲的时间,不断去提升自己,总结自己,将理论付诸于行动(≖ᴗ≖)✧。