lxy/u-desk
Private
Public Access
1
0
Fork 0
Code Activity
Files
8c577f70e73bdff2ce5cde77349fade82f58b14d
u-desk/docs/work-plan.md

11 KiB
Raw Blame History

Go Desk 项目 - 多角度审视与工作计划

生成时间: 2026-01-26 项目状态: 功能开发阶段，存在技术债务 当前代码量: 2590 行（重复率 59.7%）

🎭 各角色角度审视

1️⃣ UX设计师视角

✅ 做得好的地方

  • 紧凑工具栏设计：48px高度，功能集中，符合Fitts定律
  • 渐进式披露：收藏夹、历史记录按需显示
  • 视觉一致性：统一的间距、字体、圆角规范
  • 交互反馈：拖拽时有清晰的视觉提示（hover、cursor变化）

❌ 存在的问题

  1. 交互模式不一致

    • DeviceTest.vue：使用 a-card + a-row 布局（旧设计）
    • FileSystem.vue：使用自定义工具栏 + 侧边栏（新设计）
    • 用户困惑：两个"文件管理"功能，操作方式完全不同

  2. 功能发现率低

    • 侧边栏默认隐藏，用户可能不知道有收藏功能
    • 没有视觉提示引导用户发现高级功能

  3. 缺少空状态引导

    • 首次使用时没有引导流程
    • 空文件夹的提示不够友好

💡 UX改进建议

  • 统一交互模式：将 FileSystem.vue 的新设计应用到 DeviceTest.vue
  • 添加首次引导：简单的tooltip或empty state引导
  • 侧边栏记忆：记住用户是否打开了侧边栏
  • 统一操作反馈：所有成功操作使用一致的动画效果

2️⃣ CTO视角

❌ 技术债务问题（严重）

  1. 代码重复率 59.7%

    • 439 行重复代码
    • 违反DRY原则，维护成本x2

  2. 缺少架构分层

    • 没有统一的业务逻辑层
    • 组件直接调用API，缺少抽象
    • 状态管理散乱（localStorage到处都是）

  3. 可测试性差

    • 没有单元测试
    • 业务逻辑耦合在组件中，无法单独测试
    • 缺少类型定义，运行时错误风险高

  4. 过度设计

    • FileSystem.vue（1374行）职责过多
    • 媒体预览功能可以独立成服务
    • 拖拽逻辑应该抽象为通用composable

✅ 技术亮点

  • API调用方式统一（有良好的基础）
  • 错误处理模式一致
  • 使用了现代Vue3 Composition API

💡 架构改进建议

  • 紧急：建立composables抽象层（减少60%重复代码）
  • 本周：统一localStorage键名管理
  • 本月：引入TypeScript类型定义
  • 下月：建立单元测试体系（目标70%覆盖率）

3️⃣ 程序员视角

😵 当前的痛点

  1. 改一个功能要改两个地方

    // 例如：修改收藏功能
DeviceTest.vue: toggleFavorite()    // 要改这里
FileSystem.vue: toggleFavorite()   // 还要改这里

  2. FileSystem.vue太复杂

    • 1374行，34个函数
    • 状态变量15+个，难以追踪
    • 添加新功能时容易引入bug

  3. 缺少类型提示

    • fileList.value 的数据结构不明确
    • 函数参数没有类型检查
    • 只能靠运行时测试发现错误

  4. 调试困难

    • 没有日志系统
    • 错误堆栈难以追踪
    • localStorage操作失败时静默失败

💡 开发体验改进

  • 立即：抽取公共composables（useFileOperations, useFavoriteFiles）
  • 本周：添加ESLint规则，强制统一代码风格
  • 本月：引入Vitest + TypeScript
  • 长期：建立错误监控和日志系统

4️⃣ 用户视角

✅ 功能完整性

  • ✅ 历史记录（方便回溯）
  • ✅ 收藏夹（快速访问）
  • ✅ 拖拽调整（灵活布局）
  • ✅ 文件预览（图片、视频、PDF）
  • ✅ 点击即打开（流畅操作）

⚠️ 用户困惑点

  1. 两个入口做什么？

    • "文件管理"和"设备调用测试"都能操作文件
    • 功能重复，不知道该用哪个

  2. 收藏的文件在哪里？

    • 侧边栏默认隐藏
    • 没有明确提示

  3. 为什么有些操作不一样？

    • DeviceTest.vue：列出目录后要手动点文件名
    • FileSystem.vue：点击即打开

💡 用户价值优化

  • 合并入口：只保留一个"文件管理"入口
  • 简化操作：统一"点击即打开"的交互模式
  • 功能提示：首次使用时显示功能引导
  • 键盘快捷键：常用操作添加快捷键支持

5️⃣ 产品经理视角

📊 当前状态评估

  • 功能完成度: 90% （核心功能都有）
  • 用户体验: 70% （有用但不精致）
  • 技术健康度: 50% （存在严重技术债务）
  • 市场竞争力: 65% （功能完整但体验一般）

💰 成本分析

  • 重复功能开发成本: 高（两个相似的文件管理页面）
  • 维护成本: 高（改一个功能要改两个地方）
  • bug率: 中等（代码重复导致同步问题）
  • 新增功能成本: 高（缺少公共抽象，每次都从零开始）

🎯 产品策略建议

  • 短期：合并重复功能，统一用户体验
  • 中期：偿还技术债务，提升开发效率
  • 长期：建立差异化功能（如：批量操作、文件搜索、同步功能）

📋 综合工作计划

基于以上分析，制定以下分阶段工作计划：

🚀 第一阶段：偿还技术债务（Week 1-2）

优先级: 🔴 紧急 目标: 减少代码重复，建立公共抽象层

Week 1: 创建公共 Composables

Day 1-2: 核心 Composables

src/composables/
├── useFileOperations.js     # 文件操作逻辑（2h）
├── useFavoriteFiles.js      # 收藏功能（1.5h）
├── usePathHistory.js        # 历史记录（1h）
└── useLocalStorage.js       # localStorage封装（1.5h)

验收标准:

  • Composables有完整的TypeScript类型定义
  • 单元测试覆盖率>80%
  • DeviceTest和FileSystem都使用这些composables

Day 3-4: 工具函数和常量

src/utils/
├── fileUtils.js             # formatBytes, getFileIcon等（1h）
└── constants.js             # STORAGE_KEYS, FILE_EXTENSIONS（1h）

src/composables/
└── useResizable.js          # 拖拽调整逻辑（1h）

验收标准:

  • 所有常量统一管理
  • 文件类型判断逻辑只有一处
  • 工具函数有单元测试

Week 2: 重构组件

Day 1-2: 重构 DeviceTest.vue

  • 使用新的composables替换内联逻辑
  • 简化模板代码
  • 保持功能不变

预期效果: 738行 → 300行（减少59%）

Day 3-4: 重构 FileSystem.vue

  • 使用新的composables
  • 抽取FilePreviewer组件
  • 简化媒体预览逻辑

预期效果: 1374行 → 500行（减少64%）

Day 5: 回归测试

  • 手动测试所有功能
  • 修复重构引入的bug
  • 更新文档

🎨 第二阶段：统一用户体验（Week 3-4）

优先级: 🟡 高 目标: 统一交互模式，提升用户体验

Week 3: 统一交互设计

Day 1-2: 统一布局结构

  • DeviceTest.vue采用FileSystem.vue的工具栏设计
  • 两个页面使用相同的文件列表组件
  • 统一拖拽交互

Day 3-4: 优化用户体验

  • 添加首次使用引导
  • 优化空状态提示
  • 添加loading骨架屏
  • 统一成功/失败提示

Week 4: 功能整合

Day 1-2: 合并重复入口

  • 讨论：是否合并"文件管理"和"设备调用测试"
  • 如果合并：决定保留哪个，迁移功能
  • 如果不合并：明确两者定位差异

Day 3-4: 功能增强

  • 添加键盘快捷键
  • 批量操作功能
  • 文件搜索功能
  • 操作历史撤销/重做

🧪 第三阶段：质量保障（Week 5-6）

优先级: 🟢 中 目标: 建立测试体系，提升代码质量

Week 5: 单元测试

Day 1-2: Composables测试

tests/composables/
├── useFileOperations.spec.js
├── useFavoriteFiles.spec.js
├── usePathHistory.spec.js
└── useLocalStorage.spec.js

目标: 覆盖率>80%

Day 3-4: 工具函数测试

tests/utils/
├── fileUtils.spec.js
└── constants.spec.js

Week 6: 集成测试和文档

Day 1-2: 组件测试

  • DeviceTest.vue快照测试
  • FileSystem.vue快照测试
  • 公共组件测试

Day 3-4: 文档和指南

  • 组件使用文档
  • Composables API文档
  • 贡献指南

🔮 第四阶段：性能优化（Week 7-8）

优先级: 🟢 中 目标: 优化性能，提升响应速度

Week 7: 性能优化

Day 1-2: 虚拟滚动

  • 大文件列表使用虚拟滚动
  • 图片懒加载

Day 3-4: 缓存优化

  • 文件列表缓存
  • 预览内容缓存
  • 路径解析缓存

Week 8: 高级功能

Day 1-2: 批量操作

  • 多选文件
  • 批量删除
  • 批量下载

Day 3-4: 搜索和过滤

  • 文件名搜索
  • 文件类型过滤
  • 大小过滤
  • 时间过滤

📊 优先级矩阵

根据影响力和紧急程度排序：

任务 影响力 紧急度 优先级 预计工时
抽取Composables 高 高 🔴 P0 16h
统一常量管理 高 高 🔴 P0 4h
重构DeviceTest.vue 高 高 🔴 P0 8h
重构FileSystem.vue 高 高 🔴 P0 12h
统一交互模式 中 高 🟡 P1 16h
单元测试 中 中 🟡 P1 16h
TypeScript迁移 高 低 🟢 P2 40h
性能优化 中 低 🟢 P2 16h
高级功能 中 低 🟢 P2 24h

🎯 成功指标

技术指标

  • 代码复用率: 40% → 80%
  • 代码行数: 2590 → 1500（减少42%）
  • 单元测试覆盖率: 0% → 70%
  • TypeScript覆盖率: 0% → 100%
  • 代码重复率: 59.7% → <10%

用户体验指标

  • 交互一致性: 两个页面操作方式100%一致
  • 功能发现率: 核心功能发现率>90%
  • 首屏加载: <1s
  • 操作响应: <200ms

开发效率指标

  • 新增功能时间: 减少60%
  • Bug修复时间: 减少50%
  • 代码审查时间: 减少40%

💡 立即行动（今天/明天）

今天可以做的（2-3小时）

  1. ✅ 创建 src/utils/constants.js（30min）

    • 统一STORAGE_KEYS管理
    • 统一FILE_EXTENSIONS定义

  2. ✅ 创建 src/utils/fileUtils.js（1h）

    • formatBytes
    • getFileName
    • getFileIcon（简化版）

  3. ✅ 重构DeviceTest.vue使用新工具函数（1h）

    • 导入新的utils
    • 删除重复代码
    • 测试功能

明天可以做的（4-6小时）

  1. ✅ 创建 src/composables/useLocalStorage.js（1.5h）

    • 封装localStorage操作
    • 添加类型定义

  2. ✅ 创建 src/composables/useFileOperations.js（2.5h）

    • 封装文件操作逻辑
    • 添加错误处理

  3. ✅ 重构DeviceTest.vue使用composables（2h）

    • 替换内联逻辑
    • 测试功能

📝 总结

当前问题

  1. ❌ 代码重复率59.7%
  2. ❌ 缺少公共抽象
  3. ❌ 交互模式不一致
  4. ❌ 缺少类型和测试

改进方向

  1. ✅ 建立composables抽象层
  2. ✅ 统一用户体验
  3. ✅ 建立测试体系
  4. ✅ 引入TypeScript

预期收益

  • 代码减少42%
  • 开发效率提升60%
  • 维护成本降低50%
  • 用户满意度提升30%

下一步: 从"立即行动"开始，今天就迈出第一步！💪

View Git Blame Copy Permalink