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

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

极简必要性：
    举个例子，我以前命名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的发生限制在一定范围，但太过追求“能一句代码实现的，就不用两句代码”，那么灾难就会降临，阿门……

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