trash talk
In recent years, the front-end has developed very fast, and the prosperity of SPA has made the front-end engineering more and more important. In many scenarios, the complexity and difficulty of the front end has already surpassed that of the back end. But with the rapid development, the front-end has gradually exposed many problems. As we all know, front-end practitioners rarely talk about program design principles or design ideas. The design pattern is at most the same question-and-answer "Observer Pattern" and "Publish Subscriber Pattern" in the eight-part interview. Words like "cohesion" and "decoupling" rarely pop out of the front end. This inevitably leads to the front-end code being written into a mountain of shit. And this is still based on the MVVM-like framework development model. The front-end code naturally has component-level abstraction. If it is the MVC era of slash and burn, it is even more unimaginable.
A front-end project in charge of a colleague frequently broke out bugs, and it has reached the level of repairing 1 bug to generate 3 bugs, and even many bugs cannot be located. I asked my colleagues why, and the answer is that the project is more complicated. I humbly think that the complexity of the project is not a reason to write a mountain of shit (to give an extreme example, your project will not exceed the Chrome browser no matter how difficult or complex it is, if the Chrome browser project can be maintained very decently, less difficult projects You must also find good technical solutions and architectures to deal with.). Out of curiosity, I browsed the code of this project and found that this is a typical front-end big shit mountain. There should be no one else who can or is willing to take over the project except the author himself, and the fate of the future can only be to hire a new person to refactor from 0, and even a line of code cannot be referenced (I have experienced this!).
Purely from the point of view of writing software, in fact, there are many mature code specifications that can be referenced, and even the specification to variable naming and so on. But here we will only discuss the pile-up skills in the front-end field.
Essence Tutorial
- reject Ts
Resolutely do not use Ts, and even refactor the projects written by Ts into Js code. Last year, I was airborne as a leader (it was Ali P7 many years ago). After taking a look at the rich text editor project I maintain, I was told that the project needs to be refactored, and the refactoring goal is to drop Ts and rewrite it in Js. After struggling for days, I made a difficult decision. . .
- reject hooks
All components use Class components, reject function components, and reject hooks.
- Full embrace of state managers
All state is managed through state managers like Redux or Mobx.
- No module abstraction and reuse
每个功能都从0开始实现，不抽象任何公共组件，不把高频出现的逻辑抽象成hooks，不抽象出工具函数，坚决不复用任何逻辑。
- 把JSX结构掰开揉碎
直接在JSX上写长函数和复杂参数，至少需要达到一眼看上去稀碎，完全无法在脑中构建出页面的样子。
- 编写长长长长长的组件
一整个页面只编写1个组件去维护，单个组件代码行数轻松写到1000行以上。
- 父子组件多传参，尽可能多层传递
父组件给子组件传非常多参数，然后子组件继续又将这些参数层层往下传递。
- 单文件开发
将状态、数据、类型、工具函数、网络请求和组件等等全部放入一个文件中。
- 打破文件组织结构与组件结构关系
虽然组件天然是一个多叉树结构，但相应的文件全部平铺到1层。
- 不封装网络请求函数
每次请求都创建新的Axios实例，网络请求错误不统一拦截，全部单独catch。
- 样式混用和强行覆盖
内联样式与css文件样式混用和覆盖。类名随便起，不要透露结构信息，相同的css代码在各个类上直接复制黏贴一份。遇到冲突的样式强行再覆盖一层。
- 到处修改UI组件库内部样式
为了达到设计要求，通过导出类名强行覆盖UI组件库的内部css样式，多用!important魔法。
- 多用Js代替CSS实现效果
伪类伪元素等坚决不用，动画过渡等效果也必须通过Js实现。
- 到处使用微前端
尽可能的把页面拆成一个个单一功能的微前端应用。
- 不要argue需求
对于产品或设计给到的需求全盘接受，尽力实现交互复杂混乱繁冗的功能，获得技术成就感，做一只不挑食的小白兔。
收益
- 每天都看起来非常忙，大家排队求你分一点时间处理各种技术问题，都哭着叫你大佬，饱受尊敬。
- 每次上线产品、测试、后端都围着你加油，生怕测试通过上线之后仍旧出现各种奇奇怪怪的生产事故。
- 同事认为你技术很牛逼，解决了诸多神奇bug，老板夸你勤奋不摸鱼下班晚，周报总是满满当当。
- 公司地位无可撼动，除了你这个项目没人有能力或愿意接住，只能给你加钱，生怕你离职。
xdm，还有什么堆屎效果奇佳的好手段？可以留言补充啊！