Web前端发展至今已经变得十分的繁杂，做Web前端的业务开发有两三年了，是可以谈一谈自己的一些理解了。

如何理解业务开发？

通常我们需要解决是极其实在的问题，比如构建一个表单、列表、交互操作等等，我们工作通常是使用各种的框架、三方库等来构建产品的“脸面”，直接面对使用者。因此，需要我们去实现的需求、功能通常非常的多变的。所谓的需求、功能，我这里简化为解决问题，任何需求、功能都是解决问题一种描述表象。

这种多变确实会给我们开发者弄得焦头烂额，因为通常做技术的都喜欢不变，变就变得非常。这里的变与不变是一种辩证的看法，是比较狭义的，所谓的不变就是比如一直开发一个框架、数据库等等这种专业度高的技术，因为选择少所以可以不断精进，通常这类技术是比较固定的，不变就不变在所要解决的问题是固定的。而对应的业务问题，通常是面对的是人，往往多变的多，我理解的多变其实是我们很多时候很难去准确把握业务表象问题之下的真正问题，所以通常产品会不断的猜测用户的意图，或者通过观察用户的数据来反馈做出行动。这就像是机器学习的训练一样，反馈更改、反馈更改，循环往复，有的时候确实会让人麻木。
在变中寻找不变，去找到这些核心问题，然后去解决这些问题。（通常只有少数人能够在纷繁复杂的表面问题直击其下的核心问题，这个是毕生的追求了）
这里说的有点唯心主义了，不过越来越发现很多道理问题都是相同，本文主要从当业务问题转换为需求问题，然后又转换为技术问题后，这些前端技术问题如何更好的解决。

我现有的理解是，要把业务开发做好，需要从下面几个方面入手
1.规范
2.抽象

规范

所谓的规范就像是统一度量单位一样，是为了解决协作问题。
通常有一些一系列的规范需要考虑

  • 代码规范
    • 代码的格式，比如，缩进是多少、每行最大的字符数等等。（可以使用Prettier）
    • 代码使用规范，比如，不能使用某种语法等（tslint，eslint）
    • 注释的规范，提高可读性（只能靠自觉）
  • 编辑器设置规范
  • 开发部署规范

规范的利是可以解决多人间的协作问题，提高可维护性，不至于写的各种代码让人从形式上就看不懂，解决的外在形式的问题。在社区中，我们可以找到各种工具来帮助我们解决这个问题。

抽象

所有的问题的汇集，我觉得首先要试着做抽象，我们做技术的一定要学会抽象，这是毕生的。
需求问题，比如界面上加个什么按钮、做个交互、做个表单、控制、动画等等比较具体的东西。通常，我们会比较简单的一一的实现，不会想太对，就是完成了工作。这个其实就是没有思考的技术应用，通常这个价值是仅限在所做产品本身，并且有可能在未来带入许多的维护、扩展等问题。
抽象是找出解决核心问题、共同问题，从而可以复用。表象的问题通常是不断变得，而其核心通常是变化很小的，比如Linux，其内核被很好的抽象，几乎不需要变动，但是我们可以在外延做很多的自定义，从而有各种版本的Linux，甚至是Android。通常抽象的越好其复用的能力越大。
对于Web前端，通常复用会从这几个角度入手

  • 通用库，比如，状态管理、网络请求等等
  • 组件库
    • 基本组件库，比较细粒度的组件（按钮、输入框等等），这种组件比较通用。
      • 主题单一，一般符合整个业务群的使用
      • 主题定制，可以做到比较好的定制化，适用更广
    • 业务组件，通常在某个子业务中有效
      • 特定业务的组件
      • 基于基础组件库的封装
    • 项目组件，通常在单个项目中的多处可以使用

工程化

所谓工程化就是把前端的一系列的编译、部署、测试等等各种工作，都采用自动化的方式集成起来，其目的是提高开发的效率、代码的质量，让开发可以专注于业务开发，而各种重复的事情都交给机器来做。

  • CI：通过持续集成，把编译、部署、自动化测试都一条龙起来，只要提交代码，按几个按钮就全部搞定。
  • 本地开发：
    • 数据mock
    • 本地测试
    • git提交检测（代码规范等）
    • 代码美化

耐心、细致、不断学习

写代码的过程，如同其他的职业一样，需要耐心，需要细致，才能写出较好的代码。天才是少数的，即使是天才也是不断学习，不断实践的。记得在电视剧 Legal High中，有一集是讲一个漫画大师，说道：削铅笔、画画，钝了，继续削铅笔、画画，循环往复，突然有一天发现所有的人都在山底，说着这个人是天才。