另外额外说一点，如果思路不清晰不妨先将业务逻辑通过注释打出来然后按照逻辑去写，如果没写注释写完后再打一遍注释有助于检查一遍逻辑和代码
- 保证业务清晰度，比如：一段逻辑要完成判空和过滤两种情况的写法，分开写当别人看的时候会很清晰，合在一起用lambda写看起来逻辑不太清晰那直接选择第一种方式，当然相反也是一样，如果使用lambda 清晰，分开写不清晰，则使用lambda
- 降低代码风险，比如：某段代码这样写可能会产生空指针异常的风险，但是另一种写法完全不存在这种风险，则选择另一种
- 性能上考虑，比如：执行时间，内存占用等
- 从扩展性考虑，刚开始的代码可能不需要使用设计模式，但是要考虑到未来这块的业务是否会变得特别复杂，就必须在写这些方法的时候考虑到以后会如何扩展，哪里可能会是扩展点，例如：订单支付有微信支付，支付宝支付等对接，未来不知道会不会有其他支付方式对接进来，所以要考虑到以后的扩展如何处理，可以先将微信支付， 支付宝支付等相关流程都封装成一个方法，在使用switch进行逻辑判断，如果后期变得复杂，可以将这两个方法直接变成相应的接口进行实现，以此引用到相关的设计模式来处理复杂的流程
- 从可维护性考虑，从可维护性考虑其实某种方面保证代码清晰度是有关系的，更或者说两者是相辅相成的，比如：做好注释，代码整洁度等等，经典反例就是嵌套地狱了
- 从功能复用的角度考虑，要考虑到某块代码是否在后面还会被别人调用到，此时就需要将这段代码直接写成一个方法
- 从代码稳定性考虑（代码健壮性），怎样写能够保证代码的稳定运行，和性能上考虑有些相似，但是又有所不同，代码稳定性例如我们开玩笑的一句话，这个程序是靠bug执行的，代码性能考虑，已经是优化流程了，以上仅个人理解，不对请纠正