我应该把它自动化吗？

_{有那么一个应用程序，它的部署只需要三个步骤：在数据库上运行“create tables”脚本，把应用程序文件拷贝到web服务器上，然后更新配置文件使之反映应用程序的路由变更。很简单的几个步骤。你需要每隔两三天就部署一次，那又怎么样呢？毕竟做这一切只需要15分钟。}

_{假如这个项目持续8个月又如何呢？你要把这个仪式重复64遍（实际上到项目后期这个速率还会提高，那时你会更加频繁地部署）。把它加起来：64次 x 15分钟 = 960分钟 = 16小时 = 2工作日。整整两个工作日不干别的，就是一遍又一遍地重复这同一件事！这还没考虑你会因为一时粗心忘记其中的某个步骤，然后不得不花更多的时间来调试和修复错误。所以，只要将其自动化的工作量不超过两天，这笔买卖就根本不需要考虑，因为你完全是在节约时间。但如果需要三天时间来将其自动化呢──还值得去做吗？}

_{我见过一些系统管理员，他们写bash脚本来执行每项任务。这样做的原因有两条。第一，既然你已经做了一次，那么几乎可以肯定以后你还会做同样的事。bash命令本身非常简洁，有时就连有经验的程序员也得花上好几分钟才能弄对；但如果你需要再次执行这个任务，保存下来的命令就能节省你的时间。第二，把一切有用的命令都保存在脚本中，就等于给你做的事情──甚至还可能包括为什么要做这些事──创建了一份活的文档。记录所做的每件事有些极端，但存储设备非常便宜──比起重新创造某些东西所需的时间来要便宜多了。你也可以做个折衷：不必保存做过的每件事，不过一旦发现自己第二次做某件事，就将其自动化。一旦某件事需要你做两次，很可能你还需要做100次。}

_{几乎所有*-nix用户都会在自己的.bash_profile配置文件里创建各种别名，给常用的命令行工具创造捷径。下面的例子展示了别名的语法：}

_{alias catout='tail -f /Users/nealford/bin/apache-tomcat-6.0.14/logs/catalina.out'}

_{alias derby='~/bin/db-derby-10.1.3.1-bin/frameworks/embedded/bin/ij.ksh'}

_{alias mysql='/usr/local/mysql/bin/mysql -u root'}

_{Any frequently used command can appear in this file, freeing you from having to remember some incantation that does magic. In fact, this ability significantly overlaps that of using key macro tools (see the section called “Key Macro Tools”” in Chapter 2). I tend to use bash aliases for most things (less overhead with expanding the macro), but one critical category exists for which I use key macro tools. Any command line you have that contains a mixture of double and single quotes is hard to get escaped exactly right as an alias. The key macro tools handle that much better. For example, the svnAddNew script (shown earlier in the section called “Tame Command-Line Subversion””) started as a bash alias, but it was driving me nuts trying to get all the escaping just right. It now lives as a key macro, and life is much simpler.}

_{所有常用的命令都可以放在这个文件里，这样你就不必费心记住那些复杂的魔法咒语了。实际上，这个功能与键盘宏工具（参见第2章“键盘宏工具”一节）有很大程度的重合。对于大部分命令，我都比较喜欢用bash别名（从而不必进行宏展开），但有那么一种重要的情况会让我使用键盘宏工具：如果一条命令里同时包含双引号和单引号，就很难为它创建别名，因为很难把引号转码弄对。键盘宏工具能更好地处理这种情况。比如说svnAddNew这个脚本（在前面的“驯服Subversion命令行”中展示过了）一开始是一个bash别名，但为了把引号转码弄对几乎把我给搞疯了，所以后来我把它实现为一个键盘宏，生活从此变得轻松。}

_提示

_{是否应该自动化的关键在于投资回报率和缓解风险。}

_{项目中会有很多杂事让你想要自动化，这时你应该先拿下列问题来问自己（并且诚实地作答）：}

_{l长期来看，将其自动化能节省时间吗？}

_{l这件任务是否很容易出错（因为其中包含很多复杂的步骤）？一旦出错是否会浪费大把时间？}

_{l执行这件任务是否在浪费我的注意力？（几乎所有任务都会使你的注意力为之转移，你必须花些工夫才能再回到全神贯注的状态。）}

_{l如果手工操作失误会造成什么危害？}

_{最后一个问题之所以重要，因为它涉及到风险的考量。在我以前工作过的一个项目里，人们由于历史原因而把代码和测试输出在同一个目录里。要运行测试，我们需要创建三个不同的测试套件，分别对应一种类型的测试（单元测试、功能测试和集成测试）。项目经理建议我们手工创建这些测试套件，但我们还是决定借助反射机制来自动创建它们。手工更新测试套件很容易出错，开发者很可能会写了测试却忘记把它加入到测试套件，从而导致新增的测试不被运行。我们认为，不将这个环节自动化可能造成很大的危害。}

_{当你打算把某个任务自动化时，项目经理可能会担心你的工作失控。我们都有过这样的经验：原本以为只要两个小时就能搞定的事，最终用了4天才总算做完。要控制这种风险，最好的办法就是“时间盒”（timebox）：首先定好一段时间来探索和了解情况，时间一到就客观地评估是否值得去做这件事。使用时间盒是为了掌握更多信息，以便做出切合实际的决策。时间盒到期以后，如果掌握的信息不够，你也可以再增加一个时间盒，以便找出更多信息。我知道，巧妙的自动化脚本比那些无聊的项目工作更让你感兴趣，但还是现实点吧，你的老板一定比较喜欢脚踏实地的工作量估算。}

_提示

_{研究性的工作应该放在时间盒里做。}

_{别给牦牛剪毛}

_{最后，别让自动化的努力变成“剪牦牛毛”──这是一句在计算机科学界源远流长的黑话，它代表了诸如此类的情况：}

_{1.你打算根据Subversion日志自动生成一些文档。}

_{2.你尝试给Subversion加上一个钩子，然后发现当前使用的Subversion版本与你的web服务器不兼容。}

_{3.你开始更新web服务器的版本，随后又发现这个新版本在操作系统当前的这个补丁级别上不被支持，于是你开始更新操作系统。}

_{4.操作系统的更新包存在一个已知的问题，与用于备份的磁盘阵列不兼容。}

_{5.你下载了尚未正式发布的针对磁盘阵列的操作系统补丁，它应该能用……它确实能用，但又导致显卡驱动出了问题。}

_{终于在某个时候，你停下来回想自己一开始到底是想干什么。然后你发现自己正在给牦牛剪毛，这时你就应该停下来想想：这一大堆牦牛毛跟“从Subversion日志生成文档”到底有什么关系呢？}

_{剪牦牛毛是件危险的事，因为它会吃掉你大把的时间。这也能解释为什么任务工作量估算常常出现偏差：剪光一头牦牛的毛需要多少时间？始终牢记你到底要做什么，如果情况开始失控就及时抽身而出。}