提问回顾
提问回顾
以前问的问题
- 个人开发流程里面的PSP表格中，开发阶段发现没有程序优化这一项，但是开发过程中程序的优化感觉上是必不可少的一部分，那么为什么PSP表格所描述的个人开发流程中没有优化这一项呢？
优化可以认为是下一轮迭代的一个需求，从而是另一轮的设计、编码阶段，而PSP表格主要描述的是一轮迭代下的各个工作的占比等信息，所以是没有必要特意留出优化这一项。
- 用户需求总是变化的，那么写软件的时候需要预测用户的需求变化吗？这样会不会属于过早优化?
可以使用敏捷开发的思路，通过快速迭代来适应不断变化的需求，所以写软件的时候并不用也不要去预测用户的需求变化，而是尽可能快的去实现需求。是属于过早优化的。
- 感觉书中对于变量名的要求过于苛刻，一些不必要的修饰词也算是代码风格的一种，也并不影响人们阅读，那么我们为什么不去接受这种代码风格呢？
在多人开发过程中，严格的代码规范可以避免一些没有必要的合并问题，并在不同人的认知上也能够得到统一，是好处多于坏处的。
- 书中提到类似飞机安全功能是必要的。对于软件的安全功能上，有没有一个方法能够比较全面的找到这些安全功能的必要性，来指导软件开发？
目前还是没有看到，但可以通过敏捷的快速迭代更新来补全安全功能。
- 现在编程越来越普及，软件工程方法会不会也一起流行起来？
现在来看这是必然的趋势，随着软件规模的越来越大，以后每个人都需要学习一些软件工程方法来进行开发管理等。
请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。
- 需求：必须写成一个详实的需求文档
- 设计：需求转设计需要给出完整的技术设计文档，包括代码规定、软件架构设计、接口设计等等
- 实现：严格按照代码规定、接口规定等技术文档
- 测试：要有一个完整的测试计划，可以在设计阶段就提出来指导开发过程，避免问题在最后整合阶段一并出现
- 发布：发布阶段尽可能要早要快，可以先发布一个不太好的版本并根据用户意见快速修复问题。
- 维护：维护其实也是新一轮迭代的开始，在修复已有bug的基础上征集用户意见以备下一轮的迭代。
