|
|
<execution>
|
|
|
<constraint>
|
|
|
## 技术约束条件
|
|
|
- **Qt版本限制**：必须兼容Qt 5.15，不能使用更高版本特性
|
|
|
- **C++标准**：遵循C++17标准，避免使用实验性特性
|
|
|
- **平台兼容性**：确保跨平台兼容性，支持Windows/Linux/macOS
|
|
|
- **构建系统**：基于qmake构建系统，保持.pro文件兼容性
|
|
|
- **现有功能**：优化过程中不能破坏现有功能
|
|
|
- **渐进式改进**：避免大规模重构，采用小步快跑策略
|
|
|
</constraint>
|
|
|
|
|
|
<rule>
|
|
|
## 强制执行规则
|
|
|
- **代码规范强制**：严格遵循Qt Coding Style或Google C++ Style Guide
|
|
|
- **向后兼容性**：所有改进必须保持向后兼容
|
|
|
- **测试验证**：每个改进都必须经过测试验证
|
|
|
- **文档同步**：代码改进必须同步更新相关文档
|
|
|
- **版本控制**：所有改动必须有清晰的提交记录
|
|
|
- **安全优先**：安全相关问题必须优先处理
|
|
|
</rule>
|
|
|
|
|
|
<guideline>
|
|
|
## 优化指导原则
|
|
|
- **质量优先**：优先解决影响代码质量的核心问题
|
|
|
- **学术导向**：优化方案要体现学术价值和技术深度
|
|
|
- **实用性平衡**：在理论完美与实际可行之间找到平衡
|
|
|
- **可维护性**：优化后的代码应该更容易维护和扩展
|
|
|
- **性能考虑**：在不影响可读性的前提下优化性能
|
|
|
- **最佳实践**：积极应用行业最佳实践和设计模式
|
|
|
</guideline>
|
|
|
|
|
|
<process>
|
|
|
## Qt代码优化执行流程
|
|
|
|
|
|
### Phase 1: 项目分析阶段 (1-2天)
|
|
|
```mermaid
|
|
|
flowchart TD
|
|
|
A[项目概览] --> B[文件结构分析]
|
|
|
B --> C[依赖关系梳理]
|
|
|
C --> D[功能模块识别]
|
|
|
D --> E[质量基线建立]
|
|
|
E --> F[问题清单生成]
|
|
|
```
|
|
|
|
|
|
**具体执行步骤**：
|
|
|
1. **项目结构扫描**
|
|
|
- 分析目录组织结构
|
|
|
- 检查文件命名规范
|
|
|
- 识别模块划分情况
|
|
|
|
|
|
2. **代码质量基线**
|
|
|
- 运行静态分析工具
|
|
|
- 统计代码复杂度指标
|
|
|
- 评估测试覆盖率
|
|
|
|
|
|
3. **Qt特性审查**
|
|
|
- 检查信号槽使用情况
|
|
|
- 分析UI组件组织
|
|
|
- 评估资源文件管理
|
|
|
|
|
|
### Phase 2: 优化方案设计 (2-3天)
|
|
|
```mermaid
|
|
|
graph TD
|
|
|
A[问题分类] --> B{优先级评估}
|
|
|
B -->|High| C[Critical修复方案]
|
|
|
B -->|Medium| D[Major改进方案]
|
|
|
B -->|Low| E[Minor优化方案]
|
|
|
C --> F[方案可行性评估]
|
|
|
D --> F
|
|
|
E --> F
|
|
|
F --> G[实施计划制定]
|
|
|
```
|
|
|
|
|
|
**优化方案类型**：
|
|
|
- **结构重组**：目录结构、文件组织、模块划分
|
|
|
- **代码重构**：类设计、函数拆分、接口优化
|
|
|
- **规范统一**：命名规范、代码风格、注释标准
|
|
|
- **性能优化**：算法改进、内存优化、资源管理
|
|
|
- **文档完善**：API文档、架构说明、使用指南
|
|
|
|
|
|
### Phase 3: 渐进式实施 (5-7天)
|
|
|
```mermaid
|
|
|
gantt
|
|
|
title Qt代码优化实施计划
|
|
|
dateFormat YYYY-MM-DD
|
|
|
section 结构优化
|
|
|
目录重组 :done, struct1, 2024-01-01, 1d
|
|
|
文件重命名 :done, struct2, after struct1, 1d
|
|
|
section 代码重构
|
|
|
类设计优化 :active, refactor1, 2024-01-03, 2d
|
|
|
函数重构 :refactor2, after refactor1, 2d
|
|
|
section 规范统一
|
|
|
命名规范化 :style1, 2024-01-07, 1d
|
|
|
注释完善 :style2, after style1, 1d
|
|
|
section 文档完善
|
|
|
API文档 :doc1, 2024-01-09, 1d
|
|
|
架构文档 :doc2, after doc1, 1d
|
|
|
```
|
|
|
|
|
|
**实施原则**：
|
|
|
- **小批量提交**：每次改动控制在合理范围内
|
|
|
- **功能验证**：每个阶段完成后进行功能测试
|
|
|
- **回滚准备**：为每个重要改动准备回滚方案
|
|
|
- **进度跟踪**：定期评估进度和质量改进效果
|
|
|
|
|
|
### Phase 4: 质量验证 (1-2天)
|
|
|
```mermaid
|
|
|
flowchart LR
|
|
|
A[代码审查] --> B[静态分析]
|
|
|
B --> C[功能测试]
|
|
|
C --> D[性能测试]
|
|
|
D --> E[文档检查]
|
|
|
E --> F[质量报告]
|
|
|
```
|
|
|
|
|
|
**验证标准**：
|
|
|
- **功能完整性**：所有原有功能正常工作
|
|
|
- **代码质量**：静态分析工具无Critical问题
|
|
|
- **性能指标**：性能不低于优化前水平
|
|
|
- **文档完整**：关键模块有完整文档
|
|
|
- **规范符合**：代码风格符合选定标准
|
|
|
</process>
|
|
|
|
|
|
<criteria>
|
|
|
## 优化质量评价标准
|
|
|
|
|
|
### 技术质量指标
|
|
|
- ✅ **代码规范符合率** ≥ 95%
|
|
|
- ✅ **静态分析问题** Critical = 0, Major ≤ 5
|
|
|
- ✅ **代码复杂度** 平均圈复杂度 ≤ 10
|
|
|
- ✅ **注释覆盖率** 公共接口 ≥ 90%
|
|
|
- ✅ **文档完整性** 核心模块文档覆盖率 ≥ 80%
|
|
|
|
|
|
### 学术价值指标
|
|
|
- ✅ **设计模式应用** 至少应用3种经典设计模式
|
|
|
- ✅ **最佳实践体现** 体现Qt和C++最佳实践
|
|
|
- ✅ **技术创新点** 至少有2个技术亮点
|
|
|
- ✅ **工程规范性** 符合工业级开发标准
|
|
|
- ✅ **可维护性提升** 代码可维护性指数提升30%以上
|
|
|
|
|
|
### 实施效果评估
|
|
|
- ✅ **功能完整性** 所有原有功能100%保持
|
|
|
- ✅ **性能影响** 性能不降低，优化项目性能提升
|
|
|
- ✅ **开发效率** 后续开发和维护效率提升
|
|
|
- ✅ **学习价值** 代码具有良好的学习和参考价值
|
|
|
- ✅ **导师认可** 获得导师和评审专家的积极评价
|
|
|
</criteria>
|
|
|
</execution>
|
