项目管理之软件设计工作（下）

继上一篇文章：
!(项目管理之软件设计上)[https://www.jianshu.com/p/21d351781886]
讲解了关于软件设计的一些概念性知识，这篇文章，我将进一步分享跟总结软件设计工作的一些实用法则。

软件设计文档评审标准

例如下图示例：

上图中，检查单变成了通用的。这时候

• 通用的检查单是没有用的
• 最实用的方法是：

• 列出关键需求点。逐一求证设计、如何考虑
• 综合考虑以下因素，做出适当的取舍和平衡：
  -- 工期和预算限制
  -- 项目成员当前水平和潜力

• 设计决定了软件的工作量

• 设计文档评审流于形式就属于“浪费”时间，不熟悉需求去评审设计文档属于“扯蛋”
• 在设计时间上"节省"时间，代价就是将要花费数倍甚至数十倍以上的项目工作量。

软件设计法则

1、需求驱动设计

需求驱动设计是什么呢？

• 全部需求驱动架构设计
• 局部需求驱动模块设计
• 业务数据驱动数据库设计
• 业务流程、业务数据、业务目标驱动用户体验设计

2、不要误解"简单设计"

什么是简单设计呢？？在敏捷开发设计或者极限开发中也有一种说法叫简单设计。
就说以下两点：

1. 不要考虑太长远，仅考虑当前需求。
2. 用最简单直接地方法来实现。

上面说的简单设计的意思其实就是指让项目工作变得建安，而不是将设计的思考过程简单化。同时，软件设计是一种智力投资，多花一小时想清楚如何让项目工作变得更简单，会节省更多的项目时间。

（ps几个要点）

1. 重视设计
   2.修炼和提升
   3.集体的智慧

3、做高性价比的设计

在符合项目战略的情况下，用最少的工作量，来实现需求，这基本上就是"高性价比"的意思。

条件限制：
1.工期和预算成本。
2.项目成员能力

好处

• 项目的利润最大化
• 项目工作变得简单化
• 高性价比设计是挑战智力的工作，会让你的工作更加愉悦以及高质量，成就感。

4、人人都是软件设计师

1. 架构设计和数据库设计往往由富有经验的程序员负责的，其他项目成员参与学习和评审该设计。
2. 模块设计一般由将来负责该模块编码的程序员负责，架构设计来评审该设计。
3. 用户体验设计由测试工程师或实施工程师负责，程序员参与。

5、设计文档应该先己后人

这句话有点抽象，其实就是说，设计文档必须保证对项目组当前工作是有用的，要立马能用得上，而不是以后的要用，现在就写。

6、设计文档不应该局限word文档

案例分析： 无聊的数据库设计文档。
-- 建议的做法: 直接使用uml，或者在数据库设计。
-- 冲突： QA要求：不符合ISO的要求，必须写文档。。。

直接在数据库中设计的好处：

• 设计马上得到验证；
• 利用数据库特性做很多设计上的探索，设计会做的更好
• 设计完成的同时，数据库也建成了，节省工作量。

其实是指设计的形式可以有很多种，不一定要做word，选择什么方式对当前工作最优先，可以采用什么样的方式。

7、并不是所有的地方都需要设计文档

这条规则直接参考上一条，有些内容非常简单，是不需要设计文档的。

正常的做法:

1. 架构设计文档一般必不可少。

2. 数据库设计文档一般也不可缺。

3. 并不是所有的模块，都需要写设计文档:
   一般在以下几种情况需要：

4. 算法比较复杂

5. 想法暂时不是很成熟

6. 负责该模块的程序员是新人。

7. 用户体验的设计文档一般也不可缺。

8、"编码即设计"是最合适的，但烂代码除外

• 好的编码既设计

• 仅有必要的设计文档
• 代码中有适量的注释
• 代码条理清晰，结构严谨。

• 训练程序员良好的编程习惯
• 代码就是设计

• 有时候程序员写不出设计文档，也可以直接编码。

• Demo就是设计

• 设计逻辑复杂、算法复杂、需要技术攻关，Demo才是最好和最直接的设计！