掌中生活——α冲刺Day5

掌中生活 掌中生活 墨衍会员 · AI 创作全网分发 墨衍智能分发 通过墨衍一键同步至各平台 可同步平台 CSDN微信公众号微博知乎掘金百家号博客园抖音小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年,写一次发全网 我也要 + 加入社区

掌中生活——α冲刺Day5

这个作业属于哪个课程202601福大-软件工程实践-W班
这个作业要求在哪里软件工程实践团队作业-站立式会议+α冲刺
这个作业的目标记录 Alpha 冲刺第 5 天站立式会议(线上):C1/C2 分类标签完成、G1 日期节点服务、status_log 写入方补齐、CI 首次执行失败排查,燃尽领先计划 20 点
其他参考文献《构建之法》第2章、13章;团队代码规范 v1.0;《04-接口契约文档 v1.0》;CR-20261027-01 契约变更单

目录

  • 掌中生活——α冲刺Day5
  • 一、今日站立式会议
  • 二、燃尽图
  • 三、成员进展
  • 四、AI 技术员工作(今日)
  • 五、代码签入与 Issue
  • 六、运行截图
  • 七、明日计划

一、今日站立式会议

  • 时间:2026-10-27 22:00–22:40(线上,腾讯会议)
  • 主持:黄炫文
  • 参会:全员 7 人 + AI 技术员(AI-P/AI-T/AI-D)
  • 议题与决议:
    1. 进度同步:C1 分类默认值与 C2 标签即时创建(含 AccountRepo 补齐、TaxonomyServiceImpl 重写)、G1 DateNodeService 五方法与纯校验、AuditRepo/StatusService(补上全仓缺失的 status_log 写入方)、新建记录联调验证均完成;燃尽 52 → 32,领先计划 20 点;
    2. 缺陷处置:D-01~D-04 连续三天未修,账号落 Room 后 D-01 风险升级(半成品账号真正写进 app_user 表)——决议 Day6 第一优先修复 D-01,D-02/D-03 一并处理;陈瀚楷另发现 D-05(computeNextDate 期数无上限导致年份溢出,P3);
    3. 契约变更:CR-20261027-01 三条偏差(register 缺密保问题号、countRecordsByTag 归属、AccountRepo 暂不实现偏好)——由黄炫文裁决是否升版,Day6 站会前答复;
    4. CI 流水线:首次执行失败(构建机 gradlew 权限问题),已定位,修复中;
    5. 明日(Day6)闭环联调安排(见第七节)。

img

二、燃尽图

img

剩余 32 点:今日完成 C1(6 点)+ C2(6 点)+ G1(8 点)共 20 点,领先计划 20 点。

三、成员进展

成员昨日进展存在问题明日安排心得体会
黄炫文收齐全员材料;docs 签入站会纪要 Day5 与燃尽数据;发布 Day5 随笔;CI 流水线首次执行失败排查(构建机 gradlew 权限问题定位)CI 构建机执行权限修复待验证;CR-20261027-01 三条契约偏差待裁决CI 修复后重跑;Day6 随笔;冲刺总结材料准备CI 第一次跑就挂,反而把"每天构建必须成功"这条红线的价值暴露出来了——问题越早出现越便宜
胡昊交付 AuditRepo(status_log/access_log 读写)、StatusService(契约 7.6 四方法)、RecordRepo.changeStatus(只改 status 一列),补上全仓库此前缺失的 status_log 写入方(提交 4a6445f/4e9fcdc/d9d01ac,20 文件 +2521/−7)真机测试发现 listStatusLog 排序不稳定:changed_at 只精确到毫秒,同一毫秒内两次变更顺序未定义,已改 ORDER BY changed_at DESC, log_id DESC;LmDatabase 单例缓存了已关闭连接,已加 resetForTest();dev 上 check_local.sh 第 3 阶段失败(4 个问题在队友的 RecordEditFragment/RecordDetailViewModel,非本轮引入)配合吴军峰完成 Day6 F2 状态流转 UI(他直接调 StatusService.changeStatus,留痕和事务已封装)触发器要求"先改 record.status 再插日志",顺序颠倒必被 DBAC12 拒;旧状态必须在事务内取出,提交后再查只会得到 DONE→DONE;同一个毫秒内的排序必须靠 log_id 兜底
陈志G1 完成:DateNodeService 五个方法契约 + 节点名称/日期/leadDays 纯校验 + 基于 baseDate 锚点的月末闰年计算;新增 18 条单测,全量 144 条单测全过,assembleDebug、数据库 12 项回归和静态检查均通过(提交 b4fb17e,Issue #71204545)DateRepo 和会话账号隔离尚未接入,CRUD 持久化暂以 TODO(#71204545) 和 E_NOT_IMPLEMENTED 保留;排期表曾把 F1 列在 Day5,与专项拆解口径冲突,已按 G1 执行Day6 接入 DateRepo,通过会话获取 userId 实现节点查询/新建/修改/删除;补第 6 个节点返回 E_NODE_LIMIT、越权或不存在返回 E_NOT_FOUND日期节点看似只是日期计算,但月末和闰年规则一旦采用累加方式就会逐渐错期,必须始终从基准日期按锚点计算
陈瀚楷梳理 dev 今日两次合并,编写并执行 27 条单测:DateNodeServiceImpl 21 条 + 缺陷回归 6 条;结果 22 通过 / 5 失败;日期节点校验 21 条全绿(名称上限、OTHER 必填、日期格式、提前天数 0365、锚点语义 1-31 按月第 2 期是 03-31、闰年 02-29 按年推回);确认 CRUD 未接仓储时显式返回 E_NOT_IMPLEMENTED;新发现 D-05(computeNextDate 期数无上限,Int.MAX_VALUE 期推到年份 178958996 仍返回 Success,P3);D-01D-04 全部原样复现;输出 Day5 测试报告(6 页)账号侧 4 条缺陷连续三天未修,D-01 现在会把半成品账号真正写进 app_user 表,清理成本翻倍,建议 Day6 第一优先;节点 CRUD 全是占位,记录详情页接不上日期节点;MAX_NODE_PER_RECORD=5 只写在常量里无代码校验;CR-20261027-01 未见契约升版推动 D-01 优先修复并回归(D-02/D-03 改常量与正则可一并处理);节点 CRUD 接 DateRepo 后补端到端用例;开始 T6 用例骨架今天最值得记的不是"新功能过了 21 条",而是"老问题又过了一天"——缺陷不会因为没人提就消失,账号从内存搬进数据库之后,同一个 D-01 的修复成本已经翻倍
杨俊鑫完成新建记录联调验证:模拟器新增物品类记录、设置标签/日期节点/提前提醒,保存后在列表和详情查看并编辑备注;重启应用后记录仍在,Database Inspector 能查到数据;字段级校验已验证;改动已提交合入 dev 申请(Issue #71200238,待评审)注册页本地验证项答案问题仍未处理(已记录,与本次联调无关);合入申请尚待评审参与 Day6 闭环联调,重点验证新建记录后列表和详情展示,配合检查状态更新后的详情结果,问题登记 Issue通过模拟器操作和 Database Inspector 一起核对,确认了记录不仅能显示,也确实保存到了本地数据库
吴军峰C1+C2 完成:先补 AccountRepo(record/tag/user_category_setting 三表都有 app_user 外键,C1 按账号落库绕不过去);TaxonomyServiceImpl 重写(端口加 userId + suspend + 注入 SessionService,单测替身从 21 个方法降到 5 个);标签去重只在服务层做(normalized_name);设置页四类默认敏感级别可改;发现并修复重要问题:注册流程原本 100% 失败(app_user 有 CHECK 要求密保问题号与答案成组存在,契约 register 不收问题号,INSERT 必被拒——固定 DEFAULT_SECURITY_QUESTION_ID=1,登记 CR);提交 0f38688/37f9287/f328760,Day5 增量 25 文件 +2369/−98,MR !10;验证:check_local.sh ALL CHECKS PASSED(10 类/140 条)、verify_day5_sql.py 23 通过/0 失败CR-20261027-01 三条契约偏差待群内确认(register 缺密保问题号需黄炫文裁决、countRecordsByTag 归属、AccountRepo 暂不实现 getPreference);Gradle test worker 在中文 GRADLE_USER_HOME 下必崩,脚本兜底路径改 D:/tmpDay6 F2 状态流转 UI(直接调 StatusService.changeStatus);配合 I1 闭环联调把口头结论写成可执行脚本——verify_day5_sql.py 是把"我确认过"变成"每次都能确认"的转化,这类工作价值高于改代码
李天赐全量审查 dev 分支 Day4 夜间提交:注册登录链路接通(AuthViewModel 调 ServiceLocator.accountService)、ServiceLocator 从只装 sessionService 扩展为装配全部五个服务、sessionPersistence 桥接正确;静态核对 RecordServiceImpl/TodoServiceImpl 对 SessionService 的用法符合契约 S5(currentUserId 判空转 E_SESSION_EXPIRED,不向上抛异常)与 S7(isUnlocked 判定 PROTECTED 内容);产出 Day5 模拟器联调验收清单:6 个用例每步操作和预期结果写死,并标注"哪条不过该找谁"AccountStore 仍是 InMemoryAccountStore(杀进程后账号需重新注册),等胡昊 AccountRepo 落地替换;ServiceLocator 注释自报"core 包 import 了 service.impl 违反契约 2.2",属团队既有约定,不阻塞本期按验收清单在模拟器跑 6 个用例,重点是用例 3(第 5 次当场锁)和用例 4(强杀重启仍锁),拿两张真截图Day4 我说的 3 个接线缺口,杨俊鑫一个晚上全补上了;定位器从 30 行扩到 150 行,每个新服务接入都是同一套模式——这就是 Day1 冻结接口的价值,接的时候没人需要回头改签名

四、AI 技术员工作(今日)

今日角色:AI-P/AI-T/AI-D 并进;全部产出经人工核对/实际执行后采纳。

  • AI-P(codex,杨俊鑫驱动):协助梳理测试步骤、分析分支合入状态并整理日报,采纳测试顺序和合并申请描述建议;
  • AI-P(codex/deepseek,吴军峰驱动):跨文件追链路("账号在内存里→谁调用 saveSession→ServiceLocator 没装配 accountService"这条线靠 grep 定位比人快得多);机械排查零引用(Day4 清出 9 条无用字符串、Day5 核对 ROOM_OWNED_TABLES 是否覆盖全部实体);把口头结论写成可执行脚本(verify_day5_sql.py);契约与代码对读(deleteTag 错误码 REC-05 vs REC-10、fallbackToDestructiveMigration 的 API 版本差异都是逐条对读查出来的);
  • AI-P(codex,陈志驱动):生成日期节点服务、纯校验、锚点日期计算及测试代码,采纳其完整实现和锚点日期方案;
  • AI-P(codex,李天赐驱动):生成 6 个用例的预期/异常对照表,人工核对"用例 3 第 5 次当场锁"和"用例 5 锁定期内不累加"两个边界后采纳;
  • AI-T(deepseek harness,陈瀚楷驱动):拉起今日两次合并、抽取日期节点服务源码生成 27 条用例并实际执行;其中"超大期数"一条原本按规格写成断言、跑出来才发现实现会年份溢出,顺手登记为 D-05;
  • AI-P(deepseek harness,胡昊驱动):分支交叉比对与契约一致性检查;单测和真机测试的用例设计由本人确定,AI 辅助生成后逐条核对断言;
  • AI-D(DeepSeek v4 pro,黄炫文驱动):全员材料汇总整理、Day5 随笔初稿。

AI-P 驱动实录(胡昊 · deepseek harness,两段对话)

对话一:「看一下 day5 的工作安排,不需要动手,你输出给我看」——AI 输出 Day5 计划与实际执行核对结论:计划里的 3 个任务(C1、C2、F1)对应代码都已上线,但 C1 归类混进了 Day6 的东西、F1 其实提前 3 天做完、另有 4 个附件类交付缺失;对话二:「那是不是需要三个新建合并请求」——AI 实测"分两次合并"流程后给出结论:只需一个 MR(integration/day4-verified 已包含另外两条分支,先合 fix/record 或先合 locator 都会在 LmApplication.kt 与 ServiceLocator.kt 各冲突一次)。两个结论均人工核对后采纳。

img

img

今日度量:AI 生成并实际执行的单元测试 27 条(陈瀚楷,22 通过/5 失败)+ 18 条(陈志新增);本地一键验证 140 条全过(吴军峰)+ SQL 约束验收 23 条全过;确认新缺陷 1 个(D-05),遗留缺陷 4 个复现(D-01~D-04)。

五、代码签入与 Issue

时间作者提交说明关联工作项
日间吴军峰0f38688 data-C1 分类默认值与标签接入 Room;37f9287 ui-C2 标签芯片适配器与移除交互;f328760 docs-CR Day5 三处契约偏差(Day5 增量 25 文件 +2369/−98,MR !10)#71193367
日间陈志b4fb17e G1 DateNodeService 五方法 + 纯校验(新增 18 单测,全量 144 全过)#71204545
日间胡昊4a6445f/4e9fcdc/d9d01ac AuditRepo + StatusService + RecordRepo.changeStatus(20 文件 +2521/−7,status_log 写入方补齐)#71192105
日间杨俊鑫新建记录联调验证提交(合入 dev 申请,待评审)#71200238
日间陈瀚楷Day5 测试代码(分支提交,待推送)+ 测试报告 6 页—
晚黄炫文a6c42d5 docs: 站会纪要 Day5 与燃尽数据#71192105

签入截图:

杨俊鑫 · Day5 签入记录

img

吴军峰 · Day5 签入记录(0f38688/37f9287/f328760,四张)

img

img

img

img

陈志 · Day5 签入记录(b4fb17e,DateNodeService)

img

陈瀚楷 · Day5 签入记录

img

胡昊 · Day5 签入记录(4a6445f/4e9fcdc/d9d01ac)

img

黄炫文 · Day5 签入记录

img

李天赐:今日为全量代码审查与联调验收清单产出,无签入。

六、运行截图

新建记录联调验证(杨俊鑫 · 模拟器 + Database Inspector,两张)

img

img

status_log / access_log 真机数据(胡昊 · 4 次迁移全部留痕,record.status 同步)

img

Day5 测试结果(胡昊 · 176 JVM 单测 + 16 真机测试 + 2 个 SQL 验收脚本)

img

Day5 测试执行结果图(陈瀚楷 · run=27 / 通过 22 / 失败 5)

img

缺陷探针明细图(陈瀚楷 · D-01~D-05)

img

  • 说明:陈志 G1 为服务契约与纯逻辑开发,无界面改动(以 144 条全量单测与 assembleDebug 通过为证);李天赐的用例 3/4 模拟器截图 Day6 补。

七、明日计划

  • 全员:I1 闭环联调(注册→登录→新建→详情→改状态);吴军峰:F2 状态流转 UI(调 StatusService.changeStatus);陈志:DateRepo 接入(userId 隔离 + 节点 CRUD + E_NODE_LIMIT/E_NOT_FOUND);陈瀚楷:D-01 优先修复回归 + D-02/D-03 一并 + T6 骨架;李天赐:按验收清单跑 6 个登录锁用例拿真截图;胡昊:配合联调与回归;黄炫文:CI 修复重跑 + Day6 随笔 + 冲刺总结材料。
  • 明日燃尽目标:计划剩余 52 点(实际已领先至 32)。
...全文

相关推荐

产教融合实训基地与实践中心建设逻辑图-可编辑版

产教融合实训基地与实践中心建设逻辑图-可编辑版

龙猫与奥特曼

idea2025-free.zip

idea2025-free.zip

qq_45190508

sop基于灵敏度分析的有源配电网智能软开关优化配置升级1(Matlab代码实现)

内容概要:本文提出了一种基于灵敏度分析的有源配电网智能软开关(SOP)优化配置方法,旨在应对高比例分布式电源接入带来的电压波动与网络损耗加剧等问题。研究以IEEE33节点系统为算例,通过改进的灵敏度分析模型量化各节点对电压和功率流动的影响程度,进而构建SOP选址与定容的优化模型,实现降低网损、改善电压分布及提升系统运行灵活性的目标。全文详细阐述了灵敏度指标的数学推导、目标函数与约束条件的建模过程,并基于Matlab实现了完整的仿真求解流程,具备良好的工程实用性与学术参考价值。; 适合人群:电力系统及其自动化、电气工程等相关专业的硕士博士研究生、科研机构研究人员,以及从事智能配电网规划、运行与优化的工程技术人员。; 使用场景及目标:①研究分布式电源大规模接入背景下配电网的主动调控与优化策略;②指导智能软开关在实际配电网中的科学选址与容量配置;③为相关科研课题提供可复现的仿真案例,支撑学术论文撰写与算法验证。; 阅读建议:建议读者结合提供的Matlab代码与IEEE33节点标准模型进行动手实践,重点理解灵敏度指标的物理意义及其在优化模型中的应用逻辑,关注求解过程中的约束设置与算法收敛性,并可进一步拓展至SOP与储能联合配置、多时间尺度优化等复杂场景进行二次开发与研究。

荔枝科研社

Ubuntu安装Latex

关于Ubuntu安装Latex的详细记录和排错指南

Leers Ting

高校技术转移办公室人员在成果转化过程中,如何实现科技成果与产业需求的高效对接?.docx

高校技术转移办公室人员在成果转化过程中,如何实现科技成果与产业需求的高效对接?

BIZKEEN
评论
收藏 已收藏
分享
返回顶部