1.3 首先，不行损害之事
那么，我们该如何承担责任呢？的确有一些原则可供参考。援引“希波克拉底誓言”或许显得有点夸张，但没有比这更好的引据了。的确，作为一名有追求有抱负的专业人士，他的首要职责与目标难道不正是尽其所能行有益之事吗？
软件开发人员能做出什么坏事呢？从纯软件角度看，他可以破坏软件的功能与架构。我们会探讨如何避免带来这些破坏。
1.3.1 不要破坏软件功能
显然，我们希望软件可以运行。没错，我们中的大部分人今天之所以是程序员，是因为我们曾开发出可用的软件，而且希望能再度体验那种成功创作的喜悦。但希望软件有用的不单单是我们，客户和雇主也希望它们能用。是啊，他们出钱，让我们去开发那些能按照他们意愿运行的软件。
开发的软件有bug会损害软件的功能。因此，要做得专业，就不能留下bug。
“等等！”你肯定会说，“可是那是不可能的呀。软件开发太复杂了，怎么可能会没bug呢！”
当然，你说的没错。软件开发太复杂了，不可能没什么bug。但很不幸，这并不能为你开脱。人体太复杂了，不可能尽知其全部，但医生仍要发誓不伤害病人。如果他们都不拿“人体的复杂性”作托辞，我们又怎么能开脱自己的责任呢？
“你的意思是我们要追求完美喽？”你可能会这样抬杠吧？
不，我其实是想告诉你，要对自己的不完美负责。代码中难免会出现bug，但这并不意味着你不用对它们负责；没人能写出完美的软件，但这并不表示你不用对不完美负责。
所谓专业人士，就是能对自己犯下的错误负责的人，哪怕那些错误实际上在所难免。所以，雄心勃勃的专业人士们，你们要练习的第一件事就是“道歉”。道歉是必要的，但还不够。你不能一而再、再而三地犯相同的错误。职业经验多了之后，你的失误率应该快速减少，甚至渐近于零。失误率永远不可能等于零，但你有责任让它无限接近零。
1．让QA找不出任何问题
因此，发布软件时，你应该确保QA找不出任何问题。故意发送明知有缺陷的代码，这种做法是极其不专业的。什么样的代码是有缺陷的呢？那些你没把握的代码都是！
有些家伙会把QA当作啄木鸟看待。他们把自己没有全盘检查过的代码发送过去，想等QA找出bug再反馈回来。没错，有些公司确实按照所发现的bug数来奖励测试人员，揪出的bug越多，奖金越多。
且不说这么做是否会大幅增加公司成本，严重损害软件，是否会破坏计划并让企业对开发小组的信心打折扣，也不去评判这么做是否等同于懒惰失职，把自己没把握的代码发送给QA这么做本身就是不专业的。这违背了“不行损害之事”的原则。
QA会发现bug吗？可能会吧，所以，准备好道歉吧，然后反思那些bug是怎么逃过你的注意的，想办法防止它再次出现。
每次QA找出问题时，更糟糕的是用户找出问题时，你都该震惊羞愧，并决心以此为戒。
2．要确信代码正常运行
你怎么知道代码能否常运行呢？很简单，测试！一遍遍地测，翻来覆去、颠来倒去地测，使出浑身解数来测！
你或许会担心这么狂测代码会占用很多时间，毕竟，你还要赶进度，要在截止日期前完工。如果不停地花时间做测试，你就没时间写别的代码了。言之有理！所以要实行自动化测试。写一些随时都能运行的单元测试，然后尽可能多地执行这些测试。
要用这些自动化单元测试去测多少代码呢？还要说吗？全部！全部都要测！
我是在建议进行百分百测试覆盖吗？不，我不是在建议，我是在要求！你写的每一行代码都要测试。完毕！
这是不是不切实际？当然不是。你写代码是因为想执行它，如果你希望代码可以执行，那你就该知道它是否可行。而要知道它是否可行，就一定要对它进行测试。
我是开源项目FitNesse的主要贡献者和代码提交者。在写作本书的时候，FitNesse的代码有6万多行。在这6万行代码中有2000多个单元测试，超过2.6万行。Emma的报告显示，这2000多个测试对代码的覆盖率约为90%。
为什么只有90%呢？因为Emma会忽略一些执行的代码。我确信实际的覆盖率会比90%高许多。能达到100%吗？不，达不到，100%只是个理想值。
但是有些代码不是很难测试吗？是的，但之所以很难测试，是因为设计时就没考虑如何测试。唯一的解决办法就是要设计易于测试的代码，最好是先写测试，再写要测的代码。
这一方法叫做测试驱动开发（TDD），我们在随后的章节里会继续谈到。
3．自动化QA
FitNesse的整个QA流程即是执行单元测试和验收测试。如果这些测试通过了，我就会发布软件。这意味着我的QA流程大概需要3分钟，只要我想要，可以随时执行完整的测试流程。
没错，FitNesse即使有bug也不是什么人命关天的事，也不会有人为此损失几百万美元。值得一提的是FitNesse用户上万，但它的bug列表却很短。
当然，也不排除有些系统因其任务极其关键特殊，不能只靠简短的自动化测试来判断软件是否已经足够高质量，是否可以投入使用。而且，作为开发人员，你需要有个相对迅捷可靠的机制，以此判断所写的代码可否正常工作，并且不会干扰系统的其他部分。因此，你的自动化测试至少要能够让你知道，你的系统很有可能通过QA的测试。
1.3.2 不要破坏结构
成熟的专业开发人员知道，聪明人不会为了发布新功能而破坏结构。结构良好的代码更灵活。以牺牲结构为代价，得不偿失，将来必追悔莫及。
所有软件项目的根本指导原则是，软件要易于修改。如果违背这条原则搭建僵化的结构，就破坏了构筑整个行业的经济模型。
简言之，你必须能让修改不必花太高代价就可以完成。
不幸的是，实在是已有太多的项目因结构糟糕而深陷失败的泥潭。那些曾经只要几天就能完成的任务现在需要耗费几周甚至几个月的时间。急于重新树立威望的管理层于是聘来更多的开发人员来加快项目进度，但这些开发人员只会进一步破坏结构，乱上添乱。
描述如何创建灵活可维护的结构的软件设计原则和模式[2]已经有许多了。专业的软件开发人员会牢记这些原则和模式，并在开发软件时认真遵循。但是其中有一条实在是没几个软件开发人员会认真照做，那就是，如果你希望自己的软件灵活可变，那就应该时常修改它！
要想证明软件易于修改，唯一办法就是做些实际的修改。如果发现这些改动并不像你预想的那样简单，你便应该改进设计，使后续修改变简单。
该在什么时候做这些简单的小修改呢？随时！关注哪个模块，就对它做点简单的修改来改进结构。每次通读代码的时候，也可以不时调整一下结构。
这一策略有时也叫“无情重构”，我把它叫作“童子军训练守则”：对每个模块，每检入一次代码，就要让它比上次检出时变得更为简洁。每次读代码，都别忘了进行点滴的改善。
这完全与大多数人对软件的理解相反。他们认为对上线运行的软件不断地做修改是危险的。错！让软件保持固定不变才是危险的！如果一直不重构代码，等到最后不得不重构时，你就会发现代码已经“僵化了”。
为什么大多数开发人员不敢不断修改他的代码呢？因为他们害怕会改坏代码！为什么会有这样的担心呢？因为他们没做过测试。
话题又回到测试上来了。如果你有一套覆盖了全部代码的自动化测试，如果那套测试可以随时快速执行，那么你根本不会害怕修改代码。怎样才能证明你不怕修改代码呢？那就是，你一直在改。
专业开发人员对自己的代码和测试极有把握，他们会极其疯狂随意地做各种修改。他们敢于随心所欲修改类的名称。在通读代码时，如果发现一个冗长的方法，他们肯定会将它拆分，重新组织。他们还会把switch语句改为多态结构，或者将继承层次重构成一条“命令链”。简单地说，他们对待代码，就如同雕塑家对待泥巴那样，要对它进行不断的变形与塑造。