我没有什么Java经验，看到标签里有PHP，来按照PHP的路子回答一下，可能Java有自己的风格，但我觉得本质应该通的
我觉得理想的业务代码的判断依据应该是清晰易懂、易维护，不会因为环境的变更需求的叠加而迅速坏死，这和过程式还是OO，抽象还是不抽象并没有直接关系

那么什么是最容易维护的代码呢？

我认为是英文。就是需求文档本身，假设需求文档本身就能跑起来，那可维护性一定是最高的

那需求文档和我们日常写的代码之间的区别在哪里呢？我认为主要的却别就是我们的代码除了需求（业务）以外，还描述了实现方式，除了what to do，还有how to do

好比需求文档可能是这样的

在表单中输入名字、价格和描述，点击提交按钮生产一个产品，名字不能为空，价格是小数，描述可以为空

代码可能是这样的

conn = sql_connect('xxx.xxx.xxx.xxx');
inputButton.on('click', ->
  assert name is nonempty string, price is float, price > 0, ....
  conn.query('INSERT INTO product VALUES (.....)');
)

看，需求在代码里被实现淹没了，我们按钮是点击的，数据库是sql的，表结构是sql语句里写死的……只有当那么多前提条件恰好工作，这段代码才能正确地反映需求

那么我觉得理想的代码应该就是需求文档的英文版，可能恰好符合某种语法规范，但里面绝对没有任何实现的细节。

比如

form = new Form();
form
  .addField 'name', Form.String, [Assertion.NONEMPTY]
  .addField 'price', Form.Float, [Assertion.POSITIVE]
  .addField 'desc', Form.String, [Assertion.maxLength(65535)]
  .onSubmit ->
    Product.createProduct(form)

然后我可能会以这样的业务代码为目标开始设计整体结构，Form类和Assertion类合作提供表单构建、验证能力，Product里封装关于存储的细节等等。

哦，这个思路有个很帅气的名字叫DSL，在任何高级语言的基础上，通过合适的设计其实设计这样的DSL都不难，可能最初的代码量工作量会稍大，但稍后你会发现，只要产品需求文档还是人话，你要做的事情就是简单的翻译。加业务就只会改业务代码，环境变化或者性能优化或者新的DSL语法就只会改实现代码。这件事看上去很像是抽象，但和软工传统的抽象有所区别：抽象的目的是复用代码，而分离DSL的目的是分离业务和实现，前者可能希望代码少一点，认为代码复用就能提高可维护性，后者则不在乎代码量，认为业务和实现分离才能提高可维护性（虽然这种分离基本上意味着实现的部分可以复用）

这个回答的思路源于我以前的这篇文章 http://press.mcfog.wang/2013/06/dsl-style-javascript/
对应的问题是大表单的JS逻辑代码混乱，可以参考一下

写完一看发现似乎和PHP也没啥关系，其实我就是不懂Java SSH的service那一套，可能没啥针对性

首先任何功能的执行，说到底还是一个过程，先做什么再做什么，第一步第二步，这是肯定的，理清这个过程是实现的第一步。然后，面向对象的设计要求我们把过程中的每一步委托给合适的类来做，读文件让谁来做，排序让谁来做，解析xml让谁来做。这样职责委派的结果，就是程序内出现了模块分层，被依赖得多的模块，通常被视为底层。

当对象在模块之间进行传递时，是否每个模块都要判断其合法性？commons-lang的StringUtils是个例子，它用来处理字符串，而它的所有方法都能很好的处理null参数值，所以它发出了一个很明确的信号：不要在调用我的方法前检查参数是否为null，只管传给我好了！至于你自己写的方法，对参数有什么要求，最好在文档里说明，这样调用者也省心。

日志记录，每个模块都是在自己的角度上去理解要不要记，所以如果你觉得某个地方重复了的话，通过调整配置屏蔽掉多余的就好。

文中你说的两个问题应该是c++才容易遇到的,java一般不用状态码,而是使用异常