文章目录
前言
经过职业道路上的开发实践，并结合后续的深入思考，我沉淀出了一些个人的心得体会。这些体会涵盖了多个维度，包括但不限于前端工程搭建与开发、项目流程、工作总结等方面。
虽然这些记录可能并不完全客观，也不一定能全面代表整个行业的情况，但我相信一定有前端开发人员能够感同身受。
未来，我会不定期地继续补充和完善这些内容。
前端工程规划的思考
在做工程开发的时候，需要提前或者在开发过程中做好项目调整和规划。规划的目的是为了能让工程健康的长久开发与维护，也能让后续参与进来的开发者能够快速的上手整个工程。
架构的选择和搭建，技术栈、通用方案的预研
最开始的时候，肯定要根据公司资源，要做的业务类型，选择一个合适的框架，然后进行库的技术栈预研。
通用方案也要提前预研下，例如你这次做的是后台管理，那么你是要选择二次开发框架呢（vben、ruiyi之类的），还是自己去实现权限管理、登录登出、页面缓存等等场景。如果是后者你要怎么选实现方案？
还有一个容易忽视的CSS编码方案，这个绝对要考虑下，可以看看我这篇文章【工程化】千万不要忽视css编写方案的定制！选择好的编写方案越写越爽！！！
制定代码规范，文件结构与git提交的规范
紧接着制定代码规范，文件结构与git提交的规范。可以参考或直接使用行业内比较成熟的规范。
eslint的制定，可以参考这俩篇文章：
- 【工程化】记录在vue工程中eslint、prettier等formatter以及git提交等规范的知识点
- 【工程化】记录在react工程中eslint、prettier等formatter以及git提交等规范的知识点
规范文档
对于规范文档，我之前公司的文档个人感觉写的太多了，反而会让开发者有抵触情绪，因为有心智负担。我的建议是，eslint和prettier能帮我们自动处理的就不要写上去了，能够大大减少文档内容。然后文档上就写上一些eslint和prettier处理不了的，还有一些文件结构、变量命名规范等等之类的即可。整个文档整下来就非常简洁好读了。
规则复用
当项目数量很多的时候，并且你的自定义eslint规则挺多的情况下，就要考虑每个项目的eslint规则的复用方案了。
我看到掘金有个用npm去解决的：因为我经常配置重复的 eslint，我被孤立了
他那种如果有更新，每个项目都需要重新把这个npm包更新下。我个人觉得eslint规则，初期定下来后期应该就不会怎么改动了，用他这个方案也行。不过我觉得简单的eslint文件和pritter文件直接复制粘贴也挺好，因为每个工程的eslint文件和pritter文件后面基本上是不动的。
制定一个代码审核流程
一般要么阶段性代码提交的审核，或者需求结尾性的code review。可别小看code review了，我看很多没啥前端建设的公司都不重视前端的code review。
我来告诉你有什么好处：
- 项目成员帮忙找bug（业务上或者功能上），减少生产事故（出现生产事故了处理时可是挤占了你下次迭代的开发时间）
- 成员熟悉对方的代码，纠正不符合规范的地方，让项目不那么容易失控
- 大家可以相互学习，别小看这点咯，如果你的组员都是大佬的话，是真的可以学到很多东西的
制定分支管理规则
git分支管理搞起来，多人开发分支怎么制定？不同环境分支怎么规划？成员各自的权限怎么分配？这都是要考虑的
联调前期没接口怎么办
联调时间其实非常的紧张，因为前端不仅要把返回的数据正确使用到前端上，接着帮后端找接口bug，还要把整个页面功能流程串起来疯狂调试，最后要走冒烟测试。
然而在联调时前期甚至开发末期，基本上接口还是没部署的，为了不浪费宝贵的周期，这个时候就需要前端自己模拟接口了。
可以看看我这篇文章：【工程化】前端开发阶段没有接口，如何模拟后端接口请求
除了接口模拟问题，还有几个问题是前端要实时注意的：
- 如果觉得后端某个接口返参不合理，或者说设计不合理（类似获取某个东西要先调这然后再调那），一定要找后端商量，争取修改的机会
- 前端代码要考虑接口返回参数的非正常情况的应对
组件怎么设计
内容放下一个大标题里了。
业务/功能代码注意事项
- 时刻考虑代码的性能优化与可维护性、拓展性。
- 代码的趋向高级语法、简洁但不过分简洁（要能很清晰的看出业务逻辑）、逻辑条理化、语义化，加注释说明；
- 不同大小屏幕，缩放比例的适配问题（【场景方案】前端的噩梦，给老旧的显示设备做页面兼容，你做过多少？一起来补充呗）
- 管理工具类文件和字典；
- 性能的优化（可以参考：【工程化】收集平时积累的一些性能优化措施，并且分享我是怎么去回答面试官的）
- 时刻考虑边界问题/容错问题
等等，其实这些做的好，我认为你已经是个非常合格的前端工程师了。
以上的这些最好有一个类似前端组长的职位人员，去统筹全局，严格把控整个工程。
对于前端单元测试的理解
我看到现在搭建框架的时候，都会默认问你需要jest单元测试包吗，这个东西包括可视化测试库storybook，我个人认为是那种开发组件库的开发团队使用比较合适。
为啥呢？
- 平时开发时间紧，你还要花时间去给每个组件写单元测试例子，当你需求大的时候组件会被拆分很多，将耗费你大量精力
- 需求经常变动，可能你当时写的测试例子一下子就都废了，又要重写
个人认为，还不如多理解业务自己细心的多走几遍流程，前端人多的话还可以组织code review，还可能更适用些。
当你负责一个前端项目时，初期要考虑哪些
基本上就是结合上面说的：
- 项目业务分析，先了解要做的是什么东西，然后进行架构的选择和搭建，技术栈、通用方案的预研
- 制定规范：文件规范，代码规范，git规范等。
- 文档的制定，项目总说明文档，业务组件库文档等。
- 制定一个代码审核流程、定制分支管理规则。
- 联调前期方案的确认。
- 是否要加入单元测试。
- 提前与设计沟通统一全局UI设计稿（不要忽视哦）
- CI/CD流程（这个暂时没接触过）
- webpack优化等
为什么要有UI统一全局的设计稿
- 很多时候在开发阶段，只有原型稿，UI设计稿还没出来，这时候如果原型上有的组件在全局的设计稿里有一样的，前端就可以直接画出，节省后续的工作量
- 前端可以根据全局的设计稿封装对应的公共组件和样式选择器，提高开发效率
- 方便新加入的开发快速了解UI的设计
对组件开发的思考
主动开发组件的好处太多了，减少调试时间、提高开发效率、提高运行稳定性等，下面就说我认为的开发组件要注意的几个地方。
如何去设计组件
从几个方面去想：
样式
- 针对组件内部的样式，写的时候尽量写优先级低的选择器，这样外部组件可以直接覆盖修改特定的样式。
- 组件内部也可以对外提供一些特定的样式，方便外部直接用插槽时能够通过添加class类名来修改样式（这样的话使用说明需要写详细些）。
- 也可以通过传值的方式添加class类名或者style类名，例如antd的组件xxxStyle属性或者xxxClassName属性。
模板
- 一些固定必有的界面可以写死，例如一个表单组件的标题。一些需要父组件去自定义的，可以采用插槽的方式插入，并且组件内部提供默认的插槽。
- 稍微复杂一点的可以使用具名插槽的方式。
对外暴露的方法
- 建议组件中的每一个动作都对外暴露一个方法，最好的话一个动作可以分为前、中、后分别三个周期暴露出去。
- 暴露出去的方法尽量给的参数多一些。
- 还可以写一些让父组件能直接调用的方法，给父组件一些主动权。
配置项
- 动态的数据都由父组件传入
- 尽量用一个大对象的形式作为配置项传入，不要写一堆的props不好维护
- 这个配置项有可能在很多地方使用的都是一样的，可以专门写常量去维护，例如jsx里可以以
{...INPUT_CONFIG}的形式引入，然后要修改里面某个配置，在后面写覆盖即可
解耦
封装的组件之间虽然有相互引用，但尽量解耦，能够单独成一个独立的组件。
例如页码组件、搜索栏组件、表格组件，这三者怎么做解耦，可以通过url的参数做数据的联系与接口请求的驱动。好比搜索栏组件点击搜索后，把参数更新到url上，表格组件监听到url的参数发生变化自动去调接口。页码组件触发了页码相关动作也把参数更新到url上让表格组件监听。
学会举一反三~
组件之间怎么结合
我们知道我们的页面是一个个组件拼接成组件树形成的，那么每个组件之间的关系要怎么设计呢？如何做解耦，如何灵活的联动，如何做复用关系。这是前端的一个很大的挑战，也能反映前端的一些设计功底。
我抛砖引玉下，可以参考我这篇关于表单组件的使用思考：【场景方案】分享平时做表单页面时，积累的一些心得体会
多积累公共组件库
对于需要使用的第三方UI库，最好能在公司内部对每个控件进行二次封装，积累成一个公共组件库。比如element-ui的公司组件库、ant-design的公司组件库。
可以玩玩高阶的业务组件
业务组件按我自己的理解是：多个功能组件根据业务需求组合成的复合组件。
个人之前有在开发业务组件，还是有不少真实的心得：
- 第一，业务组件中实现配置项与接口结合形成的低代码效果需要业务场景完全固定才能稳定维护与拓展。
- 第二，业务组件不能在完成第一个版本后就上到整个工程去使用，后续你会发现各种问题和场景调整，最好是开发完后先上实际场景试用，然后后续不断进行版本迭代优化；
- 第三，最好固定场景的业务对应相同的业务组件，不要想着一个业务组件适配所有业务场景，因为只要一个稍微的定制化需求，就会需要改变业务组件中的逻辑代码，还可能影响到正在使用它的其他地方；
- 第四，业务组件解耦第三方技术栈真的太难了，只能做到尽量解耦，越想解耦中间的解耦代码就会越来越庞大；建议配置项尽量不破坏第三方库的原生api。
- 第五，前期需求不稳定，还是尽量不要封业务组件，往就往组件化上靠就行。或者干脆不要业务组件也行。
写完组件后的注意事项
我认为，一个开发团队想做到持续健康的开发，在做完组件开发后，需要写组件的说明文档，方便快速上手及查阅也能避免后加入的人对功能的重复开发（这点很多公司都做不到）；
对业务的理解，对整体团队进度的了解
如果一个开发人员对业务不够理解，那么他们编写的代码很可能会存在许多bug。因此，开发人员需要主动去深入理解业务，同时公司也应尽可能为开发人员提供系统了解业务的途径。
对于专注于前端开发的工程师来说，理解业务确实是一项挑战。在需求评审阶段，前端工程师应该特别注意，积极提问、提出意见和建议。
使用思维导图可以帮助记录和理解复杂的业务逻辑。
除了前端开发工作和业务理解之外，前端工程师还应该努力培养全局视角，了解当前推进的项目状况和每个团队成员的分工。这样，当领导询问项目细节时，才能做到心中有数，而不是一问三不知。
需求评审的注意事项
以下的一切前提是：公司的需求开发只是追求在项目排期内业务落地。而不是像苹果公司那样追求极致的打磨。
技术与实现
需求评审的过程就是一个需求想象到落地之间的博弈，实现想要的技术要考虑成本和资源。
例如团队的时间成本，排期是否充足。人员配置够吗，技术水平够吗，前期预研工作难度如何。
所以并不是说产品需要什么技术就一定要实现什么，如果太难，或者改动太大有风险，是否可以妥协技术寻求相同结果的方案，让业务落地。
所以，很多时候不是产品说什么就给他实现什么，对于不合理的需求要敢于说No！并且给出你的理由！
在网上看到一句话：需求指导设计，设计指导开发。我个人觉得最重要的是需求和设计之间的博弈。
需求是否合理
了解需求背景，为什么要做这个需求，要能说服技术人员。
质疑需求的合理性，如果出现不合理需求等到时候上线反馈不好下架版本了，整体团队的相当于没有产出，每个人绩效就会大打折扣。
需求是否闭环，意思就是每个需求他的最终目的是否存在，例如博客浏览量的需求，这个浏览量不能只是一个普通的显示，而需要用起来，用在哪里，是否能做为一个浏览量的排序等。
是否需要其他部门的协助
是否需要其他职位的支持？
例如文件下载功能的技术选择是否需要后端支持、此次需求需要依赖其他部门的平台吗等等
否则在开发阶段才意识到再提出，别人没有排期去协助，那么就是自己的问题了。
要求产品经理把场景考虑周全，同时自己也要多多考虑
对于专注于前端开发的工程师来说，他们的主要精力通常集中在两个方面：一是跟上快速变化的前端技术，二是关注用户交互的实现以及bug的修复。相比于以业务逻辑为核心的后端工程师或者负责提出需求的产品经理，前端工程师对业务的理解和敏感性可能不如他们深入。
在这种情况下，评审阶段就显得尤为重要。前端工程师需要仔细审视产品经理提出的方案，检查是否存在遗漏的场景、交互设计，以及是否有细节考虑不周的地方。一旦发现这些问题，应立即提出讨论，以便更准确地评估自己的工作量和项目进度，从而进行有效的排期。
如果省略了这个步骤，开发过程中甚至到了测试阶段或测试结束时，可能会突然涌现出一系列新的需求或改动点，这往往会导致项目延期。
因此，产品经理也需要提升自己的专业水平，确保在项目前期就考虑到所有相关因素，并将这些细节详尽地记录在需求开发文档中。同时，前端工程师也应尽力审查产品方案，确保没有遗漏任何场景、交互或细节。通过这样的协作，可以最大限度地减少项目风险，确保项目按时交付。
之前遇到过个最强产品经理，在需求开发文档中能把所有场景都给前端罗列出来，好怀念哈哈。
排期评估
在完成需求理解后的排期评估中，应当避免过于乐观的态度。现实情况往往比预期的更为复杂，因此在安排项目进度时，应预留出更多的时间以应对可能出现的各种情况：
- 开发阶段可能会遇到的会议和讨论，这些活动会占用开发时间。
- 需求可能发生的突发性变化，例如之前提到的因需求考虑不周全而导致的问题。
- 是否需要其他部门的协助，协作过程往往比预期耗费更多时间。
- 技术实现的难易程度，这可能会影响开发进度。
通过为这些潜在的时间消耗做好准备，可以更有效地管理项目风险，确保项目能够按时完成。
技术评审注意事项
- 追求性价比最高，最简单，最稳定的实现方式。不要过渡最求新技术，高技术。
- 最好记录在文档里，方便以后查看（这个到没经历过，具体没啥概念）
- 找出开发难点和重点
- 前端组内评审
等等
联调阶段
在开发完成后，后端应认真进行接口测试，避免在联调阶段让前端承担80%的问题排查工作（这个没夸张，亲身经历），这会压缩前端在接口对接后的场景测试时间。这是一个常见的工作问题，网络上经常有人提及。
在完成某个部分的联调后，后端也应该主动去点点看，帮助前端排查问题同时也是检查自己接口是否有问题，礼尚往来。
在联调过程中，前端不应完全信赖后端返回的字段，而应采取多种预防措施。这样，即使生产环境中后端字段出现问题，由于我们提前做好了预防，页面也不至于出现严重故障。
至于联调前期没有接口的问题，可以参考我的这篇文章：【工程化】前端开发阶段没有接口，如何模拟后端接口请求
还有一篇详细说明的文章可供参考：【场景方案】与后端接口斗智斗勇的这几年，我帮前端小伙伴们提供了一些策略，也给后端大佬提点建议
关于降低生产bug出现的频率
- 页面业务的理解是一切的基石
- 开发人员要有一定的自测能力
- 对于即时修改的地方一定要及时同步给测试人员并且跟进
- 产品临时加改东西要有自己的考虑，是否改了会带来新的风险
主动培养“链路”上的思考与总结能力
这个“链路”解释起来有点抽象，它可以是某件事、某个流程或者某个问题从起始到终点的过程（这是以前腾讯面试的时候，技术大佬给我提出的词）。
这个过程可以分为好几个阶段、每个阶段涉及到不同的人和事。
在每个阶段中，可以站在一个全局的角度去分析、去思考、去总结。
你会有意想不到的收获与成长。
适当参与github的开源项目
可以从小项目开始，选择自己感兴趣的领域进行实践。但我认为，如果公司有开源项目，例如公司的UI组件库对外开放，那么参与这样的项目将是一个极佳的提升机会。
适当参与GitHub上的开源项目不仅能自我提升，而且还能成为你在人才市场上与他人竞争时的优势。
至少半年要更新一次前端知识
前端领域的知识更新速度确实非常快，我建议至少每半年主动更新一次前端知识库。
推荐半年为周期的原因是基于我过去两年的个人经验。
如果你和我一样，平时有很多其他工作需要处理，没有足够的时间持续关注知识更新，可以尝试我的做法：在日常工作任务不太繁重的时候，早上先浏览一些技术博客，对新出现的技术或工具有一个大致的了解。然后，在半年周期结束时，根据自己的判断，筛选出那些你认为当前必须学习的知识，并集中时间进行深入学习和跟进。
这种方法可以帮助你在忙碌的工作中平衡知识的更新和学习，确保你的技术栈保持现代化，同时也不会过度分散日常工作的注意力。
敢于使用AI产品提升我们的工作效率
善于利用人工智能工具，如GPT，确实可以显著提升工作开发效率。我个人已经非常依赖这样的工具，如果没有它们，我的工作效率会明显下降。
然而，这种依赖也是一把双刃剑。虽然AI工具能够提高工作效率并减轻心智负担，但过度依赖也可能导致自己感觉没有真正掌握知识。我的建议是，每次AI提供答案后，我们都应该自己思考一下，努力吸收并理解其中的原理和逻辑，以确保我们不仅得到了答案，还获得了知识和技能的提升。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
