我没有什么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的目的是分离业务和实现,前者可能希望代码少一点,认为代码复用就能提高可维护性,后者则不在乎代码量,认为业务和实现分离才能提高可维护性(虽然这种分离基本上意味着实现的部分可以复用)
写完一看发现似乎和PHP也没啥关系,其实我就是不懂Java SSH的service那一套,可能没啥针对性