• 2009-09-30

    没有困难,制造困难

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

    有困难要上,没有困难制造困难也要上。相声中的段子在软件开发团队中真实的上演着!

    改进持续集成

    要敏捷,要做持续集成。于是,有人想,如果能够把一些常见的操作(比如编译)替大家做好,省去了每个项目组配置的工作量,那该多好啊!于是,投人投时间,就着CruiseControl改出来一个新版本。

    事实是,得到了一个看上去很美的可配置环境,而很多使用这个环境的项目组压根没有一键式脚本,直接把代码提交到进去,交给服务器来处理,顺便说一下,这个持续集成环境几个小时才运行一次,也就是说,写一行代码,也许几个小时以后才知道是不是能够编译通过。持续集成完全起不到应有的作用。

    其实,只要把一键式脚本写好,配置持续集成很简单。

    编写自动化测试工具

    自动化测试很重要。于是,有人想,应该有一个自动化测试工具用来编写自动化测试。于是,投人投时间,编写了一个强大的自动化工具,甚至拥有一个漂亮的IDE。

    事实是,这个工具运行起来,基本上需要占据2G内存,而很多开发人员开发人员的机器只有512M内存;编写测试的语言算是一种DSL,很特定于领域,没有人知道怎么用好它;这个为编写测试而生的工具,居然没有常规的Assert,没有setUp和tearDown;开发人员很少愿意用这个工具。

    其实,如果用脚本语言封装一下,很多现成的工具和框架都很可以使用。

    打造开发框架

    重用很重要。于是,有人想,应该构建一个统一的平台,让所有团队采用同样的机制去编写代码,减少开发和维护的工作量。于是,投人投时间,做出了一个开发框架,号称开发团队只要编写少量的代码就可以完成功能。

    事实是,一些很适合用B/S结构的应用因为这个框架变成了C/S结构;这个框架采用二进制的格式作为通信协议,让通信过程变得神秘无比;放着许多现成稳定的服务端应用不用,自己编写了一个。

    其实,就Web应用而言,太多现成的东西可用了。

    分享到:

    历史上的今天:

    引用地址:

    评论

  • 我们公司应用了两个开发框架:普元EOS,用友的UAP。是存在博主说的“打造开发框架”造成的三个问题。
    但是也有优点,这种框架优点是屏蔽底层通信技术,让项目人员更注重业务。感觉这是方向,不要求所有开发者通透技术,过多时间放在代码开发上,将重点放在业务理解上及测试上。
    回复helloqidi说:
    我并不反对构造框架,甚至我喜欢构造框架,从而简化开发。

    但是,是不是这些构造出来的框架真的能够达到简化开发的目的呢?是不是构造出来的框架是合理的呢?是不是构造出来的框架可以给开发人员一个恰当的指引呢?这是个问题。

    我之所以把blog中的那个框架评价为没有困难,制造困难,是因为它完全把开发人员引到了错误的路上。

    至于普元EOS和用友的UAP,我不了解,没资格评价。
    2009-10-12 23:21:20