Java高级编程-React 项目的架构和规范

  1. 云栖社区>
  2. 博客>
  3. 正文

Java高级编程-React 项目的架构和规范

欧阳愠斐 2018-07-05 18:09:58 浏览1026
展开阅读全文

 

 

架构和规范

架构是为了解决什么问题呢?我理解是效率问题。通过一个好的架构,能让你很容易地、具备一致性地理解一个系统,在此基础上快速地、可持续地完成业务功能。它保证的有三点:

  • 代码库阅读起来很轻松
  • 添加新功能时能很快,理想情况是,仅添加跟业务有关的代码,跟样式、基础设施相关的东西,在一个较为成熟的项目上,应该都比较稳定了
  • 在演进过程中,仍然能保持添加功能的速度很快

规范是为了解决什么问题呢?我理解是协作问题。大家一个团队工作,命名习惯不同,代码风格不同,水平参差不同,如何保证整体质量和风格面貌?靠规范呗。

那么架构和规范分别有什么例子呢?

架构

比如目录结构、组件层次、状态管理、副作用管理、路由系统、UX 系统(样式方案)、埋点设计、测试策略、持续集成、构建方式、部署方式等属此列。可以看到,为了开发一个业务功能,底下可能需要这么多基础设施支撑。而架构的目的,就是把尽可能的操作(比如路由、埋点、UX 一致性等)变成常量级别的操作、甚至默认标配的操作,这样才能让你开发起来顺畅,做到只关心业务的部分。

  • 目录结构:这个问题与组件层次问题息息相关。在 APP 的场景下,它与 web 又不太一样,APP 往往是首页路由+卡片式堆叠页面。怎么将页面结构映射到目录结构上,怎么保持清晰?是遵循 duck 目录结构设计方式,还是功能式目录结构方式?如果小型项目选择从功能式开始,后续是否有向 duck 结构的迁移路径?需要多少人力?
  • 组件层次:是按照 container component -> presentation component 的结构划分?还是不 care?
  • 状态管理:React Context、mobx、redux,如何选择?
  • 副作用管理:promise 方案?thunk 方案?saga 方案?
  • 类型系统:TS。语言层级的类型系统所带来的架构抽象能力
  • 路由系统:怎么做到让页面增删变成常量级别的操作?怎么支持多种不同的渲染模式(不卸载/卸载)?
  • UX 系统:怎么做到跟 UX 设计保持高度一致?怎么保证只需要常数级别的操作就可以达到这种一致性?如何保证只需要常数级别的操作就可以变更、尝试新的 UX 设计?
  • 埋点设计:数据乃产品之本,怎么设计埋点系统,让它对业务代码的侵入性达到最小?怎么保持细粒度埋点的灵活性?如何做到让埋点变成常量级别的操作?埋点数据结构如何设计?统计如何统计?要生成什么报表?报表的生成如何做到常量级别的操作(即不需要人工执行脚本去统计)?
  • 测试策略:测哪些?测什么?测多细?由谁测?需要制定可落地的测试策略
  • 持续集成:开发方式(分支 or 主干)?自动化测试分别在什么阶段运行?如何让持续集成的配置变成常数级别(而不需要每次换机器都要手动重新搭 CI)?
  • 构建方式:用什么工具进行自动化构建?
  • 持续部署:部署目的地?部署频率?是否能做到每次提交都进行部署?是否能准备与生产环境尽可能接近的 UAT 环境?

规范

比如代码风格、编程风格、命名风格、提交信息、提交粒度、开发习惯、代码整洁程度、单元测试好坏等属此列。

  • 代码风格:Prettier 一键解决
  • 编程风格:Eslint 尽量覆盖
  • 命名风格:明确基本原则后,写入 README 做宪法 + 术语表
  • 提交信息:precommit hook,但没法规范到信息级别,而提交信息是跟提交粒度息息相关的
  • 提交粒度:较难以统一的部分。我还是把它放到架构部分去吧
  • 开发习惯:自暴自弃的部分。比如 TDD 等
  • 代码整洁程度:基本只能用 code review + PR 来规范。这跟开发者是谋生心态还是工匠心态有关,跟组织是技术属性的组织还是政治属性的组织也有关系
  • 单元测试好坏:明确好测试的标准后,制定测试策略 + 写入 README 做宪法 + code review 经常反馈

其他的欢迎补充。

 

如果对小编所发感兴趣,欢迎关注小编,小编持续更新。

 

架构和规范

架构是为了解决什么问题呢?我理解是效率问题。通过一个好的架构,能让你很容易地、具备一致性地理解一个系统,在此基础上快速地、可持续地完成业务功能。它保证的有三点:

  • 代码库阅读起来很轻松
  • 添加新功能时能很快,理想情况是,仅添加跟业务有关的代码,跟样式、基础设施相关的东西,在一个较为成熟的项目上,应该都比较稳定了
  • 在演进过程中,仍然能保持添加功能的速度很快

规范是为了解决什么问题呢?我理解是协作问题。大家一个团队工作,命名习惯不同,代码风格不同,水平参差不同,如何保证整体质量和风格面貌?靠规范呗。

那么架构和规范分别有什么例子呢?

架构

比如目录结构、组件层次、状态管理、副作用管理、路由系统、UX 系统(样式方案)、埋点设计、测试策略、持续集成、构建方式、部署方式等属此列。可以看到,为了开发一个业务功能,底下可能需要这么多基础设施支撑。而架构的目的,就是把尽可能的操作(比如路由、埋点、UX 一致性等)变成常量级别的操作、甚至默认标配的操作,这样才能让你开发起来顺畅,做到只关心业务的部分。

  • 目录结构:这个问题与组件层次问题息息相关。在 APP 的场景下,它与 web 又不太一样,APP 往往是首页路由+卡片式堆叠页面。怎么将页面结构映射到目录结构上,怎么保持清晰?是遵循 duck 目录结构设计方式,还是功能式目录结构方式?如果小型项目选择从功能式开始,后续是否有向 duck 结构的迁移路径?需要多少人力?
  • 组件层次:是按照 container component -> presentation component 的结构划分?还是不 care?
  • 状态管理:React Context、mobx、redux,如何选择?
  • 副作用管理:promise 方案?thunk 方案?saga 方案?
  • 类型系统:TS。语言层级的类型系统所带来的架构抽象能力
  • 路由系统:怎么做到让页面增删变成常量级别的操作?怎么支持多种不同的渲染模式(不卸载/卸载)?
  • UX 系统:怎么做到跟 UX 设计保持高度一致?怎么保证只需要常数级别的操作就可以达到这种一致性?如何保证只需要常数级别的操作就可以变更、尝试新的 UX 设计?
  • 埋点设计:数据乃产品之本,怎么设计埋点系统,让它对业务代码的侵入性达到最小?怎么保持细粒度埋点的灵活性?如何做到让埋点变成常量级别的操作?埋点数据结构如何设计?统计如何统计?要生成什么报表?报表的生成如何做到常量级别的操作(即不需要人工执行脚本去统计)?
  • 测试策略:测哪些?测什么?测多细?由谁测?需要制定可落地的测试策略
  • 持续集成:开发方式(分支 or 主干)?自动化测试分别在什么阶段运行?如何让持续集成的配置变成常数级别(而不需要每次换机器都要手动重新搭 CI)?
  • 构建方式:用什么工具进行自动化构建?
  • 持续部署:部署目的地?部署频率?是否能做到每次提交都进行部署?是否能准备与生产环境尽可能接近的 UAT 环境?

规范

比如代码风格、编程风格、命名风格、提交信息、提交粒度、开发习惯、代码整洁程度、单元测试好坏等属此列。

  • 代码风格:Prettier 一键解决
  • 编程风格:Eslint 尽量覆盖
  • 命名风格:明确基本原则后,写入 README 做宪法 + 术语表
  • 提交信息:precommit hook,但没法规范到信息级别,而提交信息是跟提交粒度息息相关的
  • 提交粒度:较难以统一的部分。我还是把它放到架构部分去吧
  • 开发习惯:自暴自弃的部分。比如 TDD 等
  • 代码整洁程度:基本只能用 code review + PR 来规范。这跟开发者是谋生心态还是工匠心态有关,跟组织是技术属性的组织还是政治属性的组织也有关系
  • 单元测试好坏:明确好测试的标准后,制定测试策略 + 写入 README 做宪法 + code review 经常反馈

其他的欢迎补充。

欢迎工作一到五年的Java工程师朋友们加入Java架构开发:468947140

点击链接加入群聊【Java-BATJ企业级资深架构】:https://jq.qq.com/?_wv=1027&k=5zMN6JB

本群提供免费的学习指导 架构资料 以及免费的解答

不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导

 

如果对小编所发感兴趣,欢迎关注小编,小编持续更新。

网友评论

登录后评论
0/500
评论
欧阳愠斐
+ 关注