一段弱智代码引发的一些思考（我们是不是该进行BDD了？）

 

声明：此处想得到问题背后的一些事情，对自动代码检查和自动测试有经验的大哥欢迎拍砖！

 

 

 

昨天发了一篇【你会犯这个失误吗？？还有更好的重构吗？？】"http://www.iteye.com/topic/1122257" （被评了新手帖，做了一遍iteye的那个选择题）  犯的问题确实很弱智，但确实是犯了。

 

因此我需要反思一下，还有一起讨论下我们应该如何强制自己不犯这些失误。

 

===========还是如下代码============

 

if(saleOrderList.size() > 0 && saleOrderList.get(0).getOrderUuid() > 0 & saleOrderList.get(0).getOrder().getState() == OrderStateEnum.wait_pay) {
            ActionContext.getContext().put("orderUuid", saleOrderList.get(0).getOrderUuid());
            return "redirectToPay";
}

 

前置条件 

1、saleOrderList永远不为null 

2、saleOrderList.get(0).getOrderUuid() 如果 等于 0  表示 没有订单  ，，，即  saleOrderList.get(0).getOrder() 将返回null

 

失误：

“&&” 写成了 “&”

 

如上代码确实看着很恶心，问题：

1、异常堆栈信息很难判断出问题所在，因为异常堆栈中只告诉 哪一行 什么异常，不会具体告诉你是谁的错误；

2、debug，我承认 我很少debug，但debug只是发现错误的一种手段，不能预防错误（而且不能回归debug）；

3、单元测试，只有服务层和重要的表现层才有，这段代码也没有（有了单元测试，我们可以预防错误，而且能回归测试）。

 

但如上代码我认为是代码量较少的代码。

 

==================因此我重构了一下为如下代码==========

 

 private boolean canPay(List<SaleOrderModel> saleOrderList) {
        if (CollectionUtils.isEmpty(saleOrderList)) {
            return false;
        }
        SaleOrderModel saleOrder = saleOrderList.get(0);
        if (saleOrder.getOrderUuid() <= 0) {
            return false;
        }
        if (saleOrder.getOrder().getState() != OrderStateEnum.wait_pay.getType()) {
            return false;
        }
        return true;
    }

     

 

如上判断代码更好的表述了我的目的。

 

此处我想表达的不是谁的好谁的坏，而是如何保证所有队员都能按照一致的约定编程？如使用checkstyle等工具自动化的检查。想学习一下相关的经验。

 

对比：

1、第一段代码 量较小，计算机可读，但人读起来很费劲，因此“人不可读的代码不可维护”

2、第二段代码 量比较大， 而且只有一层条件， 人可读， 因此“人可读代码好维护”

 

那你是喜欢快（代码量较小），还是可读可维护呢？ 

很明显，大家都喜欢 第二种形式，那为什么我还会犯呢？？

那大家都能写出可读可维护的代码吗？

 

如果不能何种原因呢？我分析下我的原因仅供参考。

 

原因：

1、自认为会了的心理，这种问题是小菜；

    自认为会了，这种心理，需要什么方式来避免呢？？   -------------- 单元测试？ 代码分析？

2、没有单元测试；

    要求团队必须写单元测试？？ --------------------什么用例该写呢？

3、没有良好的编码规范制约。

    可以通过checkstyle等工具来解决这个问题。

 

 

结论：

1、程序员的意识很重要，你再牛没有良好的意识，也会犯错误。

2、写人可读的代码，而不是计算机可读的代码。

3、if条件尽量短，而且尽量一层，不要嵌套。

4、制定编码规范，强制队员检查自己的代码。

5、单元测试，而且一定要自动化的。

6、单元测试不允许有Ignore的，有应该提交申请，采用制度强制。

 

 

7、debug只是发现错误的一种手段，不能预防错误（而且不能回归debug）；单元测试，可以预防错误，而且能回归测试，因此应该写单元测试。

 

 

思考：还有更好的方式能避免吗？？

 

我认为  团队习惯 决定了 你的大部分习惯，团队的制度 决定了 你的大部分制度。 不是每个人都是优秀的程序员，因此需要制度等手段来强制程序员按照比较正确的路走，而不是见路就走。

 

 

新的问题：

工具、框架 需求相对稳定，而应用程序 需求可能随时变化，那应该如何进行单元测试呢？

1、工具、框架 应该进行单元测试吗？ 哪些组件及如何进行单元测试？

     它们相对来说 需求稳定，而且尽量对所有组件进行单元测试，如spring框架 做的相当好。 TDD吗？

2、应用程序 应该进行单元测试吗？  哪些组件及如何进行单元测试？

     但应用程序 需求可能随时会变而且变化会很大，那应该进行单元测试吗？及何时进行单元测试？单元测试应该如何应对随时变化的需求呢？ BDD吗？

 

 

应用程序大部分重点在需求（业务），因此应该以需求为导向，主导的测试应该进行BDD开发，而不是TDD。

 

TDD只对应用程序中比较重要的模块等进行单元测试（缩短发现组件缺陷到修复组件缺陷的时间）！！

BDD进行业务的 given when then 测试（发现需求缺陷到修改需求缺陷的时间）！！

 

是不是我们这帮应用程序开发人员 应该 关注 BDD啦 而不是TDD？？？不要再迷恋TDD啦！

 

文章主要是为了抛砖引玉，希望有更多牛人的指点。

一同事写了个window.location.href="....?XXOO=1&&eql=1";

这个还真没试过 会出现什么问题？

警告: Parameters: Invalid chunk ignored.
兄弟你一眼还没看出问题所在看来你WEB搞得不多哇

奥，够强啊

“..?XXOO=1&&eql=1”???

场景我知道是不符合规范的，这些都是警告（程序员没按照规范写，写错了）

那应该如何避免这些问题呢？

亮他的XXOO

…………………… 敢问 他们 同事 为什么 写  XXOO

他们公司做的什么性质的网站，我很有兴趣！