• 2008-07-07

    另一个CodeJam

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/24310683.html

    关于CodeJAM的那篇blog中,我写道,希望将来有机会把这个面扩大一些,让其他公司的人来和我们一起来做。

    周末没有休息,和几个同事参与了一个类似于CodeJam的活动,两天做一个小系统,开发工具还是ROR。不同的是,这次是和客户的开发人员一起工作。

    客户的开发人员之前没有接触过ROR开发,所以,这次活动开发的需求,可以说是小得不能再小了。与其说这个活动是为了开发这个系统,倒不如说是给他们进行一个展示,一方面,展示我们的工作方式,另一方面,展示ROR开发的威力。

    最初,我并不了解和我们一起工作的这些开发人员的水平,所以,我以为主要的精力要放在开发上。等我真正开始工作,写上几行代码的时候,我才发现,对于这些从来没有了解过Ruby和Rails的人来说,就是简简单单的几行代码,也需要我用大量的口舌去解释。这时,我突然意识到,对这个项目而言,写多少代码其实已经变得不那么重要了,同他们的沟通,远要比写几行代码重要得多。

    虽然和我们一起开发的这些人都有一些开发经验,但他们之前的工作经验并没有给他们提供像我们这样开发的机会,所以,需要解释的,不只是ROR的技术,更多的是一种工作方式。比如,第一天下午的时候,我几乎大多数时间是在和人解释测试,不是如何TDD,而是讨论为什么要做测试,以及测试和业务代码的关系。他们会问,我写完一个功能,刷一下页面,看看结果不就可以了,为什么要写测试,他们会问,测试代码在运行时起到怎样的作用,他们会问,如果测试不影响业务代码,我为什么要写它,等等。这个时候,我不得不把思路拉回到我刚刚接触这些概念的时候,给他们提供一个合理的解释。

    总结的时候,这些开发人员普遍的感觉是大开眼界,这时,有一种自豪感在心底升起,正如gigix所说,这种一出手就能给人带来震动的感觉,很好。

    这是一个非常好学的团队,在开发过程中,他们会不断提出各种各样的问题,因为我们所做的几乎一切都与他们原有的工作方式有着巨大的差异。两天时间,不仅仅是我,所有参与这次活动的ThoughtWorker都解释了大量的东西,以致于每天结束时,都会有一种口干舌燥的感觉。

    不过,他们也有一些担心,如果我们离开,失去了我们的支持,他们该如何走下去。这是一个非常好,而且也非常现实的话题。这种开发方式在ThoughtWorks是一种理所当然,而在他们的开发团队,因为原有开发习惯在作祟,会让他们遇到很多问题。我们能够给出的,只是一部分建议,可能要他们更多的探索和坚持,以及也许日后与我们的进一步合作。

    对于他们而言,这是改变的开始。
    分享到:
    引用地址:

    评论

  • 请问你们基于ror的项目有使用JRuby吗,在一本书上看到说TW在基于ROR的项目中使用JRuby
    回复bluegene.hao说:
    我们确实有基于JRuby的项目,比如Mingle,但我们这个项目里面采用的是MRI。
    2008-07-09 23:29:19
  • TW的工作方式确实不容易复制
    像我,做C/C++的,社区文化是一个重大阻塞
    同事可以认同unit test,却不能认同为了unit test而把接口改造成虚函数的前提
  • 最后才是症结所在。TW的方式不容易复制。