代码改变世界

朝得银弹,夕死可矣!

2004-06-04 00:49 FantasySoft 阅读(...) 评论(...) 编辑 收藏
        孔子云:朝闻道,夕死可矣! 我想说,朝得银弹,夕死可矣!可是,有银弹吗?没有!

        虽然我步入软件开发行业才半年有余,但是却有幸参与了一个开发团队有80多人的大型项目的开发。作为一个初出茅庐者,本该抱着学习的心态,学习项目成功的经验,可是我却在挫败的痛苦不断地总结,不断的幻想。通过这半年多的开发体验,我得出了一个结论:项目中的人的因素是最重要,而作为项目管理者,能够打造一个让程序员觉得爽的开发流程,能够在实际开发当中给予开发人员以具有指导性的建议,才是成功的。 

        我所期待的开发团队是这样的:
        1.作为系统分析人员(System Analyst),除了要从商业逻辑上把握,还要能够从技术上做整体把握。 他们需要对整个系统做详尽的分析与设计,要考虑模块之间的关系,也考虑如何构造对象,说到底,就是得有大局观。把握需求的分析人员,应该参与到实际开发中来,写UT Case就是他们的任务,这样他们就没有办法逃脱写Code了,就可以真正让自己跟开发人员打成一片,而且也能够把握好需求。除此以外,SA还要负责对技术的整体把握,他需要在不同的实现方式上做出抉择,而不是放任自流。
        2.作为高级开发人员(Advance Programmer),除了要熟悉某个模块的商业逻辑,还要为Programmer继续完备UT Case,因为SA所写的UT Case可能更多是覆盖Business Logic,而AP而要从系统实现角度上去完善这些Case。同时,他们需要对整个模块进行设计,关注与其他模块的接口,同时重要的商业逻辑由他们来做Coding和Test,并且给予Programmer以足够的支持。
        3.作为开发人员(Programmer),除了要严格按照业务逻辑的要求去做好Coding之外,还要能够懂得做好代码的优化,善于总结良好的Develop Style,并且及时与其他开发人员Share。

        我所期待的开发过程是这样的:
        SA做好整体设计,针对业务逻辑写好UT Case —> AP 继续完善 UT Case,并实现核心业务逻辑 —> Programmer 根据所有的UT Case进行开发

        这样的流程最大的好处就是目标明确,分工明晰,避免了有人只说话不做事。至少Programmer知道自己要做的就是让这些UT Case都通过,SA通过写UT Case去保证业务逻辑的完备性。

        聪明的你们或许会发现怎么没有提到文档呢?呵呵,在我看来,这些完善的UT Case就是文档,而且开发团队需要的是一份能够充分阐述业务逻辑的文档,在我们的项目中就是LPS(Logical Processing Specification)。我想只需要这个就足够了。可惜的是,我们在开发过程中还要写AMDS(Application Module Design Specification) 和 APCS(Application Program Class Specification)。多么纷繁复杂啊,然后这些文档和代码之间的一致性如何保证呢? 
      
        我多想奋臂疾呼:给我们一个觉得爽的开发流程!