先前的经历就不讲了，从开始涉及到前端leader开始讲起哈
转眼间已经单独在公司负责前端工作两年时间，在一家培训学校，有5个校区，负责学校的辅助运转项目落地，面向客户端项目落地等。
由于公司之前没有纯前端开发，即还没有前后端分离，我进入该公司之后，公司的技术开始了前后端分离，那么，所有的前端工作，现在公司就只有我一个前端负责了，一个人应对了太多的技术挑战，
- 比如从0到1,从未接触过音视频方面开发开始，帮公司完成了在线课堂，直播，录播教育的开发；完成了小程序的开发；
微信公众号h5的开发，to Customer,or to business; - 帮公司完成了在线课堂办公系统开发，可供学生，老师，教务人员使用，同时该系统适配pc、ipad、移动端，
涉及到了比较多的适配逻辑，多重逻辑的融合，系统可根据设备在无地址更换情况下切换项目场景。 - 帮公司开发了面向学生，家长，上课，教务相关的小程序开发，二开了ui组件等 以上是我值得说的一家公司经历，说这些，只是为了讲明白，我后面为什么做那些前端leader,甚至更高到前端架构的事情，以及我为什么会有后面经历的原因，因为以上的实际境况，一个人不得不考虑到很多问题、事情、业务代码范式、组件公用性、架构、适配逻辑、部署等问题
又转眼间，我已经在另外一家公司担任前端Leader工作已经有两年的光阴，真的，在一家公司待的时间，和技术成长是有一定的关系的，当你觉得没有什么长进，没有什么可以学习的时候，又坚持了一段时间后，会发现又有不一样的成长，这个成长是提升一个台阶的成长，是频繁跳槽获取不到的成长；这里记录一下我在这两年担任该职位时候的日常工作内容，这段时间抽空慢慢写，不急着一下写完哈。
2023-10-11
在我做前端leader两年期间，在刚进公司的时候，由于之前在一家公司单独负责前端工作的经历，在看了当前公司的基本项目代码之后，我感觉，这些项目代码，整体上是保留有一定的公司整体技术风向的。 逐渐的，在我接手了一个紧急的项目之后，发现公司处理整体层面的技术风向之后，技术执行细节上，代码复用性太低了，代码阅读性、直观性有点差了，代码的组件化有点缺乏大局观了，大多是低逻辑的组件，组件命名可读性有点差了，项目整体的技术可控性有点差了，都是开发人员自我发挥的，比较零散的，全局主题风格的样式需要一一去改动，去调节才能能保持一致；业务常用代码的封装有点少了，大都是把业务逻辑直接暴露到了项目主页面内容上面；主要项目与子项目，页面与子页面等的架构关系没有形成系统化、体系化、组件化、工程化、没有清晰的架构逻辑，没有清晰的全局架构思想。
思想，在基础代码编程知识掌握之后，项目的架构思想，组件封装思想，业务demo抽离思想，全局掌控的思想变成了一个程序开发人员主要掌握的事情，是要具备的能力。
组件的封装，需要看场景需要，它是一个常规的放之四海而皆准的组件还是只适用于当前自定义场景的组件，由此决定组件封装的思想高度，从而决定了组件封装时候各种参数的详细高度； 比如汽车有 轮子，方向盘，车架，这是一个抽象的思想；如果你理解为汽车的轮子、汽车的方向盘、汽车的车身，那就成了一个狭义的思想。组件封装的广度，宏观程度大体由此类似的思想形成了。除了思想，我们应明确的知道，组件的基本属性应该有，入参、响应、出参等基本要素，这些参数是泛型还是具体的定义，以及组件的使用初衷，决定的组件的宏观程度，使用场景。另外有时候，我们的组件，业务逻辑代码是相同的，我们只需要修改布局，我们要习惯于对业务代码和样式代码进行分离，代码逻辑分离，只用修改ui布局即可。
另外，代码通用的基本思想：抽离、封装、继承、多态，要使用贯穿到我们技术开发，技术架构的始终的。
我在该公司这些分析判断之后，开始了我的工作：
1 全局公用的，常用的业务组件进行封装，比如管理系统常用的 table组件，搜索条组件，form表单组件，弹窗组件，tab组件，日历组件，图标组件，文件上传、下载，对这些组件进行了 基于公司ui选型的截流，二次封装，并提供使用说明文档，并提供了相对应的使用代码范式， 因为ui组件的广度是比较大的，我们单纯使用它，每次都要花时间去看文档，了解它的各种属性，这对于开发人员是比较费时间的，我把上述组件二次封装成了符合本公司常用场景的业务组件，开发人员可以适当按照组件demo就能快速开发业务，不需要再去关注过多的配置，属性等。另外这些组件的封装，保证了项目的工程化实施，通过组件的控制，就可以把控项目全局的css样式、主题风格、业务demo范式
2 对全局公用的基础样式、布局样式、自定义样式简称、色彩主题变量进行了全局抽离提取，控制了项目整体风格和样式的统一性、专业性
3 对项目全局的 接口请求代码进行了逻辑和参数抽离，开发人员只用配置接口名字、接口路径、即可快速的注册接口、完成接口对接；同时接口的对接业务逻辑，进行了代码demo范式提供，让开发人员都能按照统一的代码编码范式去开发，省的每个人写不同的逻辑代码，提高了执行效率，降低了零散性。要对参数和业务代码、逻辑代码进行抽离，当然这些抽离的代码要作为一个可靠的范式，让大家方便使用，即便升级也要考虑不影响开发人员使用，它是开发环节的相对于开发人员的一个交付产品。
4 对项目 基于代码开发整体上的各种工具代码进行抽离封装，比如：form表单校验、正则公式、上传、下载、空值处理、url地址处理，多环境识别等全局的公用数据、配置数据等，当然做以上所有的事情，都要有一个综合考量，考虑它的多项目复用，迁移等，所以我们的抽离，全局处理，并不是越多越好，有时候要方便代码迁移、代码复用等，不然的话，我们的迁移将会解决一大堆的文件，数据依赖等问题，过犹不及。
5 开发各种有利于项目逻辑，降低工作繁杂的工具，脚本等。开发一键多项目打包脚本，shell脚本，git常规代码提交脚本，文件复制脚本，目录生成管理脚本，代码模板脚本
6 对项目代码的目录结构进行调整，归类，整理，对于业务开发人员，只需要关注各自对应的业务开发就好，至于项目的整体架构、逻辑，我会对他们进行醒目的使用目录进行隔离，对业务开发页面也会使用目录进行归类隔离，这样，项目代码、文件结构就更清晰了，虽然都是前端开发，不同的角色负责的任务不同，专事专做，提高了项目代码的统一性，工程性，专业性。项目的整体的架构逻辑，贯穿到项目的始终的，也是另一种编程哦，编程的逻辑层级不同而已，要考虑适配、兼容、系统安全、交互体验、页面样式、公用组件产品化、性能、代码执行时序、这些不是能用就行的，我习惯性的想要找到最正确的解决思路，以及脚手架的二次封装整理等。这些都是编程哦，不是说写业务代码才叫开发。 （在我做前端leader的两年，技术经理是后端，技术主管是后端，在这样的公司，也只能适应环境。。但是当技术主管说：前端搭一个项目要不了两天时间，快的一天就够了呀，你怎么感觉进度有点慢了；我又不想反驳，但我也不会认可，以上的工作内容，实际摆在这里的，前端架构，前端leader工作一点不比后端轻松。工作量和复杂度都有的。我的开发，搭建都要全盘考虑的，复用考虑的，向最佳解决思路靠近的，同时要保证降低开发人员的难度，提高他们业务开发效率）
7 我会习惯性的把业务和数据进行分离，数据和视图进行分离，组件和数据进行分离，最终只需要注入配置数据，接口字段，接口数据即可，环节节点，环节执行，只是已经封装抽离好的逻辑代码而已。数据在流畅的调用，注入，输出。比如我已经把项目的接口请求部分进一步抽离，需要对接口的时候，直接把接口路径，接口名字，一字符串的形式拼接，形成基础数据数组即可。
1
2
3
4
5
6
7
8
9
10
const baseApi = [
'apiName:apiPath:apiconfig',
'apiName:apiPath:apiconfig',
'apiName:apiPath:apiconfig',
// ...
]
const genApi = (baseArr)=>{
// return xxxx
}
比如我已经把菜单部分进行数据抽离为：
1
2
3
4
5
6
7
8
9
10
11
12
const baseMenuData = [
'path-label',
{
sub:'path-label',
children:[
'path-label'
]
}
]
const genMenuData = (baseMenuData)=>{
// return xxx
}
除了以上的举例，还有常用的key-val 指标性数据、图表组件以及数据，表单数据，等地方，这样做的目的是减少开发人员业务开发的关注点，提高代码的可维护可读性，同时提高效率，因为我不用二次再关注逻辑了，只需要把对应数据添加进基础数据结构中即可。
8 作为前端leader,除了以上工作，还有一个不能忽视的就是管理工作了，对于以上我对于项目做的整理和努力，要安利给组员使用的，目的就是提高开发效率，提高产出，降低繁杂的体力劳动，同时要对他们的代码进行 code review,因为他们有了问题解决不掉，还是要扔给我处理的，所以尽可能让他们保持良好的统一的编码习惯，降低不必要的消耗。同时，这是一个好的编码思想，他们应该也或多或少有点不一样的收获。
前面说的都是项目具体实时细节的整体把控，我看当前公司的大多项目架构还行，但是细节实时欠佳，所以我做了以上的那些工作，为我在该公司的工作，管理提高效率。只有架构，没有细节逻辑，这个项目是不充实的，在进行了上面的工作之后，我又开始了 公司常用项目架构方面的工作：
这一部分，在上一部分不经意间已经讲了一部分了。架构方面的工作，要看项目的性质的，难易程度也不尽相同，反正，如果公司项目需要往正规化、专业化发展，要做大做强的话，大概率是需要单独负责架构工作的人员的。不可能把业务开发工作和架构工作总是揉在一起。
作为前端leader，我还要对开发成员进行尽可能合乎公司规则的绩效评定，个人觉得和对人员的面试逻辑类似的，这个是综合的考指标考量一起得出结果的，不单单是技术好，不单单是人缘好，不单单是上班不迟到等单方面决定的，而是要尽可能符合考核标准，尽可能有利于技术团队的发展、和谐、稳定最终做出的评定。
用一段时间，抽空看完一部分知识点，还是有收获的，我们需要耐心，这个从长远来说，不算慢的。😀,