标签：方法 而不是 成本 管理员 inf 使用 磁盘空间 资料 失败
第八章 注重实效的项目
随着你的项目开动，我们需要从个体的哲学和编码问题转向讨论更大的、项目级的问题。我们将不深入项目管理的具体细节，而是要讨论能使项目成功或失败的几个关键区域。
1. 注重实效的团队
书中前面的内容都是帮助个体成为更好的程序员，这些方法在对团队来说仍然有效。
a) 不要留破窗户。质量是一个团队的问题。最勤勉的开发者如果被派到不在乎质量的团队里，也会发现自己很难保持修正琐碎问题所需的热情。团队作为一个整体，不应该容忍破窗户——那些小小的、无人修正的不完美。
b) 煮青蛙。在项目开发高涨的热度里，很难再用一只眼睛注意周围的环境，所以作为整体的团队甚至更容易被煮熟。即使是目的最明确的团队对项目中的重大改动可能也会很健忘。团队每个人都应该主动监视环境的变化，也可以指定专人负责检查范围的扩大、时间标度的缩减、新增特性、新环境之类任何不在最初约定中的东西。
c) 交流。对外界而言，沉闷寡言、文档混乱的团队是糟糕的团队。而杰出的团队有着截然不同的个性，他们制作的文档准确、一致，团队用一个声音说话，甚至还可能有幽默感。可以使用一个营销的诀窍，来帮助团队作为整体与外界交流：创立品牌。在启动项目时，给它取一个不寻常的名字，这会给团队一个用于建设的身份标识。
d) DRY。交流有助于消除团队间的重复，此外可以安排项目成员分工担任项目不同部分的资料管理员（比如数据库schema、日期处理等）。
e) 正交性。要围绕功能、而不是工作职务组织小团队，这些小团队分别负责最终系统的特定方面的功能，每个团队都按照他们约定的承诺，对项目中的其他团队负有责任。这种分组方式能够极大地减少各个开发者的工作之间的相互影响。但是这种方法只有在项目拥有负责的开发者、以及强有力的项目管理时才会有效。
f) 自动化。自动化可以确保团队所做的每件事情一致、准确。编辑器为代码自动布局、夜间自动构建测试，这些都是很好地方式。自动化是每个项目团队的必要组成部分。
g) 知道何时停止绘画。团队由个体组成，要给他们足够的能够闪亮的空间，以支持他们，同时要把握足够好的软件，抵抗不断画下去的诱惑，确保项目的交付能够符合需求。
2. 无情的测试
a) 早测试、常测试，自动测试。寻找bug有点像是用网捕鱼。我们用纤小的网（单元测试）捕捉小鱼，用粗大的网（集成测试）来捕捉大鱼。有时鱼会设法逃跑，所以为了抓住在我们项目池塘里游动的、越来越狡猾的缺陷，要补上我们发现的任何漏洞。
与手动执行的测试计划相比，随每次构建运行的测试要有效的多。
Bug发现得越早，进行修补的成本就越低。要“编一点，测一点”，在编写产品代码的同时编写测试代码。
只有通过全部测试，编码才算完成。好的项目拥有的测试代码可能比产品代码还要多。但编写这些测试代码所花的时间是值得的。长远来看，它最后会便宜得多，而你有希望制作出接近零缺陷的产品。此外，通过了所有测试将给你高度的自信：一段代码已经“完成”了。
项目范围测试的三个方面：测试什么、怎样测试、何时测试
b) 测试什么
单元测试，这是所有其它形式测试的基础。所有模块都必须通过单元测试，才能继续前进。
集成测试，用来验证项目的主要子系统能否工作，并很好地协同。是单元测试的一种扩展，测试整个子系统是否遵守其合约。
验证和校验。就算没有bug，但回答的问题本身是错误的，这样的系统也不会有用。需要校验回答一个重要的问题是：这是用户需要的吗？要注意用户的访问模式与开发者所用测试数据的不同。
资源耗尽、错误及恢复。虽然在理想的条件下软件会正常运行，但在现实运行环境下，还有内存、磁盘空间、CPU带宽、网络带宽、屏幕分辨率等种种限制。
性能测试、压力测试或负载测试有时也很有必要，要测试软件能够满足现实条件下的性能需求，如预期的用户数、连接数、每秒事务数、可伸缩性。有时需要用专门模拟现实环境进行测试。
可用性测试。可用性测试是由真正的用户、在真实的环境条件下进行的。软件最好能像是手的延伸一样顺手。可用性测试也要尽早进行，以保证有时间更正，否则没能满足可用性标准就像是除零错误，是重大bug。
c) 怎样测试
回归测试，把当前测试的输出与先前或已知的值进行对比，以确定今天对bug的修复没有破坏昨天可以工作的代码。性能、合约、有效性能等都可以进行回归测试。
测试数据。数据分为两种，现实世界的数据和合成的数据。
现实世界的数据代表典型的用户数据，有助于揭示出需求分析中的缺陷和误解。
合成数据在需要大量数据、需要测试边界条件、展示特定统计属性时很有用。
演练GUI系统。对于涉及到GUI的部分，你的设计应该足够地解耦，以使你无需使用GUI就能对应用逻辑进行测试。从这一点来看，Winform那种界面与代码的组合方式是不好的。
彻底测试。衡量测试的覆盖率不能单单只从代码行的覆盖情况，尤其是对于循环、迭代之类的代码。重要的是程序可能具有的状态数。而且即使具有良好的代码覆盖，测试数据、遍历代码的次序对结果也有重大影响。
d) 何时进行测试。任何产品代码一旦存在，就需要进行测试。大多数测试应该自动完成，并尽可能地频繁测试，
e) 一个bug只抓一次。bug一旦被发现，就应该是最后一次被发现，应该对自动化测试进行修改，从此每次都检查那个特定的bug，不存在例外，不要觉得它不会再次发生。
标签：方法 而不是 成本 管理员 inf 使用 磁盘空间 资料 失败
原文地址：http://www.cnblogs.com/zhixin9001/p/6822409.html
