最近几年前端发展的非常快，SPA的繁荣让前端的工程化也越来越重。在很多场景下，前端的复杂度和难度也早已经超过了后端。但快速的发展下，前端也逐渐暴露出了许多问题。众所周知，前端从业人员很少谈程序的设计原则或设计思想。设计模式也顶多是在八股面试时千篇一律的问答“观察者模式”和“发布订阅者模式”。“内聚”和“解耦”这样的词语也很少从前端嘴里蹦出。这就难免导致前端代码写成一座大屎山。而这还是在基于类MVVM框架开发模式的前提下，前端代码天然具有了组件级别的抽象，如果是刀耕火种的MVC时代，更是难以想象。
同事负责的一个前端项目频频爆出bug，已经到了修1个bug产生3个bug的程度，甚至很多bug无法定位。问了同事原因，回答项目比较复杂。窃以为项目复杂不是写成屎山的理由（举一个极端的例子，你的项目再难再复杂也不会超过Chrome浏览器，那如果Chrome浏览器项目可以被维护的非常得体，难度更低的项目一定也能找到好的技术方案和架构来应对。）。出于好奇大致浏览了这个项目的代码，发现这就是一座典型的前端大屎山。除了作者本人应该没有任何人可以或愿意接住该项目，未来的命运就只能是招个新人从0开始重构，甚至一行代码都没法参考（我经历过这事！）。
纯粹从编写软件的角度，其实目前有很多成熟的代码规范可以参考，甚至规范到变量命名等等。但这里我们暂且只讨论前端这个领域的屎山堆积技巧。
精华教程
- 拒绝Ts
坚决不用Ts，甚至将Ts写的项目重构成Js代码。去年我被空降了一个leader（多年前就是阿里P7级别）。在看了一眼我维护的富文本编辑器项目之后，告诉我需要重构该项目，重构目标是抛弃Ts，用Js重写。我在纠结了好几天之后，做出了一个艰难的决定。。。
- 拒绝hooks
所有组件都用Class组件，拒绝函数组件，拒绝hooks。
- 全面拥抱状态管理器
所有状态都通过类似Redux或Mobx等状态管理器去管理。
- 不做模块抽象和复用
每个功能都从0开始实现，不抽象任何公共组件，不把高频出现的逻辑抽象成hooks，不抽象出工具函数，坚决不复用任何逻辑。
- 把JSX结构掰开揉碎
直接在JSX上写长函数和复杂参数，至少需要达到一眼看上去稀碎，完全无法在脑中构建出页面的样子。
- 编写长长长长长的组件
一整个页面只编写1个组件去维护，单个组件代码行数轻松写到1000行以上。
- 父子组件多传参，尽可能多层传递
父组件给子组件传非常多参数，然后子组件继续又将这些参数层层往下传递。
- 单文件开发
将状态、数据、类型、工具函数、网络请求和组件等等全部放入一个文件中。
- 打破文件组织结构与组件结构关系
虽然组件天然是一个多叉树结构，但相应的文件全部平铺到1层。
- 不封装网络请求函数
每次请求都创建新的Axios实例，网络请求错误不统一拦截，全部单独catch。
- 样式混用和强行覆盖
内联样式与css文件样式混用和覆盖。类名随便起，不要透露结构信息，相同的css代码在各个类上直接复制黏贴一份。遇到冲突的样式强行再覆盖一层。
- 到处修改UI组件库内部样式
为了达到设计要求，通过导出类名强行覆盖UI组件库的内部css样式，多用!important魔法。
- 多用Js代替CSS实现效果
伪类伪元素等坚决不用，动画过渡等效果也必须通过Js实现。
- 到处使用微前端
尽可能的把页面拆成一个个单一功能的微前端应用。
- 不要argue需求
对于产品或设计给到的需求全盘接受，尽力实现交互复杂混乱繁冗的功能，获得技术成就感，做一只不挑食的小白兔。
标签：一座,项目,样式,前端,Js,组件,写成,代码 来源： https://www.cnblogs.com/sunlin49/p/16260982.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。