程序员/开发者的时间都去哪了？
对于那些不知道程序员/开发者的时间都去哪了的人，本文可能会提供一些线索。我记录了这份日志不仅是为了看看时间都花费在哪了，也是为了看看我都做了些什么，检视下自己是否偷懒了。当回顾之后，我发现花这些时间都是值得的。
作为开始，下面是我在前一阶段追踪的bug，（假设）你应该可以看到其中的错误。仅仅拿出这10行JavaScript并找到错误在哪里并不难，但要在茫茫的代码中定位这10行并证明那些就是bug，这就有一定的难度了。
如此宁静的一天。通常情况下，有三个人可能打断我工作的连贯性，因为11：30之前，我要不时的与他们通过语音或文字信息交流和讨论。把这些过程以log记录下来，实际上是对我工作的推进是有帮助的。这使得我能端坐在键盘前专注于我的工作，以免被别的问题分心。
- 09:50 收到了一封来自团队成员的邮件，内容是关于一些可能会产生问题的代码。我看了一下，并把目前解决不了部分整理起来。
- 10:10 继续昨天IE7虚拟机的下载（4gb）。
- 10:15 由于IE7下载的时间比较长，我趁着下载的时候，申请了TestingBot的账号。
- 10:20 与一名开发者Skype语音，讨论关于他新添加的功能。
- 10:21 由于设计师没有正确的把图片上传到网站，产生了大量的报错邮件。我花费了两天的时间让设计师掌握源代码控制软件。由于有些设计师没有Visual Studio，我也建立了一些用来存储特定内容的文件夹，这些文件夹可以自动发布问题给这些设计师。我有没有提到，无论是在测试中，镜像模拟阶段还是已发 布的产品中出现的每一个错误我都会记录下来。我认为这些设计师都应该看一看。
- 10:22 一名开发者要与我进行Skype语音。为了防止下载软件占据网速，而影响通信，我不得不暂停下载IE7。
- 10:45 完成与那名开发者的语音通信。
- 10:50 由于持续的退信错误，250个报错邮件不能够正常工作。我继续了IE7的下载。放弃删除报错邮件，手动连接Azune并刷新那些设计师之前没有正确上传的图片。
- 10:55 通过网络服务器继续测试IE7浏览器。查看日志中IE7报错的部分并找到错误发生的原因。
- 11:00 测试位置出现了新的错误。我发现是由于某一名开发者的原因，如果他能修复错误，测试将会继续进行。我发现缺失图片错误的原因是设计师仍然没有图片添加 到源码中。由于仍然报出大量的错误，Will不得不提醒那名设计师。查看进度服务器（设计师的乐园）上的图片，我发现设计师还是没有上传。我为设计师收集 了一份错误列表，其内容是由于缺少图片而产生的错误。我提取了这些错误，记录在一份Excel中，这里提取的仅仅是关于图片的报告。我创建了一个支持工单 （译者注：support ticket 支持工单系统），并发邮件给设计师。
- 11:11 回到IE7的错误上。通过查看日志，我找到了错误的原因。
- 11:16 在日志中找到IE7的错误并下载下来。由于文件比较大，下载花费了一点时间。
- 11:21 从日志中提取50个IE7的JavaScript代码错误。追踪Excel中的错误并试图减少这50行代码的错误。
- 11:23 发现错误出现在日志的起始处，而不是最近的记录。我对日志进行时间倒序排序并找到更多的错误。
- 11:26 不再查找Excel中新加入的错误，仅仅查看现在已经记录下来的。
- 11:30 第一个错误是无法加载谷歌的网站分析服务。原来又是那可恶的百度搜索引擎。
- 11:31 在开发过程中修复了下一个错误。
- 11:32 下一个问题发生在Mac中的FireFox浏览器。我想在上Mac需要建立一个完全单独的测试计划，因此我创建了一个支持工单。
- 11:35 余下的50个错误都是由于同一个Mac系统的问题，我不得不去找一些较早时间发生的错误。
- 11:37 在错误搜索中，用“或”取代“与”，并试着取消搜索过程，但无反应。
- 11:42 一封报错邮件提醒我，测试位置发现字体缺失的问题，我将此问题发邮件给设计师。
- 11:43 之前的搜索过程被取消，开始重新搜索。
- 11:45 设计师回邮件说，那些文件出现缺失并非偶然，现在问题已经解决了。
- 11:46 在等待下一批错误的时候，已发布产品又出现了一个不可思议的IE7错误。我用支持工单记录下了这个错误。如果当初我能有时间（5分钟），我绝不会去考虑其他错误细节。
- 11:50 最后，通过使用textingbot.com网站去查看IE7的错误，我现在知道为什么IE7不得不被淘汰了。除了提示一个模糊的行数、字符位置信息 和“期望一个标识符，字符串或数字”这类日志中已经有的信息，再也没有什么可用的开发工具可以帮助提供更多的错误信息了。
- 11:52 借助IE7测试浏览器的“查看源码（View source）”功能和之前记录错误的行数，我发现少了几行。再试一次，提示超时。我想我并没有少了那几行，因为IE7报告有一行没有 JavaScript代码，这个功能一定被行数和空白符（空格、Tab和回车）干扰了。
- 11:57 我刚注意到某页的中间几段JavaScript时，再次被设计师打断。通过查看这段代码，我发现它们主要负责处理移动端显示的问题。我试着直接在测试服务器上编辑这段代码，看看能不能注释掉这些错误。
- 12:04 不能直接编辑。由于测试服务器需要密码，网络蜘蛛程序禁止我建立索引。这意味着测试浏览器服务无法进入测试服务器。
- 12:06 哦！！！我进入测试服务器发现错误还在那里。哦不，测试服务器崩溃了。
- 12:08 重启IE7的测试并再次执行测试，日志上没有出现任何JavaScript错误。
- 12:09 删除那些可能有问题的代码的注释，我发现错误再次出现在日志中。接下来要缩小范围查找错误。
- 12:10 测试服务器又开始无反应，无法刷新页面。启动另一个服务器，并登入，我发现依然会出现错误。注释掉一些代码后，我发现错误是由于最后10行代码。为了 确定，我们将这10行代码页注释掉，发现可以运行了。我们再缩小一下范围，加一些alert函数。IE7再次崩溃。
- 12:26 一些尝试之后，我重启了IE7测试服务器，我发现了错误的原因。由于一段脚本代码使得IE7崩溃，我想这段代码也可以造成其他浏览器崩溃。这些代码不 算很糟糕，我也不会（太）责备设计师。但是，这些代码本来不应该在任何浏览器上运行，更确切的说，进入到产品运行的环境中。它被嵌入到那页代码的中间部 分。这属于JavaScript代码的问题，设计师用它们做一些黑客行为的事情，比如隐藏移动设备的菜单，而且这些JavaScript代码被藏在一页中 的中间部分。这些代码附近并没有放置测试代码，没人会在最初的快速浏览中发现它们。但它们带来的后果显而易见。
- 12:30 我在源代码中修复了这个bug，并记录下这个过程。接着，我开始解决其他IE7的bug。它们是。。。
- 12:34 我意识到，我必须将这段经历告诉开发团队，因为他们都可能会写上面那种代码（除了IE7，哪里都可以运行），而且仍然有相当多的用户在使用着这个功能。
- 12:45 完成这个bug的修复。
上面提到的bug，都是由那些初始化语句中的一个逗号引起的。
一定是有人复制粘贴了这段代码，一天之后，我又在其他地方发现了它们。
原文链接： Ryan O’Neill 翻译： 伯乐在线 – yuliu
译文链接： http://blog.jobbole.com/63770/
from:http://www.oschina.net/news/50072/what-do-developers-spend-all-that-time-on