对编码、设计中“极简原则”的想法

    早上刚看了博文《对于开发人员，“极简原则”需要修正，请看“新极简原则”》，有一些想法想说说。
    我用了三年的时光维护一个不算简单的系统，窃以为，“极简原则”也好，单一职能原则也好，最根本的目的是为了易读易懂；

极简必要性：
    举个例子，我以前命名API，务求全面详实，希望用户看到方法名，就理解其功能、特点、参数类型、返回值；但结果是名称冗长，不易阅读。
如：Member getMemberInfoByMemberno(String id)
    当隔段时间再来看，连我自己都被长长的命名弄得烦躁不安，不想去细看。所以长命名并没有达到预期效果。
    实际上，这个接口充分利用已存在返回值和形参名，就可以精简很多。
如：Member getInfo(String memberno)；
  
    再举个例子,同样是获取邮件模板的ServletApi：
       /email/getEmailTempliteByTitle.do
      /email/getModel.do
    在有前缀/email的情况下，后面的方法名没必要再说明是获取email模板。

极简过度：
    举个过去追求极简，一句话包含无数信息的例子，
member.setName(StringUtil.filterKeyword(user.getUserName().trim()));

   不管你信不信，反正我看了这句话有想吐的冲动；如果不巧要调试这句话，那么我肯定骂娘。
    这一句包含的信息量太大，如果出bug，那么就需要细致定位，是user==null，还是user.getUserName() == null，或者StringUtil.filterKeyword写错了，或member.setName没有生效。
    系统设计里定义模块的目的之一，就是将bug的发生限制在一定范围，但太过追求“能一句代码实现的，就不用两句代码”，那么灾难就会降临，阿门……

    所以，我觉得编码的最根本原则是“易读易懂”。如果写两句能够让人清晰的读懂，没必要非得整合成一句。
    因为“代码是给开发人员看的”，或者更进一步，代码是给系统维护人员看的。

评论

4 楼 windshome 2015-08-01  

就是这篇

对于开发人员，“极简原则”需要修正，请看“新极简原则”
http://windshome.iteye.com/blog/2071957

3 楼 windshome 2015-08-01  

刚发现楼主还引用了我的文章，荣幸荣幸。

而且文中说到的都是非常现实真切的问题，从业十余年，深有同感。

1楼兄弟说的，我不能赞同。那样写可读性没有问题，只是读着别扭而已。二则如果这句出了空指针错误，找都不好找。

并且，有时候表达一个想法用一篇文字，有时候用一段，还有时候用一句话，但是也就有用一个字的时候，怎么更好？应该是根据场景不同，要表达的内容不同而定的。当简明则简明，当详尽则详尽。普适的极简原则是不成立的。

编程就像和人说话一样，像个普通人一样去说就可以了，没必要惜字如金，也不能动辄滔滔不绝，做到好处，就是简繁恰如其份，说实话，还真应该向讲故事的高手们学习学习呢。

2 楼 yanglphf 2014-05-29  

举得例子可能不是很恰当，只是不建议一行写太长，不易读不易理解，特别是处理bug被老板催的跟猴子似的时候……咳，但理由之一，bug涉及范围的扩散是绝对站得住脚的。

至于临时变量……话说java是类引用，所以临时变量没有多的那么夸张，就算是原本的一句话，其实也产生了临时变量。

1 楼 mike.liu 2014-05-28  

我倒是觉得那句所谓“极简过度”的语句没什么问题：
member.setName(StringUtil.filterKeyword(user.getUserName().trim()));
可读性也没问题。至少一眼就能看明白是要设置Name。至于Name是怎么来的，逐步往后看，就能明白。一点也不影响可读性，也不会导致思维中断。
至于后面罗列的理由，也是站不住脚的。你可以尝试把这句拆分，必然引入大量的临时变量。肯定需要看半天才能理解，就是想setName而已。