|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-04-01
devroller2 写道 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
最后修改：2012-04-01
楼主你就写个eclipse的validation插件吧，就是用验证&，=，|这三个在判断语句中是否存在，有了就标记出来
这样让这个即将成为精华帖的文章锦上添花嘛 |
| 返回顶楼 | |
|
发表时间：2012-04-01
jinnianshilongnian 写道 devroller2 写道 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
jinnianshilongnian 写道 devroller2 写道 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的作者也推崇单元测试，这个对软件的稳定是有帮助的，也是必须的。但如果设计不做好，单元测试也很难执行到位，想我们干脆就上集成测试，单元测试就免了。 && 误写成 & 不是问题的关键，关键是背后的事情，此处我只想引伸出对自动代码检查和自动测试有经验的大哥谈谈经验， 设计不好也很难进行单元测试，这个肯定的！ 你们直接集成测试啊，自动化的吗？ 如果不是自动化的，你们如何保证团队成员一定在进行测试？ 能否谈谈你的一些经验 保证在项目做做到某事，应该是管理的范畴吧？技术上做不了，难道你想有个方法，如果某人不对代码进行单元测就报警？或者像OO上的抽象方法，如果继承的代码必须实现其方法，否则编译不通过。如果能像这样在技术上可以做就好了。 |
| 返回顶楼 | |
|
发表时间：2012-04-01
devroller2 写道 jinnianshilongnian 写道 devroller2 写道 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
devroller2 写道 jinnianshilongnian 写道 devroller2 写道 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的作者也推崇单元测试，这个对软件的稳定是有帮助的，也是必须的。但如果设计不做好，单元测试也很难执行到位，想我们干脆就上集成测试，单元测试就免了。 && 误写成 & 不是问题的关键，关键是背后的事情，此处我只想引伸出对自动代码检查和自动测试有经验的大哥谈谈经验， 设计不好也很难进行单元测试，这个肯定的！ 你们直接集成测试啊，自动化的吗？ 如果不是自动化的，你们如何保证团队成员一定在进行测试？ 能否谈谈你的一些经验 保证在项目做做到某事，应该是管理的范畴吧？技术上做不了，难道你想有个方法，如果某人不对代码进行单元测就报警？或者像OO上的抽象方法，如果继承的代码必须实现其方法，否则编译不通过。如果能像这样在技术上可以做就好了。 自动化测试有工具能保证，但如果我们Ignore case就没办法了  ！ 我也没啥好方法，只能靠大家自觉，就想能人谈谈这块理解，没人搭理我，呵呵，都是找我的失误！
|
| 返回顶楼 | |
|
发表时间：2012-04-01
jinnianshilongnian 写道 devroller2 写道 jinnianshilongnian 写道 devroller2 写道 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的作者也推崇单元测试，这个对软件的稳定是有帮助的，也是必须的。但如果设计不做好，单元测试也很难执行到位，想我们干脆就上集成测试，单元测试就免了。 && 误写成 & 不是问题的关键，关键是背后的事情，此处我只想引伸出对自动代码检查和自动测试有经验的大哥谈谈经验， 设计不好也很难进行单元测试，这个肯定的！ 你们直接集成测试啊，自动化的吗？ 如果不是自动化的，你们如何保证团队成员一定在进行测试？ 能否谈谈你的一些经验 保证在项目做做到某事，应该是管理的范畴吧？技术上做不了，难道你想有个方法，如果某人不对代码进行单元测就报警？或者像OO上的抽象方法，如果继承的代码必须实现其方法，否则编译不通过。如果能像这样在技术上可以做就好了。 自动化测试有工具能保证，但如果我们Ignore case就没办法了 ！ 我也没啥好方法，只能靠大家自觉，就想能人谈谈这块理解，没人搭理我，呵呵，都是找我的失误！告诉Oracle，把单元测试作为语言的一部分，如果没有做过单元测试的代码不能在生产模式下运行。 |
| 返回顶楼 | |
|
发表时间：2012-04-01
jinnianshilongnian 写道 告诉Oracle，把单元测试作为语言的一部分，如果没有做过单元测试的代码不能在生产模式下运行。 
|
| 返回顶楼 | |
|
发表时间：2012-04-01
看了这么多个DD……我补充个DDD吧，领域驱动设计
|
| 返回顶楼 | |
|
发表时间：2012-04-01
KimHo 写道 看了这么多个DD……我补充个DDD吧，领域驱动设计
 这个是驱动设计的，跟咱要讨论测试方向不一样。
|
| 返回顶楼 | |
