我们拒绝平庸,拒绝随波逐流,拒绝墨守成规,让梦想不再流浪。
简单设计
上一篇 /
下一篇 2014-05-28 10:45:52
/ 个人分类:总结
简单设计 | |
等级3 | | 3级:即时设计 | | 1、设计文档包括哪些文档? 2、设计文档怎么写出来的?哪些人参与? 3、那个文档对开发的指导性较强?怎么指导开发? 4、会不会出现后面设计变动较大的情况? 5、设计需要更改的时候怎么处理?描述一下场景 6、什么时候进行重构?重构的频率是什么样子的? 7、重构有哪些具体实践?是否代码优化? 8、如何保证重构的正确性? 9、描述一下重构是怎么做的 10、什么工具辅助重构? 11、接口、数据结构的演进怎么做的? 12、架构如何演进,是SE决定还是与大家讨论? |
| 查检项 | 满足? |
参照标准 | 高级技术风险降低。足够的技术能力和实践支撑,做够用就好的设计,YAGNI文化,关注简单性;可工作、交流、无重复、尽量少的晦涩片段。 | |
6.3.1 | 能够支持小粒度的设计开发 | √ |
6.3.2 | 设计过程不是一撮而就,而是从简单到复杂的循序渐进的过程 | √ |
6.3.3 | 经过简单设计之后的组件能够持续和高质量小粒度交付 | X |
满足 简单设计 - 等级 3? | 小粒度设计开发,高级技术风险降低,关注内部? | X |
等级2 | | 2级:成熟的重构 | |
| 查检项 | 满足? |
参照标准 | 有效的技术风险降低。重构有测试保障,开发人员有意识的,自觉地进行重构,持续改善代码质量。 | |
6.2.1 | 重构思想成熟,有重构计划和技能支撑该活动 | X |
6.2.2 | 有效地应用设计模式;支持重构的测试实践。 | | X |
满足 简单设计 - 等级 2? | 成熟的重构,有效的技术风险降低? | X |
等级1 | | 1级:引入重构 | |
| 查检项 | 满足? |
参照标准 | 具有开发时降低技术风险的操作。开发人员了解面向对象设计、重构,关注技术债务;但是存在无纪律的重构,重构不充分 | |
6.1.1 | 有重视思想,但没有很好的重构计划和技能 | √ |
满足 简单设计 - 等级 1? | 无成熟的重构技能,但有技术风险降低雏形? | √ |
等级0 | | 0级:即兴设计 | |
| 查检项 | 满足? |
参照标准 | 忽视技术风险,应激性设计(工作即可),缺少代码质量意识,积累技术债务。开发人员对面向对象设计、重构等技术不了解。 | |
6.0.1 | 被动接受重构任务,简单的认为是代码优化 | X |
6.0.2 | 只完成功能实现,不考虑代码可扩展性、可复用性 | X |
满足 简单设计 - 等级 0? | 拼凑临时设计? | √ |
等级-1 | | —1级:大规模预先设计 | |
| 查检项 | 满足? |
参照标准 | 预先假想几乎所有技术风险,花费大量精力预先设计框架,开发由文档指导,代码脆弱、高耦合,维护成本高 | |
6.-1.1 | 设计过程期望大而全 | X |
6.-1.2 | 开发人员通过文档了解架构 | X |
6.-1.3 | 开发人员不能对架构提供输入 | X |
满足 简单设计 - 等级 -1? | 预先假想所有技术风险? | √ |
| | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | |
收藏
举报
TAG: