早上刚看了博文《对于开发人员,“极简原则”需要修正,请看“新极简原则”》,有一些想法想说说。
我用了三年的时光维护一个不算简单的系统,窃以为,“极简原则”也好,单一职能原则也好,最根本的目的是为了易读易懂;
[b]极简必要性:[/b]
举个例子,我以前命名API,务求全面详实,希望用户看到方法名,就理解其功能、特点、参数类型、返回值;但结果是名称冗长,不易阅读。
如:Member getMemberInfoByMemberno(String id)
当隔段时间再来看,连我自己都被长长的命名弄得烦躁不安,不想去细看。所以长命名并没有达到预期效果。
实际上,这个接口充分利用已存在返回值和形参名,就可以精简很多。
如:Member getInfo(String memberno);
再举个例子,同样是获取邮件模板的ServletApi:
/email/getEmailTempliteByTitle.do
/email/getModel.do
在有前缀/email的情况下,后面的方法名没必要再说明是获取email模板。
[b]极简过度:[/b]
举个过去追求极简,一句话包含无数信息的例子,
member.setName(StringUtil.filterKeyword(user.getUserName().trim()));
不管你信不信,反正我看了这句话有想吐的冲动;如果不巧要调试这句话,那么我肯定骂娘。
这一句包含的信息量太大,如果出bug,那么就需要细致定位,是user==null,还是user.getUserName() == null,或者StringUtil.filterKeyword写错了,或member.setName没有生效。
系统设计里定义模块的目的之一,就是将bug的发生限制在一定范围,但太过追求“能一句代码实现的,就不用两句代码”,那么灾难就会降临,阿门……
所以,我觉得编码的最根本原则是[b]“易读易懂”[/b]。如果写两句能够让人清晰的读懂,没必要非得整合成一句。
因为“代码是给开发人员看的”,或者更进一步,代码是给系统维护人员看的。
我用了三年的时光维护一个不算简单的系统,窃以为,“极简原则”也好,单一职能原则也好,最根本的目的是为了易读易懂;
[b]极简必要性:[/b]
举个例子,我以前命名API,务求全面详实,希望用户看到方法名,就理解其功能、特点、参数类型、返回值;但结果是名称冗长,不易阅读。
如:Member getMemberInfoByMemberno(String id)
当隔段时间再来看,连我自己都被长长的命名弄得烦躁不安,不想去细看。所以长命名并没有达到预期效果。
实际上,这个接口充分利用已存在返回值和形参名,就可以精简很多。
如:Member getInfo(String memberno);
再举个例子,同样是获取邮件模板的ServletApi:
/email/getEmailTempliteByTitle.do
/email/getModel.do
在有前缀/email的情况下,后面的方法名没必要再说明是获取email模板。
[b]极简过度:[/b]
举个过去追求极简,一句话包含无数信息的例子,
member.setName(StringUtil.filterKeyword(user.getUserName().trim()));
不管你信不信,反正我看了这句话有想吐的冲动;如果不巧要调试这句话,那么我肯定骂娘。
这一句包含的信息量太大,如果出bug,那么就需要细致定位,是user==null,还是user.getUserName() == null,或者StringUtil.filterKeyword写错了,或member.setName没有生效。
系统设计里定义模块的目的之一,就是将bug的发生限制在一定范围,但太过追求“能一句代码实现的,就不用两句代码”,那么灾难就会降临,阿门……
所以,我觉得编码的最根本原则是[b]“易读易懂”[/b]。如果写两句能够让人清晰的读懂,没必要非得整合成一句。
因为“代码是给开发人员看的”,或者更进一步,代码是给系统维护人员看的。