最近看了<软件调试修改之道>,看到最后一章<反模式>,觉得虽然有些地方太理想化了,但还是很有借鉴作用的,因此决定记录下来,期间根据自己的体验做了一些修改.
1 混乱的缺陷优先级
既然我们优先解决最高优先级的,那么就有可能出现测试人员为了优先解决自己的缺陷而故意夸大优先级的情况
1.1 解决方案
定期对缺陷进行审查,确保缺陷的优先级确实能够反映出它们真正的优先级,并以此作为对测试人员的信用评价
写的越详细的描述,优先完成.(问题描述作为测试人员的成本,我们认为,越舍得花费成本的,其需求越高)
2 人员更替
经常由于预算或其他项目需求等原因而发生项目团队人员的更替. 然而人员更替往往存在交接双方旋接不上的问题.
而且若被交接人被迫要去修复交接人产生的缺陷时,也容易对士气产生影响
2.1 解决方案
任何人在仔细地完成当前工作之前,不允许任何人进入下一个任务.
采取自负自责的原则,谁造成了缺陷就由谁来修复它,即使他可能已经被分配到新的项目中了.
做好文档的工作.
3 将软件过程分成开发和维护两个阶段,由不同的团队维护
这容易造成以下缺陷:
由代码原始设计者/开发者修复缺陷实际上更加高效,而维护团队需要重新学习,降低效率
若开发者不负责维护,则他就无法知道他在开发时犯了什么错误,也就无法做出改进
维护团队往往得不到完整的知识来修复缺陷,因为软件很多知识都是隐性的
维护团队被沦为二级团队,容易打击士气
开发团队由于没有维护的压力,没有动力将软件做的尽善尽美
3.1 解决方案
从最初的构思到最终布局的整个过程乃至之后的维护都要让一个团队来完成,这样能够保持连续性,确保团队成员的工作重点与组织的工作重点紧密关联,并允许他们在软件的生产过程中学习如何维护软件.
4 救火模式
救火模式时一种行为模式,在这种模式中,面对很多关键问题,我们应接不暇地解决一个个严重问题
长期或反复地陷入救火模式会破坏代码质量和团队士气.
4.1 解决方案
如果发现自己陷入了救火模式,不妨退一步,先找出问题产生的根本原因,再去解决问题.
不要因为时间紧迫而只治标不治本,确保找出缺陷产生的真正原因并修复之. 不要将不理解的事情掩盖过去,而将之当作缺陷.
这意味着,你要承担一些短期的痛苦,以为长远打好坚实的基础.
5 重写
当面对一个麻烦的功能时,人们中有一种冲动丢弃现有的代码重新写新的代码.
从心理学的观点来看,开发新的代码比修改旧代码让人更舒服. 我们天生的乐观感是我们低估了复制旧功能所要付出的精力和时间.
然而,即使代码事实上没有很好的构建,没有很好的测试或者没有很好的记入文档,但它的大部分时间是在工作的. 这意味着,它含有与问题相关的大量知识,而这些知识不能从其他任何地方获得,除了这份源代码.
5.1 解决方案
对任何重写的建议都要报怀疑d态度. 进行以此非常细致的成本/收益分析. 有时旧的代码确实太烂,但应该花些时间来确认这一点.
若决定重写,为了尽可能减少风险. 试图寻找一个方法来增量地重写代码,而不是彻头彻尾地推到重来
对现有的代码进行测试,并验证得到了相同的结果. 要特别小心找出现有代码能正确处理和你需要重做的边界
6 代码权限不明晰
极限编程中的一个做法就是集体代码所有权,每个团队对所有代码都负有责任. 任何人都可以在任何地方修复任何缺陷而不必与原作者沟通.
然而极限编程中集体代码有效,是因为它由很多其他的极限编程方法的支持,比如结对编程,测试优先开发以及统一的编码标准.
如果没有极限编程的那些方法支持,采取集体代码所有权就很危险,容易沦为一种情况:由于任何人都可以在任何时间修改他们想要修改的任何东西,造成责任不明确,代码来回被重构造成代码质量恶劣.
6.1 解决方案
谨慎对来集体代码所有权制,也许考虑采用一个传统的模式,让团队成员中每个人拥有一个子模块更好点.