西西河

主题:【原创】闲聊敏捷编程——测试驱动开发(一) -- 代码ABC

共:💬55 🌺131
分页树展主题 · 全看首页 上页
/ 4
下页 末页
      • 家园 敏捷是一个原则,可以有不同的实现方法

        总结这个过程,小羊的心得是————要想玩儿的爽,客户要配合,需要客户配合,就得让客户有热情,要让客户有热情,关键是快速的需求——实现反馈

        这里就体现了敏捷的两个原则:合作与沟通。

      • 家园 可是这么干的话,大一点的项目就不成了吧

        1。文档没有,回头客户一拍脑袋不认帐。

        2。规模稍微大一点,多个客户的需求各有想法,冲突在所难免。

        3。大一点的系统,客户所需要花的时间也不少,尤其是测试这一块。

        • 家园 大一点的系统,小羊也存在疑虑

          而且不光是我,兄弟们也是这样,我们目前还坚持这样的做法,主要原因在于

          1、目前我们用这种方法操作过的项目,最大的是一套OA,周期是半年,运作的很好,如果有更大的方法,我们也非常愿意试试看。

          2、从客户的反馈看,以前经常头疼的需求分析问题和纠纷居然神奇的消失了,我们总结是在开发的过程中就消解了。

          至于您的几个问题,小羊斗胆回复:

          1。文档没有,回头客户一拍脑袋不认帐。

          文档还是有的,每个环节完成的工作都会形成文档交付客户确认,就是怕客户不认帐,不过从实践看,基本就是轰轰烈烈走过场,认认真真搞形式了,因为这些工作是和客户一起完成的,还没碰到客户否定自己的,至于过段时间拍脑袋不认帐的,这事儿得分两头说,真是恶意的,没辙,要是确系当时没想明白的,快速原型法恰恰避免了这个问题,在建模修正的过程中,用户也在一步一步完善和修正自己的看法,即便是后面有遗漏,也不多了。

          2。规模稍微大一点,多个客户的需求各有想法,冲突在所难免。

          巧了,我们的OA项目,也存在多个功能模块,我们干脆把项目组也拆了,每组跟一个,每日完成的原型开会讨论,结果————客户自己干起来了,这个呵呵,俺们不管,直接回避,第二天,他们就有统一结果了。

          3。大一点的系统,客户所需要花的时间也不少,尤其是测试这一块。

          何止不少阿,简直超长,我们直接把这段时间称做上线试运行,哈哈。

      • 家园 您这个就是一般的方法吧,算是敏捷吗?

        系统设计的好,需求变化的压力自然分散到了各个开发节点,但是如果客户不按常理出牌,不断新增需求,还是受不了的。

        • 家园 碰上不按照常理出牌的,神仙也没办法

          小羊觉得,不管是瀑布还是敏捷,目标都是按照常理出牌的客户,区别仅在于需求获取和响应的方法上面,如果碰上了捣蛋的客户,软件工程没办法解决,得靠社会工程了,嘿嘿

    • 家园 谈一下自己的想法

      在下也搞过敏捷开发,当时老大就让我们写代码前先写测试用例,号称测试驱动开发,说实在的我也不知道这个定义对不对,但还是老老实实按这个去做了,实践中发现它确实有效,你想想,测试用例比代码还先完成,测试员必然要仔细整理自己的思路,不容易出现以前那种需求和功能不一致的情况,而且每写一点代码都是通过测试的,代码质量比较高。不过,发现了两个问题,罗列如下:

      1.特别的费时费力,既要写代码又要写测试例,工作量是以前的两倍(其实还不止),虽然提高了代码质量,但这是以加班时间换取的,投入产出比没有仔细算过,但那段时间公司的弟兄们叫苦连天那是真的。

      2.测试例集中在单元测试方面,缺少集成和系统的测试。也就是说大家写的单个函数基本上都没有问题,但是联合在一起运行的时候就出问题了,不是接口格式错,就是类型不匹配。一通大改以后,好不容易可以集成运行了,可大家对这个程序还是缺乏信心,还需要专职qa的介入。而且感觉这个问题在不做测试驱动开发的时候还不突出,反倒是推行了新的工作模型后才集中出现,我想可能还是因为写测试例的过程耗费了大家太多精力,无力去关注接口和集成方面吧。

      • 家园 tdd可以节约大量用于调试问题的时间

        软件开发大部分时间都浪费在找错上。这个角度来看,应该更节约时间才对。

        现在一看到喜欢debug的程序员就头痛,很浪费时间。除非是框架技术限制,或者为了看懂别人的代码,调试都是很浪费时间的。

        • 家园 虽然单元测试可以对单个模块达到很好的测试覆盖率

          但是集成测试是比较容易忽略的,TDD在这方面并没有更好的效果。更何况写单元测试的时间不比实现测试对象的时间少多少。所以TDD并非节约时间,而是尽早发现错误,并且可以在开发早期重构代码,提高质量。

      • 家园 其实是很有效率的

        先写测试再写程序其实是最有效率的写法了。

        我做工程的时候,以前不懂这个。最后测试的满头包,debug还很困难。

        另外,接口什么的,不是应该在一开始就协调好吗?

      • 家园 这个是很多人一开始容易犯的错误

        后面会讲到,核心是一点测试也是设计,在写测试前必须考虑如何把代码写得方便测试。其结果就是要设计好接口。

        速度问题也有点复杂,如果你把测试代码花的时间作为一种投资来看的话,那就能明白TDD和敏捷的主要思路了。

        另外,测试驱动开发不止单元测试,还包括集成、系统层次的测试,这些也是必不可少的。

    • 家园 花催下文

      现在敏捷方法是软件工程学的热门话题,但传统的瀑布模型仍然是主流的开发方法,希望楼主能谈一下两种方法各自的优缺点和适用范围。

      • 家园 适用范围理论上没区别

        因为都是软件开发组织的方法论。优缺点比较就复杂了,我个人感觉是和用户的合作是敏捷的一个软肋,一方面它颠覆了不少以往的经验,另一方面对客户合作的要求很高。还有很多,容我慢慢说明

    • 家园 花,明白点测试驱动的味道了,不过思维的转变难啊

      又得一个10年

分页树展主题 · 全看首页 上页
/ 4
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河