|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-03-31
最后修改：2012-03-31
icelander 写道 jinnianshilongnian 写道 icelander 写道 一个方法里最好只有一个return
当然 越少越好，但实际可能吗？ 这很难吗，编程规范最基本的东西 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;
}
private boolean canPay(List<SaleOrderModel> saleOrderList) {
boolean canPay = true;
if (CollectionUtils.isEmpty(saleOrderList)) {
canPay = false;
}
SaleOrderModel saleOrder = saleOrderList.get(0);
if (saleOrder.getOrderUuid() <= 0) {
canPay = false;
}
if (saleOrder.getOrder().getState() != OrderStateEnum.wait_pay.getType()) {
canPay = false;
}
return canPay;
} 你这样可能会有问题 SaleOrderModel saleOrder = saleOrderList.get(0); if (saleOrder.getOrderUuid() <= 0) { canPay = false; } //此处如果saleOrder.getOrderUuid() <= 0 saleOrder.getOrder()将为null if (saleOrder.getOrder().getState() != OrderStateEnum.wait_pay.getType()) { canPay = false; } 编码规范我懂， 但我想要背后的事情，我很懒 我不想去记编码规范------- 我们需要工具来帮我们检查代码的规范！ 我想听一些代码分析的建议。对不？ |
| 返回顶楼 | |
|
发表时间：2012-04-01
最大的问题还是在于个人编程习惯，也就是格式化代码这块，使你的条件判断清晰起来，我一向都是要求我的组员按照我的这种方式来格式化代码，而不是一味的使用的alt+shift+f。
if(
saleOrderList.size() == 0
&&
saleOrderList.get(0).getOrderUuid <=0
&&
saleOrder.getOrder().getState() != OrderStateEnum.wait_pay.getType())
){
ActionContext.getContext().put("orderUuid", saleOrderList.get(0).getOrderUuid());
return "redirectToPay";
}
并不是一味追求重构，要善于利用重构里面的“招式”，像楼主那样之后的重构只是无疑导致代码另外一种坏味道——“过长函数” 以上仅仅是我个人的一点见解。 |
| 返回顶楼 | |
|
发表时间：2012-04-01
言日星极 写道 最大的问题还是在于个人编程习惯，也就是格式化代码这块，使你的条件判断清晰起来，我一向都是要求我的组员按照我的这种方式来格式化代码，而不是一味的使用的alt+shift+f。
if(
saleOrderList.size() == 0
&&
saleOrderList.get(0).getOrderUuid <=0
&&
saleOrder.getOrder().getState() != OrderStateEnum.wait_pay.getType())
){
ActionContext.getContext().put("orderUuid", saleOrderList.get(0).getOrderUuid());
return "redirectToPay";
}
并不是一味追求重构，要善于利用重构里面的“招式”，像楼主那样之后的重构只是无疑导致代码另外一种坏味道——“过长函数” 以上仅仅是我个人的一点见解。 自动格式化我也不推荐，这种方式是死的！可能并不能很好的符合团队的习惯！ “过长函数” 我们定义是超过80行才是过长的函数 我想表达的不是谁的好谁的坏，而是如何保证所有队员都能按照一致的约定编程？如使用checkstyle等工具自动化的检查。想学习一下相关的经验。 |
| 返回顶楼 | |
|
发表时间：2012-04-01
chrhust 写道 saleOrder.getOrder().getState()这种我一般分开写，
Order order = saleOrder.getOrder(); if(order!=null && order.getState()...)虽然觉得很麻烦 这样子，程序执行的步程数少很多！！！ 
|
| 返回顶楼 | |
|
发表时间：2012-04-01
jinnianshilongnian 写道 youarestupid 写道 devroller2 写道 devroller2 写道 lz你的if条件并不是很难理解，原因是只有&&，人理解还是比较容易，所以你的第一个方法是可行的。
那种既包含&&又包含||、（）的，让人读了半天绕不过来的才需要重构，否则格式化一下代码就可以了。 当然，你项目中有很多相同的这段逻辑，那么重构为一个方法是一定的。 楼主重构的思路是正确的，楼主的第一段例子代码中，即使不把&&写错成&，也是很不好的一种写法，因为，那段代码的主要问题不是因为if()条件太长，也不是因为条件内夹杂了&& 和 ||，而是在同一个if()条件内混合了不同层次的条件判断，像这种场景是应该进行楼主第二段的重构的。 我们水平再高，也避免不了犯错误。 一下是我的思考与问题： 工具、框架 需求相对稳定，而应用程序 需求可能随时变化，那应该如何进行单元测试呢？ 1、工具、框架 应该进行单元测试吗？ 哪些组件及如何进行单元测试？ 它们相对来说 需求稳定，而且尽量对所有组件进行单元测试，如spring框架 做的相当好。 TDD吗？ 2、应用程序 应该进行单元测试吗？ 哪些组件及如何进行单元测试？ 但应用程序 需求可能随时会变而且变化会很大，那应该进行单元测试吗？及何时进行单元测试？单元测试应该如何应对随时变化的需求呢？ BDD吗？ 一起讨论下！ 工具、框架、应用程序 应该分别如何写单元测试 来避免我们遇到的问题 你理解错也！工具、框架和应用程序都是由代码组成的，思想和方法都是一样的。他们有很多共性，比如需求的的变化。你应该用框架的设计思想和方法应用到你的应用程序中去。应用程序只不过是在某个业务领域内的专业软件，他们也有稳定需求的地方，那么你把这些稳定需求设计到所谓的“应用程序框架”中去，把不稳定的抽象出来，那就能适应需求的不断变化。像框架spring，它的定位是面向非常广阔的业务领域，那些公共的基础设施（ioc、事务管理等）是它的稳定需求，所以spring实现的时候把他们纳入框架中。spring做的好，也不是它用了什么TDD的方法，而是它的定位和设计。一个软件的好坏应该看它的定位和是否有可维护性、可扩展性。 |
| 返回顶楼 | |
|
发表时间：2012-04-01
wo ca 又是这哥们，又是一对字。
|
| 返回顶楼 | |
|
发表时间：2012-04-01
devroller2 写道 jinnianshilongnian 写道 youarestupid 写道 devroller2 写道 devroller2 写道 lz你的if条件并不是很难理解，原因是只有&&，人理解还是比较容易，所以你的第一个方法是可行的。
那种既包含&&又包含||、（）的，让人读了半天绕不过来的才需要重构，否则格式化一下代码就可以了。 当然，你项目中有很多相同的这段逻辑，那么重构为一个方法是一定的。 楼主重构的思路是正确的，楼主的第一段例子代码中，即使不把&&写错成&，也是很不好的一种写法，因为，那段代码的主要问题不是因为if()条件太长，也不是因为条件内夹杂了&& 和 ||，而是在同一个if()条件内混合了不同层次的条件判断，像这种场景是应该进行楼主第二段的重构的。 我们水平再高，也避免不了犯错误。 一下是我的思考与问题： 工具、框架 需求相对稳定，而应用程序 需求可能随时变化，那应该如何进行单元测试呢？ 1、工具、框架 应该进行单元测试吗？ 哪些组件及如何进行单元测试？ 它们相对来说 需求稳定，而且尽量对所有组件进行单元测试，如spring框架 做的相当好。 TDD吗？ 2、应用程序 应该进行单元测试吗？ 哪些组件及如何进行单元测试？ 但应用程序 需求可能随时会变而且变化会很大，那应该进行单元测试吗？及何时进行单元测试？单元测试应该如何应对随时变化的需求呢？ BDD吗？ 一起讨论下！ 工具、框架、应用程序 应该分别如何写单元测试 来避免我们遇到的问题 你理解错也！工具、框架和应用程序都是由代码组成的，思想和方法都是一样的。他们有很多共性，比如需求的的变化。你应该用框架的设计思想和方法应用到你的应用程序中去。应用程序只不过是在某个业务领域内的专业软件，他们也有稳定需求的地方，那么你把这些稳定需求设计到所谓的“应用程序框架”中去，把不稳定的抽象出来，那就能适应需求的不断变化。像框架spring，它的定位是面向非常广阔的业务领域，那些公共的基础设施（ioc、事务管理等）是它的稳定需求，所以spring实现的时候把他们纳入框架中。spring做的好，也不是它用了什么TDD的方法，而是它的定位和设计。一个软件的好坏应该看它的定位和是否有可维护性、可扩展性。 工具、框架需求相对稳定，使用TDD开发这个咱没有疑问。 但应用程序，比如订单流程，今天可能支付成功送100积分，明天可能支付1000赠送5本书，这个需求是变化很快的，是不是BDD更适合呢？ 还有spring之所以稳定难道不是单元测试造就的吗？（架构和设计造就了它灵活、可维护、可扩展等，但单元测试绝对是稳定性的基础） |
| 返回顶楼 | |
|
发表时间：2012-04-01
lianglove_0 写道 wo ca 又是这哥们，又是一对字。
？？ |
| 返回顶楼 | |
|
发表时间：2012-04-01
jinnianshilongnian 写道 devroller2 写道 jinnianshilongnian 写道 youarestupid 写道 devroller2 写道 devroller2 写道 lz你的if条件并不是很难理解，原因是只有&&，人理解还是比较容易，所以你的第一个方法是可行的。
那种既包含&&又包含||、（）的，让人读了半天绕不过来的才需要重构，否则格式化一下代码就可以了。 当然，你项目中有很多相同的这段逻辑，那么重构为一个方法是一定的。 楼主重构的思路是正确的，楼主的第一段例子代码中，即使不把&&写错成&，也是很不好的一种写法，因为，那段代码的主要问题不是因为if()条件太长，也不是因为条件内夹杂了&& 和 ||，而是在同一个if()条件内混合了不同层次的条件判断，像这种场景是应该进行楼主第二段的重构的。 我们水平再高，也避免不了犯错误。 一下是我的思考与问题： 工具、框架 需求相对稳定，而应用程序 需求可能随时变化，那应该如何进行单元测试呢？ 1、工具、框架 应该进行单元测试吗？ 哪些组件及如何进行单元测试？ 它们相对来说 需求稳定，而且尽量对所有组件进行单元测试，如spring框架 做的相当好。 TDD吗？ 2、应用程序 应该进行单元测试吗？ 哪些组件及如何进行单元测试？ 但应用程序 需求可能随时会变而且变化会很大，那应该进行单元测试吗？及何时进行单元测试？单元测试应该如何应对随时变化的需求呢？ BDD吗？ 一起讨论下！ 工具、框架、应用程序 应该分别如何写单元测试 来避免我们遇到的问题 你理解错也！工具、框架和应用程序都是由代码组成的，思想和方法都是一样的。他们有很多共性，比如需求的的变化。你应该用框架的设计思想和方法应用到你的应用程序中去。应用程序只不过是在某个业务领域内的专业软件，他们也有稳定需求的地方，那么你把这些稳定需求设计到所谓的“应用程序框架”中去，把不稳定的抽象出来，那就能适应需求的不断变化。像框架spring，它的定位是面向非常广阔的业务领域，那些公共的基础设施（ioc、事务管理等）是它的稳定需求，所以spring实现的时候把他们纳入框架中。spring做的好，也不是它用了什么TDD的方法，而是它的定位和设计。一个软件的好坏应该看它的定位和是否有可维护性、可扩展性。 工具、框架需求相对稳定，使用TDD开发这个咱没有疑问。 但应用程序，比如订单流程，今天可能支付成功送100积分，明天可能支付1000赠送5本书，这个需求是变化很快的，是不是BDD更适合呢？ 还有spring之所以稳定难道不是单元测试造就的吗？（架构和设计造就了它灵活、可维护、可扩展等，但单元测试绝对是稳定性的基础） 我想订单流程肯定有稳定的地方，那些积分送什么的逻辑可以认为是扩展，假设你设计订单流程用模板方法模式，积分送书、送MP3啊都是可以扩展的。这些通过OO的多态来代替你的if判断，你看是不是避免了你把&&误写为&了 spring的作者也推崇单元测试，这个对软件的稳定是有帮助的，也是必须的。但如果设计不做好，单元测试也很难执行到位，想我们干脆就上集成测试，单元测试就免了。 |
| 返回顶楼 | |
|
发表时间：2012-04-01
多了一个&，&和两个&&是不一样的逻辑关系。
|
| 返回顶楼 | |
