前言

假设接到一个新项目，首先考虑以下几点

  • 使用何种类库，如何考虑技术选型？分别从哪几个维度去考虑？
  • 项目目录如何组织(按角色还是按功能)
  • dev和prod不同环境如何配置
  • 团队内部其他系统都用了什么
  • 多人合作开发，团队环境和代码规范问题如何解决?是否需要统一编辑器
  • 是否需要出文档，教其他团队成员配置环境、安装依赖等
  • 如果每个项目皆是如此，请考虑效率？(脚手架、cli)
  • 如何稳定高效的推动项目，请考虑成本收益比，并考虑项目所需的人力、物力的各项支持

技术框架选型

考虑以下几个问题：

  • 框架自身成熟度？
  • 框架生态圈
  • 框架主要解决什么问题？
  • 团队：学习成本
  • 项目周期：
  • 项目维护成本

结论：最终决定在中小型项目中使用Vue，而大中型项目中使用React，而对于金融科技公司而言，中台复杂项目较多，从而选定以React为主，当项目周期短且交付压力大时仍采用使用Vue的策略。

项目目录

按角色

  1. reducers/   #包含所有Redux 的reducer;
  2.     todoReducer.js
  3. actions/    #包含所有action 构造函数；
  4.     todoActions.js
  5. components/ #包含所有的傻瓜组件；
  6.     todoList.js
  7. containers/ #包含所有的容器组件。
  8.     todoListContainer.js

“按照角色组织”的方式非常不利于应用的扩展。当你需要对一个功能进行修改，虽然这个功能只是针对某一个具体的应用模块，但是却牵扯到多个角色，而不得不在多个目录间跳转。

按功能

  1. todoList/
  2.     actions.js  #定义action 类型；
  3.     actionTypes.js  #定义action 构造函数，决定了这个功能模块可以接受的动作；
  4.     index.js    #导出该组件需要导出的所有内容，每个文件夹下都包含一个index文件也有利于直接引用文件夹名称就可以导出模块
  5.     reducer.jS  #定义这个功能模块如何对应actions.js 中定义的动作；
  6.     views/  #包含这个功能模块中所有的React 组件
  7.         component.js    #傻瓜组件
  8.         container.js    #容器组件
  9. filter/
  10.     actions.js
  11.     actionTypes.js
  12.     index.js
  13.     reducer.js
  14.     views/
  15.     component.js
  16.     container.js

每个功能模块对应一个目录，每个目录下包含同样名字的角色文件。当需要修改某个功能模块的代码时，只要关注对应的目录即可，所有需要修改的代码文件都能在当前目录下找到。

脚手架

为什么不用create-react-app

  • 不满足当前团队的需求

  • 不可以定制化，需要二次修改配置

  • 没有开发组件的能力

结论：为什么不自己开发一个cli工具呢？？

yeoman

  • npm install yo -g

  • 把全局环境node_modules包下面的模板工程 copy 到你的当前项目路径文件夹下