• 2008-07-26

    一较短长

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

    眼下正在做的项目有希望延长,对于这个结果,有人欢喜有人忧。

    公司有个不成文的规定,在一个项目上工作一段时间之后,可以申请轮换,也就是说,可以申请去做别的项目。这样做的目的,防止长时间在一个项目上做下去产生厌烦心理。通常这个期限是三个月,当然,根据人员和项目的不同,会有所差别。

    最近一段时间,我个人一直在做一些很短期的项目,一两个月的项目,所以,根本没有机会体验从项目中轮换的感觉。眼下的这个项目,如果按期结束,就已经过了三个月的期限,如果项目延长,那是不是要轮换呢?

    有人希望轮换,因为期限已过,换到别的项目,或者开始一个新的项目,这样,可以丰富自己的体验,更重要的是,这个项目中最有价值的部分已经做完了,继续做下去,只能与那些价值不大的部分纠缠,这样,会显得比较无聊。

    关于价值,我很认同这里的说法,但是,那些价值只是业务本身的价值。我们是除了要为客户带来价值,还要为自己增值。

    在东软的时候,我曾经在一个项目上待了两年。两年时间里,我经历了那个项目从无到有,再不断进化的过程,那个项目是我在工作中投入最大的一个项目,我曾经为了能给它再做一个版本,在那个部门多待了一年。当然,它给我回报也是巨大的,它让我从一个毕业生成长为一个真正的程序员,它让我具备可以编写良好代码的能力,它让我对软件开发有了属于自己的认识,为我日后继续前进奠定了基础。

    所以,我知道长期项目的价值。

    需求变化是考验设计的真正标准,长期项目必然会经历需求变更,这会促使我们更好思考设计的正确性。
    度过甜蜜阶段之后,项目才会暴露出各种各样的问题:管理、过程、人员等等,对这些问题的思考,可以帮助我们在日后的工作选择一个更好的路。
    项目做长,早晚会遇到资源不足的情况,也就是需要所谓“优化”,而与有限资源做斗争是编程的一大乐趣。
    长期项目往往伴随着人员变更,对个人而言,这通常意味着机会的来临。
    ……

    所以,我希望做下去。

    现在这个项目对我来说,也有很多特别之处:第一次做真正意义的Rails项目,也是第一次做Web开发;第一次和外国同事协同工作;第一次体验跨时区工作;第一次比较完整的体验敏捷软件开发; 第一次在项目中大量的扮演Coach的角色;第一次在Mac上写程序……

    最初的那股新鲜劲已经过去了,我已经开始思考我在这个项目中遇到各种各样有趣的东西。更长时间的实践给为我的思考带来更多的依据,也可以让我更好的探索一些做事方法。

    工作有两个维度,广度和深度。短期项目有助增加自己的广度,长期项目则让自己深入,其实,两个方面都是必要的。
    分享到:

    历史上的今天:

    旧瓶装新酒 2012-07-26
    引用地址:

    评论

  • 更准确的说 : 需求变化是改善设计的良机, 而不是考验设计的标准 。

    否则,你必须苦思冥想以得到一个可以应对各种变化的设计,结果呢?绝大多数变化并没有发生,over-design.

    老马同志已经在他的《重构》里叙述了自己在这个问题上经验教训,这也正是简单设计和重构的价值所在。
  • 个人感觉,不管是长期做一个项目,还是短期做多个项目,关键部分是你寻找到令你敢兴趣的东西,并把他们做好。产生厌烦的原因恰是无法寻找到新的突破口。
  • "需求变化是考验设计的真正标准"

    这个确实是如此。但是在如何应付需求变化这个问题上,一般有两种做法,一种是优秀、有前瞻性的设计;一种是就目前需求进行设计,需求变更再做重构。

    这两种做法似乎都有各自的优缺点,第一种严重依赖于设计者的经验和能力,存在较高的风险,over-design危害众多;第二种没有over-design的风险,但是对代码的修改可能是伤筋动骨的,依赖于重构者的责任心和水平,否则代码将慢慢地难以维护。

    不知dreamhead对此有何经验和看法 呵呵
    回复Leo说:
    无论如何,设计和实现会在很大程度上依赖于人。

    设计不是错,之所以不提倡over-design,是不要做过度的考虑,而不是指不要设计。过度的考虑,往往是意味着做了很多假设,而这些假设会把系统变得不必要的复杂。我们在开发的时候,也会做设计,遇到一些影响会比较大的修改,就会一些人先在一起讨论一下。

    做在可见范围内最有效的事情。
    2008-07-31 23:52:36
  • 个人与项目共同成长