外包网站开发,wordpress新评论提醒,一站式网站建设方案,企业门户网站设计报告第八章 注重实效的项目 随着你的项目开动#xff0c;我们需要从个体的哲学和编码问题转向讨论更大的、项目级的问题。我们将不深入项目管理的具体细节#xff0c;而是要讨论能使项目成功或失败的几个关键区域。 1. 注重实效的团队 书中前面的内容都是帮助个体成为更好的程序员… 第八章 注重实效的项目 随着你的项目开动我们需要从个体的哲学和编码问题转向讨论更大的、项目级的问题。我们将不深入项目管理的具体细节而是要讨论能使项目成功或失败的几个关键区域。 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不存在例外不要觉得它不会再次发生。 转载于:https://www.cnblogs.com/zhixin9001/p/6822409.html
