程序员/开发者的时间都去哪了？

程序猿你是第1798个围观者 0条评论供稿者：zhaorong 标签：时间去哪儿, 程序员

对于那些不知道程序员/开发者的时间都去哪了的人，本文可能会提供一些线索。我记录了这份日志不仅是为了看看时间都花费在哪了，也是为了看看我都做了些什么，检视下自己是否偷懒了。当回顾之后，我发现花这些时间都是值得的。

作为开始，下面是我在前一阶段追踪的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的修复。