程序员/开发者的时间都去哪了？_最新动态

您所在的位置：程序员俱乐部 > 新闻资讯 > 最新动态 > 程序员/开发者的时间都去哪了？

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

2014/3/26 15:02:15 程序员俱乐部我要评论(0)

摘要：英文原文：Whatdodevelopersspendallthattimeon?对于那些不知道程序员/开发者的时间都去哪了的人，本文可能会提供一些线索。我记录了这份日志不仅是为了看看时间都花费在哪了，也是为了看看我都做了些什么，检视下自己是否偷懒了。当回顾之后，我发现花这些时间都是值得的。作为开始，下面是我在前一阶段追踪的bug，（假设）你应该可以看到其中的错误。仅仅拿出这10行JavaScript并找到错误在哪里并不难，但要在茫茫的代码中定位这10行并证明那些就是bug，这就有一定的难度了
标签：

class="topic_img" alt=""/>

　　英文原文：What do developers spend all that time on?

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

　　作为开始，下面是我在前一阶段追踪的 bug，（假设）你应该可以看到其中的错误。仅仅拿出这 10 行 JavaScript 并找到错误在哪里并不难，但要在茫茫的代码中定位这 10 行并证明那些就是 bug，这就有一定的难度了。

resource

　　如此宁静的一天。通常情况下，有三个人可能打断我工作的连贯性，因为 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 的修复。