继上一篇文章：
!(项目管理之软件设计上)[//www.greatytc.com/p/21d351781886]
讲解了关于软件设计的一些概念性知识，这篇文章，我将进一步分享跟总结软件设计工作的一些实用法则。
软件设计文档评审标准
例如下图示例：
上图中，检查单变成了通用的。这时候
- 通用的检查单是没有用的
- 最实用的方法是：
- 列出关键需求点。逐一求证设计、如何考虑
- 综合考虑以下因素，做出适当的取舍和平衡：
-- 工期和预算限制
-- 项目成员当前水平和潜力
- 设计决定了软件的工作量
- 设计文档评审流于形式就属于“浪费”时间，不熟悉需求去评审设计文档属于“扯蛋”
- 在设计时间上"节省"时间，代价就是将要花费数倍甚至数十倍以上的项目工作量。
软件设计法则
1、需求驱动设计
需求驱动设计是什么呢？
- 全部需求驱动架构设计
- 局部需求驱动模块设计
- 业务数据驱动数据库设计
- 业务流程、业务数据、业务目标驱动用户体验设计
2、不要误解"简单设计"
什么是简单设计呢？？在敏捷开发设计或者极限开发中也有一种说法叫简单设计。
就说以下两点：
- 不要考虑太长远，仅考虑当前需求。
- 用最简单直接地方法来实现。
上面说的简单设计的意思其实就是指让项目工作变得建安，而不是将设计的思考过程简单化。同时，软件设计是一种智力投资，多花一小时想清楚如何让项目工作变得更简单，会节省更多的项目时间。
（ps几个要点）
- 重视设计
2.修炼和提升
3.集体的智慧
3、做高性价比的设计
在符合项目战略的情况下，用最少的工作量，来实现需求，这基本上就是"高性价比"的意思。
条件限制：
1.工期和预算成本。
2.项目成员能力
好处
- 项目的利润最大化
- 项目工作变得简单化
- 高性价比设计是挑战智力的工作，会让你的工作更加愉悦以及高质量，成就感。
4、人人都是软件设计师
- 架构设计和数据库设计往往由富有经验的程序员负责的，其他项目成员参与学习和评审该设计。
- 模块设计一般由将来负责该模块编码的程序员负责，架构设计来评审该设计。
- 用户体验设计由测试工程师或实施工程师负责，程序员参与。
5、设计文档应该先己后人
这句话有点抽象，其实就是说，设计文档必须保证对项目组当前工作是有用的，要立马能用得上，而不是以后的要用，现在就写。
6、设计文档不应该局限word文档
案例分析： 无聊的数据库设计文档。
-- 建议的做法: 直接使用uml，或者在数据库设计。
-- 冲突： QA要求：不符合ISO的要求，必须写文档。。。
直接在数据库中设计的好处：
- 设计马上得到验证；
- 利用数据库特性做很多设计上的探索，设计会做的更好
- 设计完成的同时，数据库也建成了，节省工作量。
其实是指设计的形式可以有很多种，不一定要做word，选择什么方式对当前工作最优先，可以采用什么样的方式。
7、并不是所有的地方都需要设计文档
这条规则直接参考上一条，有些内容非常简单，是不需要设计文档的。
正常的做法:
架构设计文档一般必不可少。
数据库设计文档一般也不可缺。
并不是所有的模块，都需要写设计文档:
一般在以下几种情况需要：算法比较复杂
想法暂时不是很成熟
负责该模块的程序员是新人。
用户体验的设计文档一般也不可缺。
8、"编码即设计"是最合适的，但烂代码除外
- 好的编码既设计
- 仅有必要的设计文档
- 代码中有适量的注释
- 代码条理清晰，结构严谨。
- 训练程序员良好的编程习惯
- 代码就是设计
- 有时候程序员写不出设计文档，也可以直接编码。
- Demo就是设计
- 设计逻辑复杂、算法复杂、需要技术攻关，Demo才是最好和最直接的设计！
