代码敲得多了，静下心来，喝杯茶，想想之前走过的路，遇到的坑，总结一下，继续往前走。
这个契机是最近开发的一个项目，从零开始的，是一个业务逻辑很复杂，业务量很大的一个项目，随着项目进度的进行，也有了第一版、第二版…
直到现在开发第三版，又多了许多新的功能，我才发现我还不是一个成熟的工程师，简单的说，就是代码编写能力不错，解决问题的能力也不错，差就差在眼光太窄，没有站在更高的层面思考问题，缺乏更高级的抽象能力，再就是基于此导致的效率低下。
第一个问题：对业务需求的不了解。
之前我是这样的：产品告诉我需要实现什么功能，UI告诉我设计图是什么，后端告诉我接口是什么、测试告诉我测什么，我一切都写好了，完美符合他们提的要求，但是后面产品告诉你什么什么地方需要做优化…这样导致的后果就是需要花时间去完成这些优化，哪怕很简单，可是，如果在当初写代码的时候就考虑到这些可能要优化的点不是更好吗？
第二个问题：设计代码的能力
我认为这和组件化、封装可以放到一起说。
之前的我觉得这不算什么，甚至组件化复用性这些老生常谈的东西一无是处，我照样一天写好几个页面不香吗？事实证明，太年轻！举个我自己遇见的例子，项目中有5个页面的样式包括逻辑大差不离，增删改查这些，有一天需求来了，说是修改每个页面的新增输入框的校验，然后我只能一个页面一个页面去添加校验规则，假如当初我就把这个新增功能封装成一个公共组件呢？明明可以改一次的，偏偏要改那么次，浪费时间精力。
事实上，这些能力不是突然就养成的，是一个慢慢成长的过程。其实我明明已经封装了很多的公共组件，明明写了很多全局样式表，但是，have a way to go.
我想真正的设计代码的能力应该是这样的：
在项目开始的时候，就定义大部分的全局样式，将想都不用想的一些公共组件如表格、分页、输入搜索框等全部写入全局组件，还包括哪些数据是公共数据放到vuex里面，哪些需要放到本地做持久化存储，哪些请求要用action dispatch发起…总而言之，你应该有一个大局观，一个页面应该有哪些部分组成，有哪些事件这些都是可以预见的，要早早做好准备
第三个问题：站在更高的维度去解决一类问题
基于我之前来说，假设要做一个PC端后台类项目，我可能直接拿vue-admin这种半成品项目做二次开发，其实拿到手还是要做一些修改的，比如说公共样式得重写吧，比方说接口得做封装。我想说的是，我们何不自己搭建一个架子，甚至我们自己搭建架子之后，哪怕来了一个应届生新手都能基于咱们搭建的架子去做开发。
我说的这个架子，比方说我们开发一个新的项目，这个项目是后台管理类的，我们把这个项目的全局样式写好、HTTP请求接口封装好、将这个项目里面常用的功能片或者逻辑片抽离出来变成全局组件或是全局方法，还有根据我们对业务的理解将可能用到的第三方插件拿过来调试到可以使用的地步封装起来组件化，完成这些之后，再写一个页面，哪怕是新手都可以照着我们写好的一个页面去复制去粘贴也能把这个项目写出来。
我想：这就是技术壁垒吧！没有实际的工作经验作为积累，是不可能有这种思想的。
第四个问题：技术瓶颈
请问：除了常见的crud（增删改查），前端还有什么技术比较高深比较难的点？
这个问题一度困扰着我很久，直到现在，我也不敢说都了解清楚。
之前的我觉得，除了crud，还有了解vue、react底层源码、长列表优化、柯里化、性能、安全、兼容这些…
但其实没那么简单。
是一直被我忽视的webpack等模块化工具以及javascript还有就是HTTP
webpack等模块化打包工具的底层实现是接下来我主攻方向
JavaScript指的是精通，何谓精通？能把lodash.js里面的方法自己写出来就算精通
HTTP，了解他的原理之后，关于前后端交互这块再无任何后顾之忧
小结：
本文写于2022年5月27日，记录的前端开发的一些心得体会，有许多想说却想不起来或者写不出来的点，相信以后的我更加牛批，前来填坑，那么，未来在会！
