版权声明：欢迎转载，请注明沉默王二原创。 https://blog.csdn.net/qing_gee/article/details/43030569
- 关注质量就是提高生产力的最佳途径。
- 如果你看到失败的乌云已经出现在地平线时，就退回到项目的前期工作吧。
- 准备工作的中心目标就是降低风险。
- 方法论应该选用最好最新的，我主要想说的是，在工作的过程中一定要抓住方向。诸如今天我测试网络通信时，就犯了严重的导向性错误，我用我本地的客户端访问我本地的服务测试客户端到服务端的通信速度，这显然是错误的。
- 现实当中，很多管理层或者决策人员往往冷漠做前期准备的程序员，这让人难受。那么如果你遇上这样的领导，如果你足够的有钱，足够的觉得公司不适合自己，那么就跳槽吧，假如没有这么糟糕，那么他询问你现在是否在coding，而你却在做需求分析，那么你就忽悠他吧，尽早交付有质量的项目才是最重要的，至于领导，就无视他吧。
- 架构师吃掉需求，设计师吃掉架构，而程序员消化设计。这样就会出现，假如架构师把需求吃错了，那么最终受害者是最无辜的程序员，如何规避这个问题，就是提高架构师的生产力。
- 发现错误的时间要尽可能接近引入错误的时间，这句话的意思就是尽早发现问题，不要把问题拖到产品交付，那么修复的成本就不可估量。
- 在进行开发之前，问问自己，“我已经非常详细的研究了需求和设计，我想不出在编码和调试阶段还会有什么问题”，无论是敏捷开发还是瀑布开发，必要的前期准备是需要的。
- 很多时候，找不到问题是最痛苦的。事实证明，大多数情况下，解决掉log日志中的问题，难度远远低于那些没有被log日志捕获的问题，有时候看着没有报错的日志找问题，我都痛苦的无法言喻。
- 需求像水，如果冻结了，就容易在上面建设。
- 圣杯的含义：有两个方面，一个是代表众人追求的最高目标，二另外一个则暗示希望渺茫。
- 假如客户非要进行需求变更时，那么就把进度和成本两个关键字告诉他吧。
- 功能需求分析checklist：
- 是否详细定义了系统的全部输入
- 输出
- 定义了输出格式
- 定义了硬件和软件的外部接口
- 外部通信接口
- 列出用户想要做的全部事情
- 是否详细定义了每个人物的数据
- 非功能需求checklist：
- 是否为全部必要的操作，从用户的视角，详细描述了期望响应时间
- 是否详细描述了其他与计时有关的考虑
- 安全级别
- 可靠性
- 定义了机器内存和磁盘空间
- 系统的可维护性
- 成功和失败的定义
- 需求的质量
- 需求是用户的语言书写的吗
- 每条需求与其他需求冲突吗
- 详细定义了相互竞争的特性
- 避免在需求中规定设计
- 在详细程度上保持相当一致的水平
- 需求是否描述清楚，开发者能够这样想吗
- 每个条款都有解决方案吗
- 是否每个需求都是可测试的
- 描述所有对需求的改动
- 架构的主题
- 程序的整体组织结构是否清晰
- 明确主要的构造块
- 涵盖需求中列出的功能
- 论证数据设计
- 详细定义数据库的组织结构和内容
- 指出所有关键的业务规则
- 描述了用户界面设计的策略
- 用户界面模块化
- 论证处理IO的策略
- 是否估算了稀缺资源（线程、数据库连接）
- 安全需求
- 为每个类、系统描述时间预算
- 可伸缩性
- 操作性
- 国际化和本地化策略
- 有 容错的办法
- 离开了良好的软件架构，可能瞄准了正确的问题，但是却使用了错误的解决方案。
- 如果不能向一个六岁的孩子解释某件事，那么说明你真的没有理解这件事。
- 精心设计的用户界面架构决定了最终做出来的程序是“人见人爱”还是没有要用。
- 在软件开发中，如果你的技术还满足不了你未来的使用能力，那么请购买一个或者使用开源的框架。
- 软件开发中缺乏像建筑真正付诸使用泥瓦钢铁建立之前已经让工程师费劲心思构架好蓝图，很多时候我们都过于急功近利，我们的coding往往不是建立在有效的需求分析之上，好悲哀啊。
