关注51Testing
零Bug策略：要么立马修复，要么忽略
发表于： 11:12 &作者：Gal Zellermayer & 来源：伯乐在线
推荐标签：
　　你在管理着多少个 ，100，200，还是 2000 个？可能你自己也说不清，因为这个数字一直在变化。　　但我却能说出我们的 bug 数：0 个。　　你究竟在 bug 分派和管理上花费了多长时间，还是只能把它们从这个版本拖到下一个版本？　　作为一个团队经理（group manager），我每个月要花半小时的时间在 bug 管理上，并且同样的 bug 不会在我眼里出现第二次。　　你有没有考虑过，当你使用 Scrum 或其他敏捷方法时，要如何处理 bug 呢？　　答案就是使用 0 bug 策略。过去五年中，我参与过不同产品的 Scrum 项目，这个策略是基于我的工作经验得出的。　　我们也尝试过其他方法，但都宣告失败。例如，我们试过提升 bug 在产品待办事项中的优先级，但没什么用处。比起修复这些 bug，客户更倾向于给产品开发一些新功能，然后这些 bug 就会被推迟到下一次迭代中。　　0 bug 策略解决了这一问题。　　下面我们来了解一下 0 bug 策略，以及为什么我认为这是最好的解决方案。　　什么是 0 bug 策略？　　0 bug 策略是一种非常先进的处理 bug 的策略，但同时它也非常易于实施。　　你只需要谨记一条准则：不论何时对 bug 的处理方法只有两种选择，或修复它，或关闭然后不再去想它。　　如何实施？　　Bug 可以分为两类：　　· Bugs that were opened during the development of a new feature.　　·&开发新功能时出现的 bug。　　如果你们正在使用 Scrum 方法（或其他敏捷迭代方法），在实现用户故事（user story）的 sprint 过程中产生的bug。　　这类 bug 必须立刻修复，否则用户故事，或者说新功能的实现就会受到影响，而且你也违背了敏捷开发的原则：DONE is DONE（木已成舟，指开发完成就不再更改）。只有经过全方面，并得到客户的认可后，用户故事或新功能才能算得上是真正的完成。　　·&其他 bug（非 print 过程中产生的 bug）可以分为以下几种：　　·&回归 bug ：由于开发新功能导致其他功能出现 bug 的情况。　　·&客户 bug ：不是由项目组成员提出，而是由客户或用户反馈的 bug。　　·&在新功能/用户故事实现后才发现的 bug。这种情况不应该发生，但有时又无法避免，比如说当测试覆盖不足、进行 bug 跟踪或产品固化时都可能会发生。　　我们应该如何处理第二类 bug？　　·&立即修复（或在下一次 sprint 中修复，但不能拖到更晚了）　　·&如果修复这个 bug 价值不大，直接关闭不进行修复即可　　·&推迟解决（在几个月后或在下一个版本中再解决）　　永远不要推迟 bug，如果你现在无法修复它，那么你可能永远都不会再修复它了。　　那我们应该怎么做呢？或者选择修复它，或者关闭它，这就是 0 bug 策略的精髓。　　如下这种 bug 是必须进行修复的：两个用户无法同时进入 UI　　如果修复一个 bug 需要超过两天的时间，可以考虑不进行修复，举个例子：　　在 Safari 的使用过程中，当屏幕分辨率为768×1280 时登录页面中的帮助文本有些模糊。其他或其他的分辨率就没有这样的问题。　　可能有人会问，为什么不能推迟一些时间再解决这些 bug 呢？　　如果以后再修复，你需要花费比现在更多的时间和精力才可以。因为几周后：　　·&你可能记不太清，或你对 bug 的理解没现在这么清晰。　　·&验证错误和修复 bug 需要恰当的环境，几周后你需要投入很多时间来搭建环境。　　·&导致原始 bug 的代码可能发生变动，其他特性也可能会稍有区别。　　然而问题不仅仅是你需要投入更多时间才能修复 bug，这只是一个很小的方面。　　后续你还要对这些 bug 进行维护、分类和管理。无论是把它们放在产品待办事项中（在某些 bug 分类系统中），还是作为主要功能清单的一部分，你都需要对这些 bug 按优先级排序，这无疑会耗费很多时间。处理旧 bug 则需要更长的时间，因为你不能像熟知新 bug 一样那么了解它们了。同时，bug 分类也是很烦人的。　　根据我的经验来说，当经理、开发人员、产品所有者和架构师坐在一个 bug 法院（试图决定如何处理 bug）时，这场讨论将变成一场没有赢家的战争：　　·&开发经理：“现在修复这个 bug 有风险，不如推迟吧。”　　·&产品拥有者：“你根本没有考虑到用户体验，你没有为用户考虑！”　　·&开发人员：“我们可以不使用Java，只要做一个简单的 Go 模块就可以提升目标系统的性能。”　　·&架构师：“我建议放弃 extJS 转向 Angular，后者功能更强大，但需要一提的是，修复这个 bug 可能会带来安全方面的影响”　　·&QA：“测试这个修复很简单，两个小时之内就能完成。当然，如果需要模拟多浏览器多用户的情况就需要几天的时间。并且我们需要确保在规模化的角度不会有回归测试。”　　你将永远无法修复这个 bug，它会永远存在你的系统里。这类 bug 会越来越多，它们会一直跟着你。你只能一次又一次地进行分类，把它们在每周的报告中，并且在质量指数中计算它们。　　为什么这些 bug 永远无法被修复？　　·&如果你现在不打算修复的话，意味着在现在和以后的版本中，你都有更重要的事做。　　·&随着时间的推移，你会推迟越来越多的 bug，这些旧 bug 还要和新功能和新 bug 进行竞争。所以，如果在没什么其他严重 bug 情况下这些 bug 还无法被修复的话，你凭什么认为以后就能修复它们呢？　　为什么不能在发布最后的加固阶段修复非 sprint 期的 bug？　　在加固阶段，你应该努力让你的版本更稳定一些。你要尽力寻找未知的问题，而不是在这时修复那些推迟的小 bug。　　不论何时，你都不可能修复所有的 bug，总会有一些被推迟到下一个版本解决。而在下一个版本中你肯定会发现新的 bug。那些低优先级的 bug 永远不会被修复，但你还需要花时间维护它们。　　也许 4 年后你决定不再修复它们，因为不值得的浪费精力。想象一下，如果在创建 bug 时就直接选择不进行修复，你将节省多少时间。　　为什么不能在空载时间修复它们？　　你不会有空载时间的，如果有的话，也会有更重要的问题等着你去处理。　　为什么不能在下一个版本中修复它们？　　你确定么？难道下一个版本没有新功能、客户、截止日期和里程碑么？　　当然开发人员都很喜欢那两周的错误修复时间，每次 sprint 有几个 bug 会使团队人员更高兴。　　如果一个新版本刚开始的时候，功能列表还是空白的，不如在创新或社交活动上投入点时间，你会受益良多。　　为什么不能在专门的 sprint 期中修复非 springt &bug？　　我们以前尝试过这种方法，的确有些好处。产品所有者没有选择，因为整个团队这段时间都在修复 bug，每个人都在做这件事，给人一种团队合作的感觉。　　然而我却不是很推崇它，因为这种方法只是处理了其中一小部分，根本没法消除日积月累的 bug，后期你仍然会面临这些问题，而且问题会更复杂。　　为什么不能把 bug 作为待办列表的一部分解决？　　实际上这也是个不错的选择，但需要注意：　　1、产品所有者很难理解为什么这些 bug 的优先级会比新用户故事要高，他们更倾向于用户故事。删除弹窗中多余的滚动条和添加搜索功能，哪个更重要呢？这将会降低产品的质量和研发热情。　　2、每个现在你无法修复的 bug后期会消耗更多的时间。推迟 bug 不符合成本效益。　　下面这张图展示了 bug 和用户故事混合记录的情况。我们尝试了将几个用户故事和 bug 放在一起处理：　　在此期间，项目组只需处理前三条内容　　产品所有者决定将第三项优先级降低，因为停止应用程序功能更加重要　　产品拥有者还不是很满意，因为搜索功能没在列表中提及　　我们和团队达成协议优先解决前三个用户故事，同时尽可能修复 bug。Bug 并没有得到修复。下次 sprint 的模式还是一样的，更多的bug 被积压，而新的功能都得到了处理。　　现在，我们同意 0 bug 策略是唯一的出路了。　　为什么0 bug 策略不常见？　　0 bug 策略不太常见可能有以下几个原因：　　我的产品已经有超过 1000 个 bug 了，我如何开始？　　花一个星期的时间浏览这些 bug，或者选择不再修复它们，或者在下一个 sprint 中进行修复。你需要做的就是把 bug 数变为 0，然后保持住。　　恐惧　　这可能是为什么人们不喜欢 0 bug 策略的真正原因。我曾向几个团队介绍了这种方法，但是由于恐惧他们都拒绝尝试：　　如果我们关闭了这个 bug，它就彻底消失了，我们永远也找不到它了！　　没错，就是这样，难道你没有感觉到解脱么？　　但是，如果我们关闭这个 bug，用户在使用产品时又发现它，不是还要重新修复么？　　既然这个 bug 如此重要，不如现在就动手解决吧！　　我们团队只有两个人，需要遵循 0 bug 策略么？　　如果你们的团队只有两个人，就不需要任何策略，因为你们不应该有 bug，更不会去分拣它们。　　敏捷开发的主要原则是人大于过程， 0 bug 策略是否违背了这个原则？　　的确是，从我的经验来说，我更喜欢通过文化变革来解决问题，而不是增加过程。0 bug 策略是这个策略的例外。　　总结　　我可以诚实地说，使用 0 bug 策略并不是微不足道，相反它能带来很好的成本效益。对我来说，最难的部分可能是如何说服产品经理，这种方法是唯一正确的方式。这要求他们稍微放掉一些权利，这不是一件容易的事情。最好能让他们意识这个策略没有拖慢进度，反而大有用处。　　0 bug 策略还有另外一个作用，现在的开发人员追求更高的质量，没有人希望自己的代码出现错误。有了 0 bug 策略，他们知道如果现在不进行修复的话，bug 将被关闭。因此，开发者和产品才能向更高的质量标准迈进。　　这篇受到 Joel Spolsky 的博客 Software Inventory 的影响，但主要是我和同事在 VMware Israel 时完成的。
搜索风云榜
51Testing官方微信
51Testing官方微博
测试知识全知道零 bug 策略，防御性编程
零 bug 策略
Bug一词的原意是“臭虫”或“虫子”；而在电脑系统或程序中隐藏着的一些未被发现的缺陷或问题，人们也叫它“bug”。
“Bug”的创始人格蕾丝·赫柏（Grace Murray Hopper），是一位为美国海军工作的电脑专家，也是最早将人类语言融入到电脑程序的人之一。而代表电脑程序出错的“bug” 这名字，正是由赫柏所取的。日，赫柏对Harvard Mark II设置好17000个继电器进行编程后，技术人员正在进行整机运行时，它突然停止了工作。于是他们爬上去找原因，发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾，这显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。所以在报告中，赫柏用胶条贴上飞蛾，并把“bug”来表示“一个在电脑程序里的错误”，“Bug”这个说法一直沿用到今天。
与Bug相对应，人们将发现Bug并加以纠正的过程叫做“Debug”(中文称作“调试”），意即“捉虫子”或“杀虫子”。
后来就直接用bug 在很多的软件测试中 都用Bug来说明那些问题。
所谓“（Bug）”，是指电脑系统的硬件、系统软件（如操作系统）或应用软件（如文字处理软件）出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。
软件的Bug，狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。仅就狭义概念而言，软件出现Bug的原因有：
1、对各种流程分支考虑不全面；
2、对边界情况的处理不到位；
3、编码时的手误。
任何软件在发布时都不可能是绝对的零Bug。在软件过程管理中通行的CMM（能力成熟度模型）中规定的软件质量标准是（Bug个数/千行源码）：
CMM1级 11.95
CMM2级 5.52
CMM3级 2.39
CMM4级 0.92
CMM5级 0.32
你在管理着多少个 bug，100，200，还是 2000 个？可能你自己也说不清，因为这个数字一直在变化。
但我却能说出我们的 bug 数：0 个。
你究竟在 bug 分派和管理上花费了多长时间，还是只能把它们从这个版本拖到下一个版本？
作为一个团队经理（group manager），我每个月要花半小时的时间在 bug 管理上，并且同样的 bug 不会在我眼里出现第二次。
你有没有考虑过，当你使用 Scrum 或其他敏捷方法工作时，要如何处理 bug 呢？
答案就是使用 0 bug 策略。过去五年中，我参与过不同产品的 Scrum 项目，这个策略是基于我的工作经验得出的。
我们也尝试过其他方法，但都宣告失败。例如，我们试过提升 bug 在产品待办事项中的优先级，但没什么用处。比起修复这些 bug，客户更倾向于给产品开发一些新功能，然后这些 bug 就会被推迟到下一次迭代中。
0 bug 策略解决了这一问题。
下面我们来了解一下 0 bug 策略，以及为什么我认为这是最好的解决方案。
什么是 0 bug 策略？
0 bug 策略是一种非常先进的处理 bug 的策略，但同时它也非常易于实施。
你只需要谨记一条准则：不论何时对 bug 的处理方法只有两种选择，或修复它，或关闭然后不再去想它。
如何实施？
Bug 可以分为两类：
开发新功能时出现的 bug。
如果你们正在使用 Scrum 方法（或其他敏捷迭代方法），在实现用户故事（user story）的 sprint 过程中产生的bug。
这类 bug 必须立刻修复，否则用户故事，或者说新功能的实现就会受到影响，而且你也违背了敏捷开发的原则：DONE is DONE（木已成舟，指开发完成就不再更改）。只有经过全方面测试，并得到客户的认可后，用户故事或新功能才能算得上是真正的完成。
其他 bug（非 print 过程中产生的 bug）可以分为以下几种：
回归 bug ：由于开发新功能导致其他功能出现 bug 的情况。
客户 bug ：不是由项目组成员提出，而是由客户或用户反馈的 bug。
在新功能/用户故事实现后才发现的 bug。这种情况不应该发生，但有时又无法避免，比如说当测试覆盖不足、进行 bug 跟踪或产品固化时都可能会发生。
我们应该如何处理第二类 bug？
立即修复（或在下一次 sprint 中修复，但不能拖到更晚了）
如果修复这个 bug 价值不大，直接关闭不进行修复即可
推迟解决（在几个月后或在下一个版本中再解决）
永远不要推迟 bug，如果你现在无法修复它，那么你可能永远都不会再修复它了。
那我们应该怎么做呢？或者选择修复它，或者关闭它，这就是 0 bug 策略的精髓。
如下这种 bug 是必须进行修复的：两个用户无法同时进入 UI
如果修复一个 bug 需要超过两天的时间，可以考虑不进行修复，举个例子：
在 Safari 的使用过程中，当屏幕分辨率为768×1280 时登录页面中的帮助文本有些模糊。其他浏览器或其他的分辨率就没有这样的问题。
可能有人会问，为什么不能推迟一些时间再解决这些 bug 呢？
如果以后再修复，你需要花费比现在更多的时间和精力才可以。因为几周后：
你可能记不太清，或你对 bug 的理解没现在这么清晰。
验证错误和修复 bug 需要恰当的环境，几周后你需要投入很多时间来搭建环境。
导致原始 bug 的代码可能发生变动，其他特性也可能会稍有区别。
然而问题不仅仅是你需要投入更多时间才能修复 bug，这只是一个很小的方面。
后续你还要对这些 bug 进行维护、分类和管理。无论是把它们放在产品待办事项中（在某些 bug 分类系统中），还是作为主要功能清单的一部分，你都需要对这些 bug 按优先级排序，这无疑会耗费很多时间。处理旧 bug 则需要更长的时间，因为你不能像熟知新 bug 一样那么了解它们了。同时，bug 分类也是很烦人的。
根据我的经验来说，当经理、开发人员、产品所有者和架构师坐在一个 bug 法院（试图决定如何处理 bug）时，这场讨论将变成一场没有赢家的战争：
开发经理：“现在修复这个 bug 有风险，不如推迟吧。”
产品拥有者：“你根本没有考虑到用户体验，你没有为用户考虑！”
开发人员：“我们可以不使用Java，只要做一个简单的 Go 模块就可以提升目标系统的性能。”
架构师：“我建议放弃 extJS 转向 Angular，后者功能更强大，但需要一提的是，修复这个 bug 可能会带来安全方面的影响”
QA：“测试这个修复很简单，两个小时之内就能完成。当然，如果需要模拟多浏览器多用户的情况就需要几天的时间。并且我们需要确保在规模化的角度不会有回归测试。”
你将永远无法修复这个 bug，它会永远存在你的系统里。这类 bug 会越来越多，它们会一直跟着你。你只能一次又一次地进行分类，把它们记录在每周的报告中，并且在质量指数中计算它们。
为什么这些 bug 永远无法被修复？
如果你现在不打算修复的话，意味着在现在和以后的版本中，你都有更重要的事做。
随着时间的推移，你会推迟越来越多的 bug，这些旧 bug 还要和新功能和新 bug 进行竞争。所以，如果在没什么其他严重 bug 情况下这些 bug 还无法被修复的话，你凭什么认为以后就能修复它们呢？
为什么不能在发布最后的加固阶段修复非 sprint 期的 bug？
在加固阶段，你应该努力让你的版本更稳定一些。你要尽力寻找未知的问题，而不是在这时修复那些推迟的小 bug。
不论何时，你都不可能修复所有的 bug，总会有一些被推迟到下一个版本解决。而在下一个版本中你肯定会发现新的 bug。那些低优先级的 bug 永远不会被修复，但你还需要花时间维护它们。
也许 4 年后你决定不再修复它们，因为不值得的浪费精力。想象一下，如果在创建 bug 时就直接选择不进行修复，你将节省多少时间。
为什么不能在空载时间修复它们？
你不会有空载时间的，如果有的话，也会有更重要的问题等着你去处理。
为什么不能在下一个版本中修复它们？
你确定么？难道下一个版本没有新功能、客户、截止日期和里程碑么？
当然开发人员都很喜欢那两周的错误修复时间，每次 sprint 有几个 bug 会使团队人员更高兴。
如果一个新版本刚开始的时候，功能列表还是空白的，不如在创新或社交活动上投入点时间，你会受益良多。
为什么不能在专门的 sprint 期中修复非 springt bug？
我们以前尝试过这种方法，的确有些好处。产品所有者没有选择，因为整个团队这段时间都在修复 bug，每个人都在做这件事，给人一种团队合作的感觉。
然而我却不是很推崇它，因为这种方法只是处理了其中一小部分，根本没法消除日积月累的 bug，后期你仍然会面临这些问题，而且问题会更复杂。
为什么不能把 bug 作为待办列表的一部分解决？
实际上这也是个不错的选择，但需要注意：
产品所有者很难理解为什么这些 bug 的优先级会比新用户故事要高，他们更倾向于用户故事。删除弹窗中多余的滚动条和添加搜索功能，哪个更重要呢？这将会降低产品的质量和研发热情。
每个现在你无法修复的 bug后期会消耗更多的时间。推迟 bug 不符合成本效益。
下面这张图展示了 bug 和用户故事混合记录的情况。我们尝试了将几个用户故事和 bug 放在一起处理：
在此期间，项目组只需处理前三条内容
产品所有者决定将第三项优先级降低，因为停止应用程序功能更加重要
产品拥有者还不是很满意，因为搜索功能没在列表中提及
我们和团队达成协议优先解决前三个用户故事，同时尽可能修复 bug。Bug 并没有得到修复。下次 sprint 的模式还是一样的，更多的bug 被积压，而新的功能都得到了处理。
现在，我们同意 0 bug 策略是唯一的出路了。
为什么0 bug 策略不常见？
0 bug 策略不太常见可能有以下几个原因：
我的产品已经有超过 1000 个 bug 了，我如何开始？
花一个星期的时间浏览这些 bug，或者选择不再修复它们，或者在下一个 sprint 中进行修复。你需要做的就是把 bug 数变为 0，然后保持住。
这可能是为什么人们不喜欢 0 bug 策略的真正原因。我曾向几个团队介绍了这种方法，但是由于恐惧他们都拒绝尝试：
如果我们关闭了这个 bug，它就彻底消失了，我们永远也找不到它了！
没错，就是这样，难道你没有感觉到解脱么？
但是，如果我们关闭这个 bug，用户在使用产品时又发现它，不是还要重新修复么？
既然这个 bug 如此重要，不如现在就动手解决吧！
我们团队只有两个人，需要遵循 0 bug 策略么？
如果你们的团队只有两个人，就不需要任何策略，因为你们不应该有 bug，更不会去分拣它们。
敏捷开发的主要原则是人大于过程， 0 bug 策略是否违背了这个原则？
的确是，从我的经验来说，我更喜欢通过文化变革来解决问题，而不是增加过程。0 bug 策略是这个策略的例外。
我可以诚实地说，使用 0 bug 策略并不是微不足道，相反它能带来很好的成本效益。对我来说，最难的部分可能是如何说服产品经理，这种方法是唯一正确的方式。这要求他们稍微放掉一些权利，这不是一件容易的事情。最好能让他们意识这个策略没有拖慢进度，反而大有用处。
0 bug 策略还有另外一个作用，现在的开发人员追求更高的质量，没有人希望自己的代码出现错误。有了 0 bug 策略，他们知道如果现在不进行修复的话，bug 将被关闭。因此，开发者和产品才能向更高的质量标准迈进。
防御性编程
为什么开发者不编写安全的代码？我们在这并不是要再一次讨论「整洁代码」。我们要从纯粹的实用观点出发，讨论软件的安全性和保密性。是的，因为不安全的软件不仅无用，而且还可怕。我们来看看什么是不安全的软件。
日，欧洲航天局的 Ariane 5 Flight 501 在起飞后 40 秒被引爆。因为导航软件里的一个 bug，这个价值 10 亿美金的运载火箭不得不自毁。
日，MIM-104 Patriot（爱国者）里的一个软件错误使它的系统每一百小时有三分之一秒的时钟偏移，导致定位拦截入侵导弹失败。结果伊拉克的飞毛腿导弹击中宰赫兰（沙特阿拉伯东北部城市）的一个美军军营，28 人死亡，100 多人受伤。
这应该能够说明编写安全软件的重要性了，尤其在特定的环境中。当然也包括其他用例中，我们也应该意识到我们的软件 bug 会导致什么后果。
防御性编程初窥
为什么我认为在特定种类的工程中，防御性编程是解决这些问题好办法？
抵御那些不可能的事，因为看似不可能的事也会发生。
防御性编程中有很多防御方式，这也取决于你的软件项目所需的「安全」级别和资源级别。
防御性编程是防御式设计的一种形式，用来确保软件在未知的环境中能继续运行。防御性编程的实践往往用于需要高可用性、安全性、保密性的地方。
我个人相信这种方法适合很多人参与的大型、长期的项目。例如，一个需要大量维护的开源项目。
我们来探索一下我提出的关键点，来完成一个防御性编程的实现。
永远不要相信用户输入
设想你总是获取到你不想要的东西。因为像我们说过的，我们预期的是异常情况的出现，（所以）要时刻防备用户输入以及通常会传入你系统的东西，这是你成为一个防御性程序员的方法。试着做到尽可能的严格，确保输入的值就是你所期望的值。
进攻是最好的防守
设置白名单而不是黑名单。举个例子，当你验证图像扩展名时，不要检查非法的类型，而是检查合法的类型并排除其他类型。在 PHP 有无数的开源校验库可以让你的工作变简单。
进攻是最好的防守。
数据库抽象化
在 OWASP Top 10 Security Vulnerabilities排首位的是注入攻击。这意味着有些人（很多人）还没有使用安全的工具来查询数据库。请使用数据库抽象包或库。
不要重复发明轮子
你不用框架（或微框架）吗？好吧恭喜你，你喜欢毫无理由地做额外的工作。这并不仅跟框架有关，也意味着你可以方便地使用已经存在的、经过测试的、受万千开发者信任的、稳定的新特性，而不是你只为了自己从中受益而制作的东西。你自己创建方法的唯一原因是你需要的东西不存在，或存在但不符合你的需求（性能差、缺失特性等等）。
这就是所谓的智能代码重用。拥抱它吧。
不要相信开发者
防御性编程与防御性驾驶相关联。在防御性驾驶中，我们假设周围的每个人都可能犯错。所以我们要留意别人的行为。相同概念也适用于防御性编程，我们作为开发者不要相信其他开发者的代码。我们同样也不要相信我们的代码。
在很多人参与的大型项目中，我们有许多方式编写并组织代码。这也导致混乱甚至更多的 bug。这也是我们需要加强规范代码风格和代码检查的原因，让生活更轻松。
编写符合 SOLID 原则的代码
这是（防御性）编程最困难的部分——编写不糟糕的代码。这也是很多人知道并一直在讨论的，但没有人真正关心或将注意力和精力放在实现符合 SOLID 原则的代码上。
让我们看一些糟糕的例子
避免：未初始化的属性
在这个例子中，我们需要牢记签发付款前要先调用 setCurrency。这是很糟糕的事情，一个像这样的改变状态的操作（签发付款）不应该分两步来完成，且使用两个公开的方法。我们还可以用很多方法付款，但我们必须只有一个公开的方法来改变状态（对象不应该存在不一致的状态）。
在这个例子中，我们把它改进，将未初始化的属性封装进 Money 对象。
使它万无一失。不要使用未初始化的对象属性。
避免：在类的作用域外泄露状态
在这个例子中，Message 是通过引用传递的，两个实例的输出都是 “joe message”。一个解决方案是复制 Mailer 构造函数中的 message 对象。但是我们应该做的是试着使用（不可变的）值对象，而不是简单可变的 Message 对象。尽可能使用不可变的对象。
这点我们很还需要再说吗？编写单元测试可以帮助你秉承一般的原则，比如高内聚、单一职责、低耦合和正确的对象组合。它不仅帮助你测试小的单元用例，也能测试你组织对象的方式。确实，当测试你的小功能时，你会清晰的看到你需要测试多少情况和需要模拟多少对象，来达到 100% 的覆盖率。
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点}