今年听到一句话感觉比较有意思，大致意思是“知识管理有时候就是增援未来的自己”。
这让我想起来电影《终结者》中，长大后的小男孩派出了机器人去保护小时候的自己。
不二过
今天为什么要写这篇文章呢？实际上，比较早就有这个打算，但是属于没到痛处就没动手，现在写实际上已经是有点晚了。不过好在亡羊补牢，犹未晚矣。
在前端开发中，不少工作就是根据设计图开发各种页面，而页面上的元素也就常见的几十种，但是由于各种实际情况比较复杂，或者考虑不周全，导致工期延长或者bug较多。
有些问题会重复遇到，如果不总结的话，会出现，这个问题我清楚地遇到过，但是怎么解决的，我是不清楚了。
久而久之，越发觉得，有必要整理一些内容出来。一方面总结回顾，一方面增援未来。
举个例子
日期组件在开发中非常常见，日期格式，日期、时间的选择，是否禁选、选一段时间等等。
有些功能比较常见，有些比较少见，如果不做处理，有时候会出现，今天搜索过了，后来再次遇到后还需要再次搜索的问题。
如果直接将面临的问题解决方案及时收藏，那么下次就可以直接从自己的知识库里面精准搜索了。
有人可能会说，可以用ChatGPT呀，但是如果每次都问，也是需要花费时间和金钱的。实际上，各有各的好处。AI 可以用来提供解决方法，链接可以用来收藏。
如上图所示，
第一行是组件名，一般较为通用。
星级代表在实际开发中出现的频率或者重要程度。
官方链接，代表常用组件库的官方地址，这样可以一键直达。
交互清单，则为平常遇到的一些关键点
相关链接，是一些常见问题的解决方案，有些不一定遇到，但是可以备用。为什么要记录一些自己未曾遇到过的情况呢，一来，现在没遇到不代表将来不会遇到，有网友遇到过，那么我们也有一定的概率会遇到。二来，可以大致心里有个数，将来遇到了也有印象。
图之于未萌，虑之于未有——《旧唐书》
这样做的好处
技术方面的知识回顾和梳理
一方面，检验已有的组件熟悉度，另外，可以系统回顾下常见组件都有哪些地方是需要注意的，假如将来需要写组件库可以考虑得更加全面些。
另外，有时候开需求评审会议，如果设计或者交互有问题可以提前暴露出来。毕竟对于处于链路下游的前端来说，这种事情还是比较常见的。有一句话说得很好，你跟产品讨论了一下午，产品的需求有了，你的开发时间没了。如果能够提前识别风险，那么就不会耽误工时，少加点班。毕竟身体是自己的。
方便后期的开发和自测
写好后，实际的开发过程中，可以自己写一写比较完善的公共函数，有些问题就只需要解决一次，后面再也不用担心了。 另外也可以自己用来自测，有时候可以规避一些风险，比如后端传过来的数据是否符合要求。
提高团队内部一致性
有了最佳实践后，就可以不用在这些事情上面多次争论了，确保团队成员遵循相同的标准。后面新人入职或者新项目开发，也可以萧规曹随。
提高工作效率和减少bug
经历过上面的流程，基本上提测后就很难遇到一些常见的 bug 了。工作效率的提升是必然的，这样就不会把所有的时间都花在日常开发中。
另外，假如有的公司绩效跟 bug 挂钩的话，就可以避免在这一块影响绩效。也可以减少一些沟通时间。
提高知识管理能力
首先，反复遇到的问题需要整理成文档，如果工作经验大于5年的话，是要有一些积累和输出的。以我有限的经验，如果不呢？后面还会再来几次，然后又会后悔之前为什么没有整理。既然现实情况如此，为什么不一开始（n>=3）就借机整理呢？
只有总结经验，才能不会在同一个地方反复摔倒。
其次，知识结果要形成文档，不可全依赖记忆力，年轻时候还好，随着年纪变大，或者遇到的事情比较繁杂琐碎，很难面面俱到。
另外，形成的文档等资料，还可以在求职面试的过程中起到一定作用。
也可以发布到个人博客，这样博客也有了内容。
平常整理的内容，就像是自己的武器库、脚手架。别人还在钻木取火的时候，你已经开始在架好炉子烧火做饭了。
经过日积月累，效果还是很明显的。
last but not least，当然还有另外几个用处，不过这里先卖个关子，日后揭晓。
