2026秋软件工程结对作业（第二次之程序实现）

2026秋软件工程第二次结对作业之程序实现

信息说明

结对成员：102401604马英慧、102401606黄丽婷
结对成员博客链接：
102401604马英慧博客链接：https://www.cnblogs.com/lUoUl
102401606黄丽婷博客链接：https://www.cnblogs.com/halttt
本次作业博客链接：https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering/homework/16744
GitHub仓库地址：https://github.com/halttt/102401604-102401606

一、结对分工与PSP

结对详细分工

马英慧（102401604）：

1. 项目前期准备：新建GitHub仓库，创建项目分支，搭建项目基础文件夹结构，创建index.html、css/style.css空白文件，初始化仓库README文档。
2. HTML页面开发：编写网页整体HTML骨架，搭建导航栏、搜索区域、卡片容器、发布表单弹窗、详情弹窗的DOM结构，完成页面静态元素布局。
3. CSS样式开发：编写页面全部CSS代码，设计卡片样式、圆角阴影、配色方案，区分待处理/已完成状态标签颜色，编写弹窗遮罩样式，调整页面排版，保证页面美观整洁，适配电脑端浏览。
4. 项目文档工作：负责本次结对作业博客园文章的整体框架搭建，整理项目截图，撰写需求分析、设计思路等文档内容，反复调整Markdown格式，保证博客在博客园正常渲染。
5. 协同工作：代码提交、合并PR，审查队友提交的代码，发现页面样式冲突、布局问题，与队友沟通并共同修复。

黄丽婷（102401606）：

1. JavaScript业务逻辑开发：编写main.js全部核心功能代码，封装localStorage读写函数、列表渲染函数。
2. 功能模块实现：开发表单提交与前端校验逻辑、关键词实时搜索过滤逻辑、弹窗显示隐藏控制逻辑、物品状态修改逻辑，额外实现附加功能——联系方式一键复制。
3. 项目测试：对每一个功能模块进行单元测试，手动测试各个交互场景，寻找页面bug，比如数据保存失效、弹窗重复弹出、搜索过滤异常等，并且完成bug修复。
4. 素材收集：录制功能演示、截取网页运行截图，整理测试用例与测试结果，整理PSP工时记录。
5. 协同工作：Fork仓库，新建分支开发JS代码，提交Pull Request，等待队友审核合并，在开发中与队友沟通逻辑问题，调整功能交互细节。

协作说明：两人采用GitHub分支协作模式，各自在独立分支开发，开发完成提交PR，互相进行代码复审，确认无误后合并到主分支，避免直接修改main主分支造成代码覆盖冲突。遇到分歧采用结对讨论的方式协商确定方案。

PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	20	25
· Estimate	· 估计任务工作量，划分两人任务	20	25
Development	开发	320	350
· Analysis	· 需求分析，梳理基础功能+附加功能	40	45
· Design Spec	· 生成设计文档，定义数据模型	30	35
· Design Review	· 设计复审，结对讨论方案可行性	30	25
· Coding Standard	· 约定代码规范、变量命名规范	20	20
· Design	· 具体设计：页面结构、函数划分	40	50
· Coding	· 代码实现，HTML、CSS、JS编码	120	130
· Code Review	· 代码复审，互相查看代码，查找bug	20	25
· Test	· 功能测试，编写测试用例，手动测试	20	20
Reporting	报告	60	70
· Test Report	· 撰写测试报告，记录测试结果	20	25
· Size Measurement	· 工作量统计，统计PSP工时	10	10
· Postmortem & Process Improvement Plan	· 项目复盘，总结问题与改进方案	30	35
合计		400	445

PSP说明：
预估阶段，我们评估整体任务，拆分计划、开发、报告三大阶段，分配预估工时。实际开发过程中，编码和详细设计花费时间超出预估，主要原因是调试弹窗交互、本地存储数据同步、剪贴板API容错处理花费了额外时间。代码复审环节比预估更快，得益于结对两个人互相快速定位问题。最后复盘阶段，我们梳理本次开发遇到的难点，记录可以优化的地方，完成整个PSP流程。

二、解题思路描述与设计实现说明

1. 需求分析

本次结对编程作业，是在第一次结对作业原型设计基础之上，完成校园失物招领Web网页的程序开发。我们首先仔细研读作业要求，对业务需求、限制条件进行完整拆解。

核心业务需求：

1. 信息发布：用户能够发布两类信息，寻物启事（物品丢失，寻找捡拾者）、招领启事（捡拾到物品，寻找失主）；发布表单需要填写物品名称、物品描述、遗失/拾取地点、联系方式、发布人昵称等内容。
2. 信息浏览：网页首页集中展示所有已发布的失物招领信息，以卡片形式展示摘要，方便学生快速浏览。
3. 关键词搜索：支持按照物品名称进行检索，快速筛选出相关的寻物、招领记录，减少手动翻找的成本。
4. 详情查看：点击物品卡片，弹出详情窗口，展示这条记录的完整信息，包含发布者联系方式，方便双方沟通。
5. 状态更新：发布者在物品完成找回或者归还之后，可以将这条信息标记为“已找到”或“已归还”。标记之后所有用户都能看到物品状态，避免大量重复咨询，减少无效沟通。

作业限制说明：本次开发不强制实现后端服务器、账号注册登录、实名认证、即时聊天、地图定位等复杂功能。结合两人结对的技术能力与作业截止时间，我们选用纯前端方案，利用浏览器localStorage实现本地持久化存储。网页关闭之后，已经录入的失物数据不会丢失，再次打开网页可以继续查看。整个项目采用HTML+CSS+原生JavaScript开发，开发、测试统一使用谷歌Chrome浏览器，规避不同浏览器的样式差异、JS API兼容问题，保证助教下载项目文件后，直接双击打开index.html即可正常运行。

在基础需求之外，我们结合校园真实场景挖掘痛点。校园学生使用时，查看联系方式后，手动选中文字复制号码操作麻烦，容易选不中。因此我们计划额外增加一键复制联系方式的附加功能，提升产品易用性。

2. 整体设计思路

1. 页面模块拆分
   项目采用单页面设计，全程不跳转多个HTML页面。页面划分为四大核心模块：首页物品列表模块、发布信息弹窗模块、物品详情弹窗模块、我的发布模块。依靠JS控制弹窗DOM的显示与隐藏切换视图，没有页面刷新，交互流畅。

2. 数据模型定义
   每一条失物招领信息为独立JS对象，每条记录设置唯一id，防止记录混淆。对象字段如下：

• id：记录唯一编号
• type：信息类型（寻物 / 招领）
• name：物品名称
• desc：物品详细描述
• place：遗失地点或者拾取地点
• contact：发布者联系方式
• author：发布人昵称
• time：信息发布时间
• status：物品状态，可选：待处理 / 已找到 / 已归还

3. 数据存储方案
   使用浏览器localStorage持久化存储全部记录数组。封装两个全局函数统一管理数据读写：getList()负责读取本地存储的记录数组；saveList()将更新后的数组转为字符串存入本地存储。项目所有模块复用这一组读写函数，统一数据入口，减少重复代码，降低维护成本。

4. 各功能模块详细规划

• 发布模块：提交表单前做前端表单校验。物品名称、联系方式为必填项，为空则拦截提交，弹窗提示用户补全。校验通过后自动生成唯一id，获取当前系统时间，组装完整记录对象，存入localStorage，自动刷新首页列表，新发布信息立刻展示。
• 搜索模块：监听搜索框输入事件，获取用户输入关键词。遍历记录数组进行过滤，匹配逻辑忽略大小写。只要物品名称包含关键词，就筛选出来渲染卡片；没有匹配记录时，页面展示“暂无匹配物品，请更换关键词重试”的友好提示。
• 我的发布模块：依据发布人昵称筛选记录，页面仅展示当前用户发布的所有信息。做简单权限控制：仅在本人发布的卡片上展示【修改状态】按钮，他人发布的记录不会出现该按钮，避免用户随意修改别人的信息。
• 状态修改模块：发布者点击状态修改按钮，程序通过唯一id定位目标记录，修改status字段，调用saveList保存数据，之后执行页面渲染函数，卡片上的状态标签实时更新，所有用户都可以看到最新状态。

3. 关键实现的流程图（数据流图）

下面为网页业务数据流图，使用Mermaid绘制，博客园开启Mermaid支持即可自动渲染。

flowchart TD A[用户打开网页] --> B[加载localStorage数据，渲染首页物品列表] B --> C{用户操作选择} C -->|发布寻物/招领| D[打开发布弹窗] D --> E[填写表单，前端非空校验] E -->|校验通过| F[生成物品对象，存入localStorage] E -->|校验失败| D F --> B C -->|关键词搜索物品| G[获取搜索词，过滤数组] G --> H[忽略大小写，匹配物品名称] H --> I{是否匹配到记录} I -->|有匹配结果| I1[渲染筛选后的物品卡片] I -->|无匹配结果| I2[展示无结果提示文字] C -->|查看我的发布| J[按发布人名称筛选记录] J --> K[渲染个人发布列表，显示状态修改按钮] K --> L[发布者点击更新物品状态] L --> M[修改记录status字段，保存到localStorage] M --> B C -->|查看物品详情| N[打开详情弹窗，展示联系方式]

流程图说明：本图完整描述项目业务数据流。项目不搭建后端服务器，所有数据全部保存在浏览器本地localStorage。新增信息、修改物品状态这类写数据操作，都会更新本地存储，并且调用页面渲染函数刷新界面。搜索、查看详情属于只读操作，不会修改存储的数据。

4. 代码实现思路，文字描述

项目全部使用原生前端技术开发，不引入 Vue、React 等大型前端框架，最大程度降低项目环境依赖。助教拿到项目文件夹之后，不需要安装任何依赖，直接用谷歌浏览器打开 index.html 就可以运行页面。

HTML 负责搭建页面基础骨架，划分导航栏、搜索区域、卡片展示容器、弹窗容器等页面结构，搭建好所有需要的 DOM 元素。CSS 负责页面美化，设置卡片圆角、阴影、配色，区分不同状态的标签颜色，调整响应式布局，让页面排版整齐美观。JavaScript 承担页面全部业务交互逻辑。

我们封装统一的数据读写函数getList()与saveList()，项目里所有模块读取、保存数据时都复用这两个函数。好处是数据读写逻辑只写一次，后续如果修改存储规则，只需要改动这两处代码，便于维护。

封装全局渲染函数renderList()，接收物品记录数组作为入参，循环遍历数组动态生成物品卡片 DOM。新增记录、修改物品状态、关键词搜索切换结果时，统一调用renderList()刷新页面内容，保证页面展示数据和本地存储数据保持同步。

发布表单校验逻辑写在表单提交事件内，在数据存入存储之前拦截非法空数据，保证存储数据有效性。物品状态更新功能依靠每条记录的唯一 id 定位目标对象，修改 status 字段，保存之后重新渲染页面，实现页面实时更新，不需要手动刷新网页。

三、重要代码片段及解释

读取、保存本地存储，修改物品状态核心代码：

// 保存、读取本地存储数据，持久化失物招领列表
function getList() {
  const data = localStorage.getItem("lostFoundList");
  return data ? JSON.parse(data) : [];
}
function saveList(arr) {
  localStorage.setItem("lostFoundList", JSON.stringify(arr));
}
// 修改物品状态
function changeStatus(id, newStatus) {
  let list = getList();
  let target = list.find(item => item.id === id);
  if(target){
    target.status = newStatus;
    saveList(list);
    renderList();
  }
}

代码解释：

1. getList()：读取浏览器本地存储中的失物数组，如果不存在则返回空数组。
2. saveList()：将 JS 数组转为 JSON 字符串存入 localStorage，实现持久化保存。
3. changeStatus：根据物品唯一 id 找到目标记录，修改状态字段，保存数据并重新渲染页面，实现状态实时更新展示。

四、附加特点设计与展示

1. 设计的创意独到之处，这个设计的意义

本次项目除作业要求的基础功能外，额外增加一键复制联系方式的人性化功能。
在校园失物招领的真实使用场景中，学生浏览物品信息之后，如果想要联系发布者，传统方式需要手动拖动鼠标选中手机号或者QQ号，再右键复制，操作步骤多，网页快速浏览时很容易选不中文字，操作繁琐。增加一键复制功能之后，用户只需要点击联系方式文本，就能自动将信息复制到系统剪贴板，省去手动选中文字的操作，大幅简化用户操作流程。
该设计的核心意义是优化用户体验，减少使用过程中的操作阻力。对于失物招领平台来说，用户联系发布者越方便，物品找回、归还的概率就越高。这个小功能贴合校园学生真实使用习惯，属于轻量化、实用性强的附加优化，不增加系统复杂负担，却能显著提升页面的便捷程度。

2. 实现思路

在物品详情弹窗渲染完成后，给联系方式DOM元素绑定点击事件。采用浏览器原生Clipboard剪贴板API编写异步函数，点击触发函数时，读取联系方式文本，调用写入剪贴板接口。
由于部分浏览器环境存在剪贴板权限限制，代码增加异常捕获机制。复制成功时弹出提示，告知用户复制完成；如果遇到权限不足等异常导致复制失败，则弹出提示引导用户手动复制，做了容错处理，保证功能健壮性，适配谷歌浏览器。
在页面渲染详情卡片的逻辑中，给联系方式标签添加点击事件，将存储的联系方式作为参数传入复制函数，实现点击触发复制。

3. 贴出你认为重要的/有价值的代码片段，并解释

// 一键复制联系方式
async function copyContactText(text) {
  try {
    await navigator.clipboard.writeText(text);
    alert("联系方式复制成功，可以直接粘贴使用！");
  } catch (err) {
    alert("复制失败，请手动复制联系方式");
  }
}

代码解释：
这是异步函数，使用navigator.clipboard.writeText调用浏览器剪贴板接口，传入需要复制的联系方式字符串。try-catch用来捕获权限、浏览器环境带来的异常。复制成功，弹出提示框反馈给用户；一旦接口调用失败，进入 catch 分支，提示用户手动复制，防止功能完全失效。在详情弹窗的联系方式标签绑定 onclick 事件，点击元素就调用copyContactText，传入当前这条记录的联系方式。

4. 实现成果展示

页面打开物品详情弹窗后，联系方式文字区域带有可点击的交互提示。点击联系方式，页面弹出成功提示框，代表文本已经复制到剪贴板，用户可以直接粘贴到微信或者短信中。

五、目录说明与使用说明

1. 项目目录结构

lost-found
├─ index.html # 网站首页主页面，包含页面全部HTML结构
├─ css
│ └─ style.css # 页面样式文件，负责布局、配色、卡片与弹窗样式
└─ js
└─ main.js # 业务逻辑JS文件，包含数据读写、渲染、弹窗、搜索等全部功能

目录结构说明：项目采用轻量化前端目录设计，将页面结构、样式、脚本分离，符合前端代码规范，便于结对两人分开维护不同文件。index.html承载页面静态DOM骨架，导航栏、搜索框、卡片容器、弹窗容器全部在此定义；style.css统一管理全局样式，包含页面响应式布局、卡片阴影圆角、不同状态标签配色、弹窗遮罩层样式；main.js存放所有交互业务逻辑，数据持久化、列表渲染、表单校验、搜索过滤、弹窗开关、状态修改、一键复制等功能全部封装在此js文件内。文件拆分之后，两个人并行开发互不干扰，修改样式不会改动JS逻辑，修改脚本也不会破坏页面HTML结构，方便GitHub分支提交与代码合并。

2. 使用说明

1. 下载完整项目文件夹，无需安装任何依赖包、不需要配置服务器。
2. 使用谷歌Chrome浏览器，直接双击index.html打开网页即可运行项目。
3. 各项功能详细操作指引：
   • 发布寻物/招领信息：点击页面顶部【发布信息】按钮，弹出发布表单弹窗。选择信息类型为“寻物启事”或者“招领启事”，依次填写物品名称、物品详细描述、遗失/拾取地点、发布人昵称、联系方式。表单会实时校验必填项，如果物品名称或者联系方式为空，点击提交按钮会弹出提示，禁止提交。填写全部信息并提交后，表单自动关闭，首页物品列表自动刷新，新发布的物品卡片直接展示在首页。
   • 物品关键词搜索：在页面顶部搜索输入框输入物品名称关键词，无需点击搜索按钮，输入的同时实时对全部记录进行过滤筛选。页面只展示物品名称包含该关键词的卡片，大小写不敏感；如果没有匹配的物品，页面展示友好提示文字“暂无匹配物品，请更换关键词重试”。清空搜索框内容，页面恢复展示全部物品记录。
   • 查看物品详情：首页点击任意物品卡片，弹出详情弹窗。弹窗完整展示这条记录的全部信息：信息类型、物品名称、物品描述、地点、发布人、发布时间、物品当前状态。弹窗内的联系方式文字支持点击一键复制。点击弹窗关闭按钮或者弹窗遮罩空白区域，即可关闭详情弹窗。
   • 我的发布与物品状态修改：点击导航栏【我的发布】选项，页面会根据填写的发布人昵称，筛选并只展示当前用户发布过的所有寻物、招领记录。仅本人发布的卡片上会出现【修改状态】按钮。点击按钮，可以切换物品状态为“已找到”或者“已归还”，保存后卡片上的状态标签实时更新。

六、测试

测试环境

浏览器：Google Chrome，版本126.0
操作系统：Windows11

测试思路

本次项目采用手工黑盒测试，模拟校园里普通学生的真实使用行为，不使用自动化测试脚本。我们针对需求清单逐条设计测试场景，除正常操作流程外，额外考虑用户漏填信息、随意输入关键词、重复点击界面元素等容易出现的误操作，检验程序能否稳定响应，提前捕获隐藏缺陷。

测试用例

1. 发布失物招领信息测试
   • 用例1：完整填写表单全部栏目，选定类型为招领启事，物品名称、物品描述、拾取地点、发布人昵称、联系方式均正常填写，点击提交按钮。预期结果：表单弹窗自动关闭，首页物品列表刷新，新增的物品卡片展示在页面上。
   • 用例2：仅清空物品名称输入框，其余内容全部填写完毕，点击提交。预期结果：页面弹出提示，阻止本次表单提交，不会生成空白物品卡片。
   • 用例3：不填写联系方式，其他输入项全部补齐，选择寻物启事类型并提交。预期结果：触发表单校验，提示补充联系方式，数据不会保存。
2. 物品检索功能测试
   • 用例1：搜索框输入关键词“校园卡”，系统内存在相关记录。预期结果：页面只保留物品名称包含“校园卡”的卡片，其余卡片隐藏。
   • 用例2：搜索框输入当前不存在的物品关键词“羽毛球拍”。预期结果：页面展示提示文字，告知用户暂无匹配记录。
   • 用例3：物品存储名称是“耳机”，搜索时输入大写“耳机”。预期结果：检索可以正常匹配，检索逻辑不区分字母大小写。
   • 用例4：删除搜索框内全部文字。预期结果：页面恢复展示所有已发布的寻物、招领卡片。
3. 详情弹窗与联系方式复制功能测试
   • 用例1：点击首页任意物品卡片。预期结果：详情弹窗弹出，物品的全部信息完整展示。
   • 用例2：点击详情弹窗内的联系方式文本。预期结果：触发复制逻辑，弹出提示，联系方式存入剪贴板。
   • 用例3：点击弹窗外围遮罩空白区域。预期结果：详情弹窗直接关闭，返回首页卡片列表。
4. 我的发布与物品状态更新测试
   • 用例1：发布信息时填写昵称“小周”，切换导航栏至【我的发布】页面。预期结果：页面仅展示昵称“小周”发布的所有记录。
   • 用例2：查看其他用户发布的物品卡片。预期结果：卡片上不存在状态修改按钮，不能修改他人发布内容。
   • 用例3：打开本人发布的记录，点击修改状态，切换状态标记为已归还。预期结果：卡片上状态标签同步更新，修改内容自动保存。
5. 本地数据持久化测试
   • 用例1：新增多条物品记录，关闭浏览器标签，重新打开index.html。预期结果：所有之前录入的信息依旧存在，物品状态保持不变。
   • 用例2：多次新增记录、反复修改物品状态，刷新页面。预期结果：所有改动全部保存，数据条目不会丢失、错乱。

测试结果

全部测试场景手动执行完毕，核心功能均符合设计预期。表单校验能够拦截无效提交，实时检索、弹窗交互、联系方式复制、状态更新和本地存储都可以稳定运行。测试过程发现一个交互缺陷：短时间连续多次点击卡片会同时弹出多层详情弹窗。我们增加了弹窗状态标记，限制同一时间只能打开一个弹窗，修复后交互体验得到改善。整体程序不存在致命bug，可以满足本次结对作业的功能需求。

单元测试

1. 测试工具、学习过程与简易教程

本次单元测试选用Chrome浏览器自带控制台，无需额外下载Jest、Mocha等测试框架，降低环境配置成本。
学习过程：我们查阅JavaScript单元测试基础资料，学习区分DOM操作和纯数据处理函数，将读写本地存储这类不依赖页面元素的逻辑抽离出来单独测试，隔离页面渲染带来的干扰，只校验数据处理结果。

简易教程：

1. 用Chrome打开项目网页，按下F12打开开发者工具，切换到Console控制台；
2. 将需要测试的函数复制粘贴到控制台中；
3. 手动构造测试数据，调用目标函数；
4. 对比函数返回结果和我们预期结果，判断函数是否运行正常

2. 单元测试代码，说明测试的函数

function testLocalStorageFunc() {
  const testData = [{id:1, name:"测试校园卡", type:"寻物", author:"测试用户"}];
  saveList(testData);
  const res = getList();
  if(res[0].name === "测试校园卡"){
    console.log("✅测试通过：本地存储读写正常");
  }else{
    console.log("❌测试失败");
  }
}
testLocalStorageFunc();

测试对象：getList() 和 saveList() 两个工具函数。
测试目的：验证本地存储的读写功能正确性。先写入构造好的测试物品数据，再读取存储内容，对比读取出来的数据和原始写入数据是否一致。

3. 构造测试数据思路，考虑异常/刁难场景

构造测试数据时，除正常完整物品对象外，额外准备空数组、缺失部分字段的残缺对象。
考虑多种极端刁难场景：清空localStorage、连续循环多次读写、页面刷新后读取存储数据。
目的：检验函数在异常输入的情况下不会崩溃报错，保证程序稳定，防止页面出现未捕获异常。

七、结对感受与总结

在本次结对编程作业中，我们基于上一轮的原型设计，把校园失物招领的想法实现为可本地直接运行的网页程序。开发使用GitHub仓库协同，一人负责页面布局、HTML骨架和CSS样式美化，另一位负责JS交互逻辑的编写，遇到问题两个人一起讨论调试。
真正动手编码之后，我们感受到原型图和实际代码之间存在不小差距。很多在原型上看着简单的交互，写代码时会遇到各种细节难题，例如本地存储更新后页面如何刷新、弹窗开关控制、剪贴板接口在浏览器中的权限限制等，这些细节在原型设计阶段很难考虑周全。结对编程的好处就是两人可以互相审阅代码，快速发现对方忽略的问题，减少程序缺陷。

同时我们也意识到这个纯前端实现方案的短板：所有数据保存在浏览器本地存储里，如果用户清理浏览器缓存，所有发布信息都会消失。如果后续继续迭代项目，可以增加后端数据库，实现多设备数据互通，增加账号登录模块，进一步完善整个系统。

这次作业完整走完从原型到代码实现、测试、文档编写的流程，锻炼了前端编码、GitHub团队协作、软件测试和项目文档撰写能力。结对编程不是简单拆分任务各自写代码，互相评审、一起讨论方案、协同排查bug，能够更早发现设计上的不足，提升最终软件的质量。

八、Github代码签入记录

下图为本项目GitHub提交记录，每次提交都编写规范commit信息，清晰记录每次改动内容。

九、遇到的代码模块异常或结对困难及解决方法

1. 问题一

• 问题描述：短时间连续多次点击物品卡片，会同时弹出多层详情弹窗，页面交互错乱。
• 做过哪些尝试：一开始只写弹窗隐藏逻辑，快速点击时事件来不及终止；后面增加全局弹窗状态标记，记录弹窗打开/关闭状态。
• 是否解决：✅已解决
• 有何收获：弹窗交互必须增加状态锁，限制重复触发；前端开发要考虑用户快速连续点击这类非常规操作。

2. 问题二

• 问题描述：直接双击本地HTML文件打开网页时，浏览器安全策略会限制剪贴板接口，一键复制联系方式的功能无法正常触发。
• 做过哪些尝试：查阅官方文档了解本地file协议的权限限制；在复制代码增加try-catch捕获异常，当复制失败时弹出提示给用户。
• 是否解决：✅增加了降级方案，复制失败会提示用户手动复制文本
• 有何收获：浏览器不同访问方式权限不一样，开发前端功能要提前考虑环境差异，增加异常兜底逻辑，避免功能直接失效。

十、评价队友

值得学习的地方

队友在页面设计与CSS样式实现方面很有想法，对界面的美观度、细节排版比较敏感，愿意反复调整卡片配色、圆角、间距，让网页看起来整洁舒服。写出来的HTML和CSS代码结构清晰，命名规范。在GitHub协作过程中，每次提交代码都会写清楚commit注释，方便我们回溯每次改动。遇到项目难题时，不会搁置问题，会主动和我沟通想法，一起商量可行的解决方案。在文档撰写阶段，主动收集项目截图，配合梳理博客内容，分工上十分配合，结对沟通效率很高。

需要改进的地方

在JavaScript逻辑开发时，前期思考更多是正常流程下的功能实现，对于各种边界、异常场景考虑偏少，很多问题只有在实际测试的时候才会暴露出来。另外编码习惯上，有时候会一次性写完一整块功能代码再提交，没有拆分成更小的增量分步提交。一旦出现bug，需要在一大段代码里定位错误，增加了调试和代码复审的压力。后续开发可以尝试小步迭代，完成一个微小功能就提交一次，便于结对互相审查，问题也可以尽早发现，避免大量缺陷集中到最后才暴露。