本次Beta冲刺是Pulse news stream项目从原型走向可测试版本的关键阶段，核心目标是完成核心功能的开发与集成，修复前期原型阶段遗留的问题，优化用户体验，为后续正式版本发布奠定基础。本文将详细阐述团队在本次冲刺中的任务拆分、时间排期、分工协作、工具准备及代码规范相关内容。

一、项目冲刺核心规划

1.1 任务拆分

基于Pulse news stream“个性化新闻流推送与交互平台”的核心定位，结合前期原型评估结果，本次Beta冲刺任务按“前端交互优化、后端核心功能开发、数据处理模块完善、测试与问题修复”四大模块拆分，具体任务如下：

前端交互优化模块

• 完成新闻列表页的下拉刷新与上拉加载更多功能开发

• 实现新闻详情页的排版优化

• 开发个性化新闻分类筛选组件（热点、科技、娱乐等）

• 完成响应式布局调整

后端核心功能开发模块

• 搭建新闻数据爬取与存储服务，对接至少3个主流新闻数据源

• 实现用户个性化推荐算法的核心逻辑（基于用户浏览历史、兴趣标签）

• 完成新闻数据的增删改查接口开发，支持前端数据请求

• 实现接口权限控制与数据校验功能，保障接口安全性

数据处理模块完善

• 设计并创建数据库表结构（用户表、新闻表）

• 完成数据清洗逻辑开发，处理爬取新闻数据中的冗余信息、特殊字符

• 实现新闻数据的定时更新任务，保障新闻时效性

• 优化数据库查询语句，提升数据查询效率

测试与问题修复模块

• 编写前端页面功能测试用例（覆盖核心交互场景）

• 对后端所有接口进行接口测试，验证接口正确性与稳定性

• 进行集成测试，验证前后端数据交互的准确性

• 收集测试过程中发现的问题，协同开发人员进行修复

• 对修复后的问题进行回归测试，确保问题彻底解决

1.2 时间排期

本次Beta冲刺周期为10天（2025年12月28日 - 2026年1月6日），具体时间排期如下：

1.3 分工协作

团队共11人，采用“前端4人、后端4人、测试3人”的分工模式，明确各成员职责与协作机制：

协作机制：每阶段晚开展30分钟简短站会，同步当日进度、遇到的问题及次日计划；采用腾讯文档共享任务清单与问题清单，实时更新；接口联调过程中，通过微信实时沟通，确保问题及时解决。

1.4 工具准备

为保障冲刺高效推进，团队统一选用以下开发、协作工具：

版本控制工具：Git + GitHub，用于代码管理、分支控制与协同开发，统一创建develop开发分支，各成员基于feature分支开发，完成后合并至develop分支

开发工具：前端使用VS Code + Vetur（Vue支持），后端使用IntelliJ IDEA，数据库使用MySQL 8.0

接口测试工具：Postman，用于后端接口的调试与测试，由后端人员编写接口测试用例，测试人员复用验证

协作沟通工具：微信（实时沟通）、wps文档（任务清单、问题清单）

部署工具：Docker，用于Beta版本的打包与部署，确保环境一致性

二、团队代码规范

为保障代码的可读性、可维护性与一致性，提升团队协作效率，制定以下代码规范，所有成员需严格遵守：

2.1 命名规则

通用原则：

命名需清晰、准确，体现变量/函数/类的含义，避免使用无意义的缩写（通用缩写除外，如user、info）

不同场景采用对应命名风格，区分清晰：
Java相关
- 类名：用大驼峰（帕斯卡命名法），如 `RssFeedCrawlerService`（每个单词首字母大写）；
- 变量/方法名：用小驼峰（骆驼命名法），如 `economySources`、`militarySources`（首单词小写，后续单词首字母大写）。

HTML/CSS相关
- ID、类名：用短横线分隔命名（kebab-case），全小写单词+短横线连接，如 `main-content`、`stat-item`。

JS相关
- 变量/函数名：用小驼峰，如 `currentDisplayCount`、`performSearch`；
- 常量：用大写下划线分隔（蛇形命名法），如 `MATRIX.PASSWORD`（全大写，单词间下划线分隔）。

2.2 注释规范

注释原则：清晰、简洁，解释“为什么做”和“复杂逻辑”，避免冗余注释（如简单getter/setter无需注释）

类型与用途明确：
1. 单行注释：用 `//`，紧跟被注释代码，说明功能/含义，如：
- Java中 `// "财经新闻"`（说明RSS源的类型）；
- JS中 `// 验证密码是否正确`（说明函数的作用）。

2. 多行注释：用 `/* */`，包裹代码块的功能说明，如 CSS中 `/* 数据展示样式 */`（说明该代码块的样式用途）。

2.3 代码格式

1. 缩进：统一用（目测）4个空格缩进，嵌套结构（HTML标签、Java/JS代码块）按层级缩进，如HTML的`<div>`嵌套、JS的`try/catch`代码块均分层缩进。

2. 换行：
- 独立逻辑/元素单独换行：如Java的`economySources.add`每行写一个；JS的`alert`/`console.error`单独占行；CSS的每个属性单独一行。

3. 代码块分隔：不同功能的代码块（如CSS的不同样式段、JS的不同逻辑块）用空行或注释区分，模块边界清晰。

4. 大括号：Java/JS中，类、函数、代码块的大括号与声明语句同行（如`public class RssFeedCrawlerService {`），代码块内内容换行缩进。

代码长度：单个函数/方法代码行数不超过80行，超过则拆分为子函数；单个文件代码行数不超过500行，超过则按功能拆分文件

前端样式规范：CSS采用BEM命名规范（块__元素--修饰符），如.news-list__item--active；Vue组件内样式优先使用scoped属性，避免样式污染

2.4 版本控制提交规范

提交信息格式：统一采用“类型: 描述”的格式，类型需明确，描述简洁准确，体现提交的核心内容

类型定义：

• fix：修复bug，如“fix: 解决新闻详情页图片加载失败问题”

• refactor：代码重构（不改变功能），如“refactor: 优化用户登录接口参数校验逻辑”

• style：代码格式调整（不改变逻辑），如“style: 统一代码缩进为4个空格”

• docs：文档更新，如“docs: 补充新闻接口测试用例”

• test：添加/修改测试代码，如“test: 编写用户注册接口测试代码”

• chore：构建/工具相关修改，如“chore: 配置Docker打包脚本”

提交规范：

• 每次提交仅包含一个功能点或一个bug的修复，避免一次性提交大量不相关修改

• 提交描述需简洁明了，不超过50字，若需详细说明可在描述后添加空行，补充详细信息

• 示例：
  feat: 实现新闻分类筛选组件
  - 支持热点、科技、娱乐三类新闻筛选
  - 筛选后自动刷新新闻列表

2.5 代码审查流程

审查方式：采用“交叉审查”+“负责人审核”的双重审查机制，前端成员互审、后端成员互审，最终由前端负责人、后端负责人分别审核前端、后端代码，测试人员参与集成测试阶段的代码审查

审查时机：成员完成一个feature分支的开发后，提交合并请求（MR）至develop分支，触发代码审查流程，审查通过后才可合并

审查内容：

• 是否符合命名规则、注释规范、代码格式要求

• 代码逻辑是否清晰、正确，是否存在冗余代码、重复代码

• 是否存在潜在bug（如空指针、数组越界、逻辑漏洞等）

• 接口设计是否合理，参数校验是否完善

• 前端代码是否考虑兼容性、性能优化

反馈与修改：审查人员需在MR中明确标注问题点，提出具体修改建议；开发人员根据反馈修改后，重新提交审查，直至审查通过

审查记录：所有审查意见、修改记录需保留在GitHub的MR评论中，便于后续追溯

三、冲刺展望

本次Beta冲刺是项目推进的关键节点，团队将严格按照上述规划推进开发工作，严格遵守代码规范，确保开发效率与代码质量。后续将重点关注Beta版本的测试反馈，及时迭代优化，为正式版本的顺利发布奠定坚实基础。