我们系统有一个发布的功能，这个发布非常慢，因为它牵扯到很多内容，所以，我们把这个发布变成了异步操作。不过，最近一段时间，这个发布变本加厉的慢了，据PM在UAT上测试的结果，发布一次要5个小时。于是，我今天决定看看为什么这个发布会慢到这个地步。
当我分阶段为这个发布过程加上日志之后，定位到了一个非常慢的方法。我简单测试了一下这个方法，耗时在十分钟以上。这个方法要做的是，如果一个对象所关联的一些对象都已经被废弃的话，那么就把这个对象废弃。这里的废弃实际上就是一个标记的工作。说起来很简单，但是真正理解这个方法所做的事却花了我很多时间，这段代码的实现是这样的：
* 它在关联对象的表进行查找，找到那些那些关联对象都已经废弃的情况，然后，找到这些关联对象所指的目标对象，也就是这些目标对象应该废弃，由此得到一个目标对象数组。
* 遍历目标对象表，如果这个目标对象在目标对象数组中，那么把它标记为废弃。
确实不好理解吧！如果你理解了这段代码的意思，你可能会问为什么会这么做，我也想知道。
当我用产品数据库进行测试时，第一步产生的目标对象数组包含超过12000个对象，而第二步遍历目标对象表则有近8000个对象。那么判断目标对象是否在目标对象数组的操作就是一个上亿规模的操作，这是这个操作缓慢的原因。可以预见，随着这个系统使用的增多，这两个表里面的内容会越来越多，这个操作的规模会越来越大，那么这个方法就会越来越慢。
之前曾有同事解决过一个问题，就是这里。问题是这样的，这里的操作有很长时间没有访问数据库，所有有时候，数据库连接会超时。我在这里做了一个统计，真正需要标记为废弃的对象大约只有800个，而前面提到了，这是一个上亿的数据规模，也就是说，大部分时间，系统是在空跑，而且你知道，Ruby并不是以高性能著称的程序设计语言，所以，会长时间没有任何操作。当时的解决方案是，定期进行一个对连接进行verify，告诉连接我们还活着。这是一个治标不治本的解决方案。
简单分析一下，我们便不难发现一些问题：
* 目标对象表一共只有8000个对象，为什么目标对象数组会超过12000。
* 既然目标对象数据包含了所有要废弃的对象，为什么还要遍历目标对象表。
简单这样一想，似乎解决方案就在眼前了，删除第二步操作，把第一步得到的数组做uniq，去除相同的内容，然后，遍历得到的数组，将所有的目标对象废弃。按照这个思路，把对象拿到内存中，进行处理的话，那么我们要做的是，把所有的对象找出来，然后遍历，修改状态，之后保存数据。内存操作虽好，但最终还需要写回数据库，这样算下来，这里要进行的数据库访问就是1（查找）+ N（保存）。
且慢，我们的目标是什么？其实，这只是一个标记对象的过程，也就是一个更新表中一个字段的操作，解决问题的关键就在于如何写更新条件。更重要的是，如果这样做的话，一条SQL语句就可以搞定问题。
好吧！我承认，我是一个SQL白痴。但我可以找到人帮忙，于是，我请了一个DBA帮忙，果不其然，当DBA明白了这里的需求，很快就帮我们写出了所需的SQL语句。
当我们敲下回车的时候，瞬间操作就完成了。大于十分钟的操作，再见了！
无论如何，这个时间出现公司，绝对是一种异常现象，没办法，因为我们项目组要开IPM（Iteration Plan Meeting）。看着同事们惺忪的睡眼，我知道，他们的心情与我是类似的。
这么早来到公司开会，实在是不得已而为之，因为IPM通常要开两到三个小时，用以规划接下来一个迭代要做的事情，更重要的原因是，参加这个会的部分人与我们是隔“洋”相望，所以，我们的早上，对他们而言，是晚上。为了能让他们不致于熬夜到太晚，我们只好在早7点来开会。
在这个跨时区团队中已经工作了几个月，这是第一次真正在这样一个团队中工作。
每天早上Stand Up的时候，我们需要进入到电话会议系统中，在电话的那一段是我们这个团队的另外一部分，包括我们身在美国的同事以及我们的客户。我们相互介绍工作情况，有些需要特别注意的点，就会在这里彼此提醒。之后，他们放心地去睡觉，我们开始一天的工作。
我们普通的工作一天，通常是从Mingle——我们公司开发的一个敏捷项目管理工具——开始的。打开Mingle，我们通常会看到美国团队的工作成果。目前美国那边的同事主要负责一些分析和QA的工作，所以，他们的工作成果往往意味着用户一些需求的调整或是一些bug，这些都被记录在Mingle的卡上，我们会从中选取优先级比较高的卡来做。
之前有一段时间，美国团队有几个人进行开发，那段时间，我们每天早上要做的就是更新代码之后看一下diff，看看我们之前一天做了什么，还有他们在我们睡觉的时候做了什么。另外，我们在Mingle上还专门开辟一个页面，叫做Dev Standup，双方会把工作中遇到的问题记录在这里，以便另外一方知道发生了什么，有时，我们也会记录一些困惑，有相关经验的同事看到了就会给出自己的理解，所以，查看Dev Standup，也成了每天早上的工作之一。
结束一天的开发工作之前，我们要保证自己所有的测试能够通过，包括单元测试和验收测试。持续集成工具上的红色就是最危险的警告，它提示我们，这会给美国团队留下一个噩梦的开始。测试通过之后，我们还会部署一下UAT（User Acceptance Testing）环境进行部署，这样，不仅仅是我们的同事，我们的客户也可以看见我们辛勤一天的劳动成果。
无论如何，早上7点的IPM，是我在这个项目的一个巨大挑战。当然，按照公司通常的做法，早来可以早走，不过，今天不可以，因为晚上会有一个公司老大的Office Update，更重要的是，今天晚上还有公司内部的Wii网球比赛。
公司有个不成文的规定，在一个项目上工作一段时间之后，可以申请轮换，也就是说，可以申请去做别的项目。这样做的目的，防止长时间在一个项目上做下去产生厌烦心理。通常这个期限是三个月，当然，根据人员和项目的不同，会有所差别。
最近一段时间，我个人一直在做一些很短期的项目，一两个月的项目，所以，根本没有机会体验从项目中轮换的感觉。眼下的这个项目，如果按期结束，就已经过了三个月的期限，如果项目延长，那是不是要轮换呢？
有人希望轮换，因为期限已过，换到别的项目，或者开始一个新的项目，这样，可以丰富自己的体验，更重要的是，这个项目中最有价值的部分已经做完了，继续做下去，只能与那些价值不大的部分纠缠，这样，会显得比较无聊。
关于价值，我很认同这里的说法，但是，那些价值只是业务本身的价值。我们是除了要为客户带来价值，还要为自己增值。
在东软的时候，我曾经在一个项目上待了两年。两年时间里，我经历了那个项目从无到有，再不断进化的过程，那个项目是我在工作中投入最大的一个项目，我曾经为了能给它再做一个版本，在那个部门多待了一年。当然，它给我回报也是巨大的，它让我从一个毕业生成长为一个真正的程序员，它让我具备可以编写良好代码的能力，它让我对软件开发有了属于自己的认识，为我日后继续前进奠定了基础。
所以，我知道长期项目的价值。
需求变化是考验设计的真正标准，长期项目必然会经历需求变更，这会促使我们更好思考设计的正确性。
度过甜蜜阶段之后，项目才会暴露出各种各样的问题：管理、过程、人员等等，对这些问题的思考，可以帮助我们在日后的工作选择一个更好的路。
项目做长，早晚会遇到资源不足的情况，也就是需要所谓“优化”，而与有限资源做斗争是编程的一大乐趣。
长期项目往往伴随着人员变更，对个人而言，这通常意味着机会的来临。
……
所以，我希望做下去。
现在这个项目对我来说，也有很多特别之处：第一次做真正意义的Rails项目，也是第一次做Web开发；第一次和外国同事协同工作；第一次体验跨时区工作；第一次比较完整的体验敏捷软件开发； 第一次在项目中大量的扮演Coach的角色；第一次在Mac上写程序……
最初的那股新鲜劲已经过去了，我已经开始思考我在这个项目中遇到各种各样有趣的东西。更长时间的实践给为我的思考带来更多的依据，也可以让我更好的探索一些做事方法。
工作有两个维度，广度和深度。短期项目有助增加自己的广度，长期项目则让自己深入，其实，两个方面都是必要的。
昨天，一个同事跟我说，这块太乱了，做不动了。
两次，我做了相同的选择：重构。
重构和开发新功能在很多PM眼里一直是一对很难调和的矛盾。对于PM来说，来自客户的压力让他更关注项目的进展，而重构往往代表项目的原地踏步，只有开发新功能才是“正道”。放弃“正道”，选择看不见进展的重构，站在PM的角度上，这是难以接受的。
“破窗户”理论告诉我们，一旦置破烂于不理，其结果通常是烂得更多更快。
一个同事和我聊天时，提到了他正在做的一个系统，他们在开发的过程中发现了很多问题，很多bug改起来都非常困难。他们想重构，但是强势的PM坚持要开发新功能，于是，这些问题有幸在代码中继续生存下去。随着项目的进行，这些问题暴露得越来越明显，以致于有些问题已经成为项目继续开发新功能的障碍。当问题到了不得不进行修改时，发布的日期也逐渐临近了。
当我做出重构的选择时，我知道，我会失去对当前进度的控制。但我期望得到的是一个合理的设计，以此，后续的一些开发工作会得到大幅度加快，前面失去的进度后面在一定程度可以得到弥补。
几个月前，那段时间，项目进度如预期的慢了下来，但随着重构的进行，我对代码质量也逐渐的越来越有信心了。事实证明，项目后期出现了进度井喷的现象，原本耽误的进度到最后居然出现了提前完成。
这次，当我和那个同事讨论了新版设计之后，我从那个曾经失望的眼里看到了光芒。今天开始工作之前，项目组的所有开发人员又在一起重新讨论了这个新的设计，并进行了一些完善。于是，一个Pair开始采用这个新的设计方案进行编码。事实出乎意料的顺利，原本预计耽误很多的进度，在他们生花妙手的努力下，在今天下班之前，就将大部分赶了回来，让我着实惊讶于他们的开发速度。
从这几个项目的经验来看，重构，短期上在阻碍开发的进度，但是站在长期的角度，却可以大幅度提升软件开发速度，也提高了软件本身的质量，更重要的是，通过重构，解决掉一些原有实现中固有的缺点，可以将程序员从痛苦中解救出来。编程本应该是快乐的，不是吗？
忍无可忍，无须再忍，重构吧！
所以，我讲一些自身的经历。
说到QA，首先想起的便是测试。从我刚开始接触编程的时候，我就知道测试是必需的，否则，怎么能够知道自己写的程序是对的，就像考完试需要检查一下卷子一样。那个时候，除了了一些最基本的程序之外，我还写过一些有界面的Windows程序，于是，关于测试，留给我的第一印象就是点这点那，到处乱点。
工作之后，虽然知道了QA这个角色的存在，但很长一段时间都没有和QA在一起工作过，所以，客观的说，那段时间一直觉得QA是一种没有技术含量的工作。直到有一天，一个长时间没有QA的项目，能够卖钱了，领导觉得有必要提高产品质量了，于是派了个QA进到项目组。他是我后来的一个非常好的朋友，当时是部门QA方面的负责人。
我们的项目是一个服务器的应用，所以，从外部的角度来看，主要就是一个发起一个符合我们用到协议的消息包，然后看看得到的应答。其实，我一直对这个项目很有信心，因为它已经在一些地方上线运行了，而且从当时的情况来看，我们还算舒服，没有经常性的被客户从睡梦中叫醒。
QA进行的第一个测试就是发了空消息包，结果系统报错了。我第一反应是“你怎么能这么用”，是的，感情上有些接受不了，甚至有些气愤，我一向很有信心的代码，就这么非常轻松让人给弄崩溃了。稍微平静了一下，我觉得其实也没有什么大不了的，毕竟是自己的代码中真的有问题，所以才让人抓住。
经过一段时间，我越发深刻的认识到QA在项目中的作用，虽然我们在写代码的时候，已经考虑了很多的异常情况，但总还是有很多我们意料之外的情况被QA发现，随着项目的进行，发现和修改的bug越来越多，我们对自己的项目也越发有信心了，不过，回想起之前的代码，那样的产品质量也在线上运行了好长时间，多少有些后怕。
这时QA在我心目中，已经不再是那个没有技术含量的工种，我对QA开始充满了敬畏。真的是敬畏，尊敬和畏惧并存，敬的是他们总能给产品质量带来提升，畏的是他们总能不断在自己感到骄傲的代码中发现问题。和我们的QA聊过几次才知道，原来QA的工作也分验证性和破坏性的，原来他们的工作也是需要缜密思考的，原来他们的工作也是需要很详细的计划。突然发现自己曾经对QA的理解，基本上完全是门外汉的水平，误解是很让人郁闷的，就如同每每我说自己是做软件开发的，家里的邻居通常会说，什么时候有空帮我们家装台机器吧！
后来，我和这个QA兄弟一起跳槽到了另外一个部门。他的工作范围本质上说还是在QA的范畴。由于这个部门做的是偏研究性质的，所以，他的工作名义上称为验证，主要是看部门研发的算法有多大的进步。最开始的时候，一般是一周做一次验证，主要的原因就是因为运行加上总结需要很长的时间，于是，这位兄弟想办法开始把一些工作自动化，随着自动化程度的提高，验证周期也逐渐缩短，后来，我离开了这里，据说，现在这个自动化验证系统已经达到了很方便的程度，只要敲一下命令，它会自动部署到几台机器上运行，然后，搜集结果产生报表。就这样，原本一周一次的过程，简化到几乎随时可以做。如果让我选择这个部门产生出最有价值的东西，我会把票投给这个自动验证系统，甚至超过了部门研发的算法，只可惜养在深闺无人识。
为了讨论这个关于QA的话题，我问了自己一个问题，为什么QA能够想到我们开发人员想不到的地方。我自己给出的答案是，二者站的角度不一样。开发人员通常是站在实现的角度，所以，通常我们会更多的关注如何把这个功能做出来，也就是规定动作，而QA是站在用户的角度，如同我们自己使用软件通常是不会看软件使用手册一样，QA总会用到一些规定动作之外的用法，也就是自选动作，所以，二者之间必然存在一些差别。既然存在差异，QA发现一些自己无法发现的东西。
如同我之前对QA有一些误解，想必也有很多开发人员对QA也存在一些误解。所以，对于QA而言，增加与项目成员之间的沟通应该是一个很好澄清误解的方式。沟通，对于任何项目都很重要，不仅仅局限于开发人员和业务分析人员之间，QA也应该是这个沟通环节中重要的一部分。只要有可能，QA都应该是从项目最初介入，这样一方面保证了QA与项目成员之间在一开始就建立起良好的沟通环境，另一方面，他们的经验和技能可以保证大家在最初的阶段就注意到一些问题，正如我们QA Lead在Agile China所讲的一样，Build Quality In。
这个关于QA的话题的最后，再聊聊ThoughtWorks QA。作为一个ThoughtWorker，除了做好自己本职工作之外，我们也要把自己工作中总结出的好的方面告诉别人，无论是以文章、blog或是讲演的方式，所以，QA也不应该例外。
周末没有休息，和几个同事参与了一个类似于CodeJam的活动，两天做一个小系统，开发工具还是ROR。不同的是，这次是和客户的开发人员一起工作。
客户的开发人员之前没有接触过ROR开发，所以，这次活动开发的需求，可以说是小得不能再小了。与其说这个活动是为了开发这个系统，倒不如说是给他们进行一个展示，一方面，展示我们的工作方式，另一方面，展示ROR开发的威力。
最初，我并不了解和我们一起工作的这些开发人员的水平，所以，我以为主要的精力要放在开发上。等我真正开始工作，写上几行代码的时候，我才发现，对于这些从来没有了解过Ruby和Rails的人来说，就是简简单单的几行代码，也需要我用大量的口舌去解释。这时，我突然意识到，对这个项目而言，写多少代码其实已经变得不那么重要了，同他们的沟通，远要比写几行代码重要得多。
虽然和我们一起开发的这些人都有一些开发经验，但他们之前的工作经验并没有给他们提供像我们这样开发的机会，所以，需要解释的，不只是ROR的技术，更多的是一种工作方式。比如，第一天下午的时候，我几乎大多数时间是在和人解释测试，不是如何TDD，而是讨论为什么要做测试，以及测试和业务代码的关系。他们会问，我写完一个功能，刷一下页面，看看结果不就可以了，为什么要写测试，他们会问，测试代码在运行时起到怎样的作用，他们会问，如果测试不影响业务代码，我为什么要写它，等等。这个时候，我不得不把思路拉回到我刚刚接触这些概念的时候，给他们提供一个合理的解释。
总结的时候，这些开发人员普遍的感觉是大开眼界，这时，有一种自豪感在心底升起，正如gigix所说，这种一出手就能给人带来震动的感觉，很好。
这是一个非常好学的团队，在开发过程中，他们会不断提出各种各样的问题，因为我们所做的几乎一切都与他们原有的工作方式有着巨大的差异。两天时间，不仅仅是我，所有参与这次活动的ThoughtWorker都解释了大量的东西，以致于每天结束时，都会有一种口干舌燥的感觉。
不过，他们也有一些担心，如果我们离开，失去了我们的支持，他们该如何走下去。这是一个非常好，而且也非常现实的话题。这种开发方式在ThoughtWorks是一种理所当然，而在他们的开发团队，因为原有开发习惯在作祟，会让他们遇到很多问题。我们能够给出的，只是一部分建议，可能要他们更多的探索和坚持，以及也许日后与我们的进一步合作。
对于他们而言，这是改变的开始。
上周末，Agile
China，因为家里有些事，我没有参加。
作为一个ThoughtWorker，错过这次活动的遗憾并不是像之前以为的那么大。首先，这次活动所涉及到的内容，大多是内部讨论或是讲座涉及到的东西，再有，这次活动做得比较好的地方是很快就放出了活动的讲演稿和视频，所以，可以随后弥补一下错过现场的遗憾。
真正值得遗憾的是，错过了一次与人交流的机会。
有时，我会想，公司为什么要举办Agile
China这样的活动。在ThoughtWorks的工作这段时间，敏捷已经成为了一种工作习惯，我甚至不觉得它有任何特别的，对我而言，它只不过是一种恰当的工作方法而已。与很多书上介绍的敏捷方法，几乎没有太大的差别。
最近，一个朋友给我写了一封邮件，给我介绍了一些他心目中应该如何做持续集成，这是他读了一些东西加上了一些自己思考的结果。不过，在我看来，所有这些内容和我日常工作中使用的持续集成差别几乎没有。显然，当这些内容还停留在他思考中的时候，我们已经在实践了。显然，他对这方面的了解还是有些不足的。事实上，这位朋友也很愿意提高自己，只是周遭的环境能够给他的帮助太有限了。
和Darwin聊过，ThoughtWorks带给我们的并不是直接技术上的进步，而是为我们打开了一扇窗。与不同的人交流，会让我们拥有更开阔的视野，总有很多新鲜东西在等待我们了解。
还是那句话，敏捷不过是一种恰当的工作方式而已。对比于所谓的传统开发方式，敏捷给人的感觉是很不同，但如果真正在工作中使用它，消除了它的神秘面纱，也不过如此。但真正有多少人能在工作中使用。它这是一个问题。只读几本书，照着几个实践去做，就“敏捷”了吗？未必。看到很多人在抱怨敏捷，不过，很多说法都是想象或是教条的结果。
公司举办的Agile
China实际上是一种经验分享，告诉大家，我们在做什么。正如我前面所说，这些东西其实并不是什么新鲜东西，但对于不了解它的人来说，它就是新鲜东西。
闭塞，是阻碍人不断进步的绊脚石。
拜IE6所赐，我们的系统刚刚上线，便有一个bug浮出水面。经过验证，这是IE6处理直接打开附件（如PDF、PPT等）的错误。不过，好在这是一个广泛遇到的问题，使得这个bug连午饭时间都没有坚持到，便被消灭了。
按照对客户的承诺，我和另外一个同事要在办公室支持到晚上10点。上午的时候，我们的QA和客户努力了三个小时，并没有发现其它问题，于是，我们想当然的认为我们可以按“点”下班。就在我们俩准备收拾东西回家睡觉之前，从睡梦中醒来的客户终于发现了bug。于是，我们只好在深夜来临之际，开始了bug征服之旅。
有bug不是什么坏事，发现总是比不发现好。
在客户和PM压力之下修改代码并不是什么愉快的经历，好在bug们都是一些友好的家伙，很容易就定位到。不过，因为客户在线，所以，必须强迫自己把事情做得尽可能按部就班：本机测试、提交到主干、提交到分支、部署到测试环境……
感谢之前大家辛勤努力编写的测试，让我们很容易就知道自己的修改在系统内会造成怎样的影响。通过所有测试的那一刻，心头如释重负。在这个原本很是紧张的时候，多了一份自信。我喜欢这种感觉，虽然忙碌，但依然从容，一切尽在掌握之中。
这个无眠的夜里，身边还有自己的Pair，有专程赶来帮助我们进行验证的项目组的老大哥，当然，还有一直都很辛苦的PM，一个敬业的团队。
印象中，这应该是一个手忙脚乱的阶段，一大群人奔前跑后，忙着处理各种各样的问题，尤其是bug。许多人回忆自己经历的时候，往往会很有成就感的说，在某某程序发布之前，忙了一整夜，终于在程序发布之后，回到家里，一觉睡了N个小时，俨然一副历经沧桑的样子。自己经过的，既有有过连续十几天工作十几个小时，为了赶上发布日的经历，也有连续几个熬到后半夜改bug的痛苦。虽然这些都是不错的日后谈资，但当时，那是透支的感觉。
现在，我在等待发布。
是的，等待！
Story的开发工作早就已经完成，bug修改也到了尾声。代码已经冻结，Mingle上可供开发的卡已无踪影，有一种闲暇无聊的感觉。
这已经不是第一次体验发布前的闲暇了。记忆中，最近做过的几个项目，到了最后的几天，都会出现无卡可做的情况。最极端的是有一次，在PM的陪伴之下，打了多半天的游戏。
对比之前的经历，这样的经历显得很特别。原本在我的印象中，越是临近发布，应该越是忙碌，而这种一下子闲下来的感觉，真的是让人有些不适应。
这个时候，PM就成了给大家找事的人。比如，他会组织大家进行一些讨论，看看之前那些做得好，做得不好，以便在后续的工作中进行改进。比如，他会把一些属于下一个阶段的任务拿过来，让大家分析一下，提前热热身，有些手快的家伙，甚至会顺便把一些任务做完。
这样难得的清闲，多半要归功于合理的计划和控制。其实，想想之前的经历，最终期限并不是合理规划出来的。事实上，大多数情况下，对于要做什么，以及这些工作的工作量究竟有多大，并没有很好的估计，所以，往往就是指定一个发布的日期，剩下的就是靠人了，其结果就是为了赶上发布日期，拼命的加班加点，那种透支需要很长一段时间才能恢复过来。
而现在做项目，所要做的一切都是经过大家一起估计出来，包括客户和开发团队，大家对于软件开发的实质认识得比较清楚，所以，不会做一些杀鸡取卵的事情，于是，所有的一切，都会按照预期一步步进行：开发团队也不会为了追赶进度，而损失了软件的内在质量；客户会重新认识他需求的价值所在，做好优先级排序，而不会不明就里的要求全部完成。这是一个合理的开发过程，一种软件开发应有的状态。
准备发布了！
