最近在 B 站刷到一位北京语文老师抨击上海古籍出版社《西厢记》存在数百处错误的视频。随后，又陆续看到多位 UP 主针对上海古籍出版社某些书籍中的个别差错进行“逐条批评”的内容。对此，我的看法是：大可不必如此上纲上线。

如果将视角稍稍拉远，就会发现，当下的出版业基本已可视为一个夕阳产业。在出版社内部，图书编辑长期被视为成本部门，对其工作的核心要求往往只有一条：只要符合质量标准即可¹。

而目前通行的图书质量检验标准是：整本书的差错率需控制在万分之一以下。只要达到这一标准，图书便被认定为质量合格，可以正常出版发行。该标准主要涵盖三类问题：其一，也是最重要的，是意识形态²问题³；其二，是错别字、病句、标点符号等文字层面的差错；其三，是知识性与逻辑性方面的错误。不同类型的问题有不同的统计与容忍尺度，其中意识形态问题属于红线，不允许出现。如果出现有关意识形态的问题，轻则召唤销毁全部已售图书，重则不再下发新书号。

换言之，一本书在出版后仍然存在一定数量的错误，在制度层面事实上是被默认、被容忍的。较为负责任的出版社，通常会采用“三审三校”⁴的流程，并配有专门的质量管理部门进行不定期随机图书抽检，以期尽可能降低出版物中的差错率。但也有不少出版社采取“以量取胜”的策略（如清华大学出版社），更看重年度出版码洋，而非单本图书的质量。

在这种背景下，为了维持持续而快速的出书节奏，在有限的编辑人员编制之下，留给编辑逐字核对的时间本就极为有限，要求其修正全部差错，几乎是不可能完成的任务。尤其是在近几年图书市场持续走低的情况下，这一问题只会进一步恶化。

如果回顾早期的出版史，在铅字排版时代，一部作品在首版首印中已经存在的错误，即便后来多次加印，往往也不会被修正，因为书版一旦固定，改动成本极高。而在如今的电脑制版环境下，再加上“加印也需重新呈缴”⁵的制度背景，每一次加印几乎都相当于重新制版，既有差错理论上都有机会在后续印次中得到修正。

因此，一般而言，同一书目越往后的印次，错误往往越少。

但问题在于，现实中并非所有出版社都真正落实了这一机制。不少出版社的质量管理部门形同虚设，只重视发行部门的业绩，对编辑部门的工作状态与修订反馈并不关心。结果是，即便读者将差错反馈给具体编辑，这些问题也未必会在后续加印中得到修正。

这也是为什么在购书时，人们常常建议优先选择“大出版社”——并非因为它们从不出错，而是其质量管理体系相对完善，更有可能避免明显低劣的出版物。

遗憾的是，这一经验在古籍出版领域并不完全适用。事实上，在上海古籍出版社相关事件发酵之前，我就已经明显感受到这一领域的图书质量正在快速下滑。例如，中华书局于 2019 年出版的《梁佩兰集校注》，便因质量问题遭到大量读者批评，最终被下架处理⁶。

更值得注意的是，中华书局近年来重印的不少古籍，仍然沿用上世纪的铅字书版，而未重新制版。这直接导致新近印次中字迹模糊、版面老化，阅读体验极差。在古籍领域，许多所谓“精校”的简体排印本，在阅读体验和文本可靠性上，反而不如直接阅读影印底本，甚至不如一些带有题跋、校勘痕迹的旧本。

即将于 2026 年 1 月 1 日施行的《中华人民共和国国家通用语言文字法》，在相关条款中明确提出：中文出版物应当符合国家通用语言文字的规范和标准。这基本限定了未来出版图书只能以《通用规范汉字表》⁷所圈定的规范汉字进行排印⁸。

当然，法律也为文物古迹、姓氏、书法篆刻、题词招牌，以及出版、教学、研究确有需要的情形，保留了有限使用繁体字、异体字的空间。这种看似克制的规定，恰恰反映出立法者所面对的两难处境：一方面，需要维护国家通用语言文字的统一性与规范性；另一方面，又不得不承认，在学术、历史与文化传承领域，语言文字从来不是一个可以被简单“标准化”的对象。

问题也正出在这里。法律能够规定“能不能用”，却很难解决“用得好不好”。在古籍出版中，是否使用规范汉字表外的繁体字、异体字，本质上并非技术问题，而是编辑能力、学术判断与责任意识的问题。如果编辑团队本身缺乏相应训练与时间保障，那么即便法律允许，现实中也可能被简单粗暴地“一刀切”式简化；而所谓的“规范”，最终只剩下形式上的合规，而非文本意义上的准确。

更何况，《通用规范汉字表》颁布已逾十年，但仍有大量异体字未被扶正⁹。很多情况下，若单纯追求形式统一，反而会造成新的错谬，使古籍的理解更加困难。

从这个角度看，图书差错之所以逐渐成为一种“常态”，并不只是因为某一家出版社、某一套制度出了问题，而是因为整个出版体系正在被迫向最低成本、最低责任的方向滑落。法律可以为文字的边界划线，却无法替代专业判断；制度可以要求“符合标准”，却无法强制生成真正的敬畏与耐心。

或许，真正令人担忧的，并不是我们是否还能读到一部“零差错”的书，而是当下一代读者逐渐失去辨认、理解古籍原貌的能力时，是否还会意识到：那些被省略、被简化、被误读的地方，原本曾经承载着更为复杂、精细的思想世界。2023 年新春贺岁片《满江红》在宣发中，将“髪”误写为“發”的海报错误，或许并非孤例，而只是一个预兆。

如果说这是一种悲哀，那么它恐怕并不只属于出版业。

9 月初，我发了一个关于《围城》的段子。评论区毫不意外地迎来了一阵骂声，言辞犀利，仿佛和我有不共戴天之仇。一如年初我提到京台高速时，解释“台”指的是台湾，也同样被人群起而攻之。

互联网时代最显著的特点，就是“放大”。原本小众的亚文化，可能因为传播而进入主流；细微的声音，也可能瞬间成为热梗。与此同时，各种铺天盖地的杂声也被无限放大，几乎每一次发声都可能引发涟漪——有时是赞扬，有时则是苛责。

记得大学时，我常读阮一峰老师的博客，经常能发现文章里的小错误。评论区里总有人指正，也有人冷嘲热讽。阮老师的处理方式很特别：修正错误，但不删评论。当时我并不理解，觉得刺眼的言论删掉就好。我曾深信“美国式的言论自由”：你有“挥拳头”的权利，我也有“不被打”的权利。

然而，网络里的冷暴力因为传播而被放大，锋利得像刀，很容易伤人。年轻时的我常常咽不下这口气，总觉得一定要争个你死我活，即便争论落了下风，也会像阿 Q 一样，在心里默念自己“被儿子骂了”。2015 年，我在知乎混迹时，知乎推出过“友善度”系统，提醒大家不要过度攻击他人。可即便如此，我仍常因争论而与他人冲突，友善度一度降到最低。

如今回头看，那些争吵、执拗和愤怒，大多没有意义。你删不完评论，也赢不了所有的辩论。学会妥协，并不是承认错误，而是承认世界不会完全如你所愿。与世界相处的方式，往往不是“打败”，而是“放下”。

学会放下，并非软弱，而是一种智慧。它让你在面对网络的喧嚣时，依然能保持内心的宁静；它让你在生活的纷扰中，不再因小事消耗过多精力。有人说，成长就是学会和自己和解，也学会与世界和解。

编码的三重境界

在程序员的成长过程中，写代码的能力通常会经历三个阶段：

1. 由少写多 —— 开始懂得写代码

这个阶段的特点是“能写出来，能用”。很多人停留在这里，写的代码逻辑不够精简，质量一般，而且往往杂乱无章。典型表现是：写之前毫无规划，想到什么就写什么。虽然功能能实现，但可读性和可维护性都很差。

2. 由多写少 —— 学会优化逻辑

进入第二阶段，你会开始有意识地精简代码逻辑、优化思路。代码看起来更简洁，重复和冗余减少了。但是，这种刻意追求简洁的做法，容易带来新的问题：

• 异常情况考虑不周全
• 可维护性下降
• 代码虽然短，但阅读困难，逻辑复杂 很多程序员在这个阶段陷入“面条代码”的陷阱：为了追求短小精悍，反而让代码变得难以理解。

3. 由少写多 —— 掌握抽象与设计

第三阶段的程序员，写代码前就有清晰的需求和思路。

• 适度抽象，考虑未来扩展
• 逻辑条理清晰，易于维护
• 不一定是最简洁的代码，但一定是最优质的代码 好的代码，重在可读性、可维护性和扩展性，而不是极致的简洁。

总结

我发现一个有趣的现象：优秀的代码，其编程风格往往相似。写代码的关键，不在于技巧，而在于思路——你知道自己想要什么，知道要解决什么问题。

没有思路写出来的代码，即便再好看，也无济于事。

网易云音乐一直是一个值得吐槽的地方，比如，它常常认为你懂五国语言，动不动给你日推一些稀奇古怪的歌曲。因为我会日语，所以日推的大部分都是日文歌，还可以接受。但最近网易云音乐开始变本加厉，给我日推俄文歌，这实在是不能接受。

一般我熬夜时，都喜欢开着网易云音乐听歌。不是说我多喜欢音乐，而是为了防困。精力专注的时候，歌曲就像一种微噪音，你根本感知不到。有时也会听到一些不错的歌曲，就下载收藏。

周一时听到一首名为「PLANET」的歌曲，前奏就十分抓耳，当时立刻点击下载，可惜这歌竟然要付费。生在天朝，仗着自己从事 IT 相关工作，最大的好处便是能免费搞到一些数字出版物。但我在谷歌、百度上查找许久，竟找不到这首曲子的 320 Kbps 版本，不禁有些沮丧。

在网易的「チーズ牛丼」（沙拉牛肉）上找到一篇关于「PLANET」的创作组合 「ラムジ」 的介绍。22 岁的山下佑树在过生日时，只因想唱点什么来到东京，和报复不得施展的井上慎二郎桑如童话般在雨中相遇，并开始了长达 8 年的演艺事业。

当時、井上慎二郎に初めて出会ったとき、雨に濡れて震える子羊のような容姿だった為、当時の山下のイメージから羊を連想し、アニメの子羊キャラクターからラムジと命名。

当时山下佑树遇到井上慎二郎，看到他被雨淋湿的姿态，联想到了动画《ラムヂーちゃん》里“子羊”这一角色，因而采用ラムジ作为组合名。

一切都是那么巧合、随性，连乐队名都有这么哭笑不得的缘由。然而，并非每个梦想都能瓜熟蒂落，ラムジ在 2012 年便宣布 2013 年解散。我翻遍他们为数不多的专辑、单曲，喜欢上的，也只有那首「PLANET」。

可我还是不死心，我能感受到歌曲里那种热情和呼唤，那种渴望展露头角、被大众关注的心情。现在的我与当时的主唱山下佑树年龄相近，更能体会他期盼与绝望交织的矛盾心情。我翻遍脸书、推特及所有我所知道的社交网络，却没找到关于山下佑树的任何信息。他随着ラムジ的解散，消失在大众视野。即使是推特上，也很少有人提起。

可是，我还记得，就像他们的歌还在被人听、被人唱一样，我还记得这么一个乐队，如流星般存在过。

前些天翻推特，看到有人说，大部分代码的存活时间只有不到 5 年。回想自己接手过的很多老项目，确实如此。在 OneAPM 上班时，兄弟部门的系统一年重写了 2 次。自己维护的系统，也因个人审美变化，一年内留下了 3 种不同风格的代码。

如果说乐队的解散还能留下当时传唱的歌曲，那么程序的重写，可能就是彻底消失。那么，作为程序员，我们还能留下什么呢？

我想，只有编程思想吧。

记得 4 个月前带小弟写的 SQL Generator。核心思想是对当时业务 DSL 的抽象封装，以及函数式变换思想。即使后面代码废弃，我想它的定义仍能传递给每个维护过它的人。这个设计思路再精进，便是Language Implementation Patterns中提到的解析与生成两种形态。虽然 SQL Generator 独立于底层解析器开发，但最终二者的抽象结构惊人一致。

同样的说法可以应用于程序设计的很多地方，比如单元测试。我以前一直不知道什么是测试、怎么写测试。后来有意识地学习模仿后发现，单测无非三大步：构造测试对象和测试数据、调用方法、断言。

测试对象有些可能是 Mock 的接口，但一定不能 Mock Static 对象，否则说明代码抽象存在问题。测试数据，也叫样本，关键在于能命中边界条件。而断言无非就是各种 true、false、equals 的判断，hamcrest 之类无非简化判断过程，但切记慎用 Mock 里的 verify 做断言。

所以，测试代码再怎么变，也逃离不了上面的编程方法，即使是别的语言，亦是如此。我很费解的是，在苏宁看到同事写测试时，竟写一个 main 方法，用 System.out.print 输出结果人肉判断。因为上线有单测覆盖率要求，他们竟写了针对实体 Getter、Setter 的测试代码。这种测试代码，有存在的意义吗？

有时我觉得，编程就是一种体力活：想好了怎么设计，后面的编码加测试，纯粹是一种肝状态。有时候又觉得很多代码纯粹是套路（模板代码），只是因为某些需求不得不这么写。正如标题所言，总得给自己留下点什么。我希望留下的，是那些有意思的设计思路，而不是那些 「垃圾代码」。

之前看 Linus Toward 在去年的某次采访中说到的好代码坏代码，当中提到了逻辑的精简，能用更通用的逻辑减少 if else 的判断在某种程度上可以使你的代码变得更好。最近一段时间重构了部分老代码，也 Review 了不少代码，对此观点深有感触。

很多时候，程序员接到的需求，产品巴不得你立刻就能搞定，有时候会给非常紧迫的时间点。这种情况下会带来的最直接问题，就是“设计坏味”。有整体的架构设计的不合理，也有代码逻辑的问题。尤其是对于边界条件的处理，因为需求的急，很多时候大家就会按照业务语言去写。

比如，下面这个例子：

某一报警系统产生了报警邮件，现在需要按照类型显示不同的内容。

如果按照业务的语言，我们可能写出如下的伪代码：

if (Web事务&& 单条Web事务) {
    return Tier,Web事务,节点;
}
if (Web事务&& Tier) {
    return Tier,节点;
}
if (节点&& 某一个节点) {
    return 节点;
}
if (节点&& Tier) {
    return Tier,节点;
}

可能你看到这里会立刻笑出来，哪有只写 if 不写 else 的。那好，也许你会写出这样的代码。

if (Web事务) {
    if (单条Web事务) {
        return Tier,Web事务,节点;
    } else if (Tier) {
        return Tier,节点;
    }
} else if (节点) {
    if (某一个节点) {
        return 节点;
    } else if (Tier) {
        return Tier,节点;
    }
}

我相信，大部分人都能将判断逻辑写到这一层，但是，这就完了么？也许你会说完了，逻辑也正确，看起来也很清晰。然而，这远远不够。

其实我们可以发现，在每种情况下，都会返回 节点 信息。只返回节点信息的只有一种情况，其他的情况下，基本都返回 Tier 信息。只有 Web事务 && 单条Web事务 的情况需要返回 Web事务 信息。所以，最后我们可以精简为两个判断。

result = "节点";
if (Web事务&& 单条Web事务) {
    result = "Web事务" + result;
}
if (Web事务 || !某一个节点) {
    result = "Tier" + result;
}
return result;

回到最初的命题，为何不要用业务的语言来编写判断逻辑呢？因为业务语言是给用户和产品看的，他们在描述上本身就不够精简。其次，业务的描述，很多时候，是定义边界，说明问题，而不是告诉你判断逻辑。

所以，在写代码的时候，更多的时候要细化逻辑。这样，在维护修改时，才更为方便。下面我举另一个更具体的例子。

这是我 Review Scala 代码的时候遇到的一个问题，首先我先用业务语言描述一下需求。需要判断某个规则的开闭状态，在一天的几点到几点间启用，且还可以额外设置是周一到周日的哪几天启用。

于是我看到当时的同事，写一个方法 isSuppressTime ，会给两个参数，第一个参数为一个时间戳 timestamp ，第二个参数为一个 List[Map[String, String]] 。

Map[String, String] 里面有4个值，分别是：

1. startTime，从零点到某个具体开始时间的秒数，0~86399。
2. endTime，从零点到某个具体结束时间的秒数，0~86399。
3. isDaily，当时间戳在 startTime endTime 之间时，如果此项为 true，则返回 true。
4. weekdays，周一到周日，1~7，以,间隔组成的字符串，如1,4,5。表示周一、周四、周五且时间戳在 startTime endTime 之间时返回 true

最后他写出了如下的代码（Scala）：

def isSuppressTime(now: Long = System.currentTimeMillis(),
                   suppressTimes: java.util.List[java.util.Map[String, String]] = rule.getSuppressTime): Boolean = {
  if(suppressTimes == null)
    return false
  import scala.collection.JavaConversions._
  suppressTimes.foreach(params => {
    if (params != null && params.size > 0) {
      val startTime = params.get("startTime")
      val endTime = params.get("endTime")
      val isDaily = params.get("isDaily")
      val weekdays = params.get("weekday").split(",").toList

      val zero = zeroTimestamp()
      //今天零点零分零秒的毫秒数
      val start = zero + startTime.toLong * 1000
      val end = zero + endTime.toLong * 1000

      if (start < = now&& end >= now) {
        if (isDaily.toBoolean)
          return true
        val cal = Calendar.getInstance()
        cal.setTimeInMillis(now)
        var day = cal.get(Calendar.DAY_OF_WEEK)
        if (day == 1)
          day = 7
        else
          day = day - 1
        val weekday = day.toString
        if (weekdays.contains(weekday))
          return true
      }
    }
  })
  return false
}

private def zeroTimestamp(): Long = {
  val cal = Calendar.getInstance()
  cal.set(Calendar.HOUR_OF_DAY, 0)
  cal.set(Calendar.SECOND, 0)
  cal.set(Calendar.MINUTE, 0)
  cal.set(Calendar.MILLISECOND, 1)
  cal.getTimeInMillis()
}

这个代码看着很长，判断很多，而且还用了超级多陈旧的 API，使得它的性能也不好。而且这是一段 Scala 的代码，却用了较多的 return 和 var ，这两个都是 Scala 不提倡的。最关键的，明明是函数式的代码，他却写出了过程式的感觉。给后面的维护人员（我）带来了不少困扰。

下面，我们来一点点优化这段代码（需要一点点 Java 功底），首先对于方法 zeroTimestamp() ，我第一眼看到的时候，是惊讶的，原作者用了一个比较旧的 Calendar 。对它最深刻的印象就是当年写 SimpleDataFormat 的时候，因为 Calendar 这货导致线程不安全。而每次创建 SimpleDataFormat 的开销比较大，最后不得不写了个 ThreadLocal<simpledataformat> 。

而Java8以后，我们可以直接用 java.time 下面的类来改写 zeroTimestamp() ，这里只需要一行代码，如下：

private def zeroTimestamp(): Long = {
  Timestamp.valueOf(LocalDate.now().atStartOfDay()).getTime
}

回到 isSuppressTime 方法上来，我姑且不说他的设计多么麻烦，因为这是一个已经被广泛使用的方法，我能做到的就是在不改变签名的情况写来优化实现。

首先，开头我们就看到

if(suppressTimes == null)
  return false

这个空的判断和强制 return ，在 Java 里面， null 是一个很痛苦的事情，Scala 因为基于 JVM 也不例外，但是 Scala 和 Java 8 都分别有一个 Option 类（Java8是 Optional ），来做空值处理。

所以，我们这里第一时间可以干掉这个判断，写成如下方式

Option[util.List[util.Map[String, String]]](suppressTimes).map(times => {
  // ba la ba la
}).getOrElse(false)

代码里面的 times 为方法中非空的 suppressTimes ，注释部分为核心的处理逻辑，这样我们避免了一个 if 判断，减少了一个 return 。

而其实， Option([A]).map([B] => Boolean).getOrElse(false) 等价于 Option 的 exists 方法，最后完整的代码应该如下：

def isSuppressTime(now: Long = System.currentTimeMillis(),
        suppressTimes: java.util.List[java.util.Map[String, String]]): Boolean = {
  Option[util.List[util.Map[String, String]]](suppressTimes).exists(times => {
    times.foreach(params => {
      if (params != null&& params.size > 0) {
        val startTime = params.get("startTime")
        val endTime = params.get("endTime")
        val isDaily = params.get("isDaily")
        val weekdays = params.get("weekday").split(",").toList

        val zero = zeroTimestamp()
        //今天零点零分零秒的毫秒数
        val start = zero + startTime.toLong * 1000
        val end = zero + endTime.toLong * 1000

        if (start < = now&& end >= now) {
          if (isDaily.toBoolean)
            return true
          val cal = Calendar.getInstance()
          cal.setTimeInMillis(now)
          var day = cal.get(Calendar.DAY_OF_WEEK)
          if (day == 1)
            day = 7
          else
            day = day - 1
          val weekday = day.toString
          if (weekdays.contains(weekday))
            return true
        }
      }
    })
    false
  })
}

在上面的例子里面，我们已经干掉了两个 return 和一个 if ，让它有一点 Functional 的感觉了。

上面重构后代码中， times 的类型是 util.List[util.Map[String, String]] 。 times.foreach(params => {}) 里的 params 对应的是 util.Map[String, String] 类型。所以，我们看到判断 if (params != null && params.size > 0) 时应该会发现，这就是一个list filter的过程嘛。 .filter() 之后不就是一个 .map() ，于是我们可以这么改：

Option[util.List[util.Map[String, String]]](suppressTimes).exists(times => {
  times.filter(params => params != null&& !params.isEmpty).map(params => {
    // ba la ba la
  }).contains(true)
})

当然 .map(xxx => Boolean).contains(true) 等价于 .exists() ，于是我们重构的方法如下：

def isSuppressTime(now: Long = System.currentTimeMillis(),
        suppressTimes: java.util.List[java.util.Map[String, String]]): Boolean = {
  Option[util.List[util.Map[String, String]]](suppressTimes).exists(times => {
    times.filter(params => params != null&& !params.isEmpty).exists(params => {
      val startTime = params.get("startTime")
      val endTime = params.get("endTime")
      val isDaily = params.get("isDaily")
      val weekdays = params.get("weekday").split(",").toList

      val zero = zeroTimestamp()
      //今天零点零分零秒的毫秒数
      val start = zero + startTime.toLong * 1000
      val end = zero + endTime.toLong * 1000

      if (start < = now&& end >= now) {
        if (isDaily.toBoolean)
          return true
        val cal = Calendar.getInstance()
        cal.setTimeInMillis(now)
        var day = cal.get(Calendar.DAY_OF_WEEK)
        if (day == 1)
          day = 7
        else
          day = day - 1
        val weekday = day.toString
        if (weekdays.contains(weekday))
          return true
      }
      false
    })
  })
}

这次重构，我们又去掉了一层 if 判断，改为 filter 实现，减少了一次返回。到了这一步，我们会发现，下面需要实现的就是一个方法，对 util.Map[String, String] 去做处理，返回一个布尔值，于是我们精简方法的实现代码为两部分：

def isSuppressTime(now: Long = System.currentTimeMillis(),
                   suppressTimes: java.util.List[java.util.Map[String, String]] = rule.getSuppressTime): Boolean = {
  Option[util.List[util.Map[String, String]]](suppressTimes)
    .exists(times => times.filter(params => params != null&& !params.isEmpty).exists(isValidateTimes(_, now)))
}

这个为边界过滤的方法。

private def isValidateTimes(params: java.util.Map[String, String], now: Long): Boolean = {
  val startTime = params.get("startTime")
  val endTime = params.get("endTime")
  val isDaily = params.get("isDaily")
  val weekdays = params.get("weekday").split(",").toList

  val zero = zeroTimestamp()
  //今天零点零分零秒的毫秒数
  val start = zero + startTime.toLong * 1000
  val end = zero + endTime.toLong * 1000

  if (start < = now&& end >= now) {
    if (isDaily.toBoolean)
      return true
    val cal = Calendar.getInstance()
    cal.setTimeInMillis(now)
    var day = cal.get(Calendar.DAY_OF_WEEK)
    if (day == 1)
      day = 7
    else
      day = day - 1
    val weekday = day.toString
    if (weekdays.contains(weekday))
      return true
  }
  false
}

这个为我们要重构的核心处理逻辑。我们优化整理它的判断条件，最后可以实现如下的完整代码：

def isSuppressTime(now: Long = System.currentTimeMillis(),
                   suppressTimes: java.util.List[java.util.Map[String, String]] = rule.getSuppressTime): Boolean = {
  Option[util.List[util.Map[String, String]]](suppressTimes)
    .exists(times => times.filter(params => params != null&& !params.isEmpty)
    .exists(isValidateTimes(_, now)))
}

private def isValidateTimes(params: java.util.Map[String, String], now: Long): Boolean = {
  val zero = zeroTimestamp()
  val start = zero + params.get("startTime").toLong * 1000
  val end = zero + params.get("endTime").toLong * 1000
  val isDaily = params.get("isDaily").toBoolean
  val weekdays = params.get("weekday").split(",").toList
  val weekday = LocalDate.now().getDayOfWeek.getValue.toString

  (start < = now&& end >= now)&& (isDaily || weekdays.contains(weekday))
}

这样，我们就实现了一个 if 都没有，一个 return 都没有的纯函数式写法。

总的来说，代码谁都能写出来，但是把需求从文字或者是流程描述换成编码实现时就有了对程序员抽象逻辑能力的需求。如何组织抽象，就像是如何写作文，或者是 Kata（空手道里面的招数、套路），不要按照业务描述写 if else，而要尽可能简化找到一致性的简单逻辑描述。

如果能将所有的特殊情况变为通用情况，简化逻辑判断，那么代码在后面的迭代中也会比较易于维护。

有句话说得好，哲学，出自一群无聊的闲人手里。苏格拉底的妻子苏珊娜就曾经如此自白：“我是苏格拉底的妻子苏珊娜，我的丈夫苏格拉底是一个著名的懒汉。他每天一大早就起床，吃完早饭就出门了，他没有工作，我也不知道他每天都在外面做些什么。家里的日子很贫寒，总是无米下锅，我很为家里的生计着急，觉得不能每次都靠柏拉图他们来接济，咱们家应该自食其力，于是每次都劝他找份工作，干个家教什么的，但是他从来都把我的话当耳边风。”

同样地，马克思也是有名的闲散之士，成天就靠着恩格斯的接济过活。而想想原因，也并非没有道理。大学教授问他的学生一天都干了些什么，学生列出满满一张日程表，最后教授惊呼“天哪，那你哪有时间思考呀？！”

思考需要时间，这是显而易见的，但却又那么容易被人忽视。每天过着忙碌敲代码的生活，哪里有时间思考。强迫自己写一篇日志之类的东西，其实也是强迫自己抽出一些时间去思考。生活的忙碌，就像小沈阳说的，“一睁眼一闭眼，一天就过去了”。

时间就像流沙一样从指缝流逝着，而自己却似乎什么都还没有做成。

~ fin ~

不知从何时起，我爱上了那深藏不露的黑色。

只因为夜。

每至深夜时，我总是习惯性地关上灯，静静地立在窗前，任凭月光如瀑般倾泻全身，以及随之而来的纷涌思绪。

也许，只有当俗世的一切喧嚣与繁华沉寂在这无边的夜时，我们才得以摘下白天的面具，让自己的灵魂在月光的抚慰下得到一丝安宁。或许，也只有此时，我们才能够真正地看清自我。

静默的黑夜是思想者的天堂。夜深人静之时，我们的心才得以自由地舞动于风中，在夜神的陪伴下细细地品味人生百态。

一向不喜在夜里喝咖啡，相反，我更情愿在这令人沉醉的黑夜中倒上一盏香茗。咖啡的味道太浓、太重，是只属于那些都市人的佳酿。而茶，却是淡淡一缕幽香。

茶香完美地与夜融为一体。人生，有时也如茶一样，淡然无味，甚至微微作苦。惟有在喝下去之后，才能体味到，那残留于舌根的一缕清香。

在夜晚听音乐亦不失为一种享受。闭上眼，听着那曼妙的旋律飘荡于月光中，只感到自己的呼吸已同时间一起消逝于无尽的黑暗中……

每一次在夜中，我都能获得不同的启示。有时，耳边仿若飘荡着来自古希腊吟游诗人的声音，一个个古老而又神秘的音符中，传颂着无数掩埋于历史尘埃之中的故事。关于爱情与热血、生命与信念……

夜，永远是最神秘莫测的精灵之一。它似乎无所不知，能够洞察每一个人的灵魂，却又如海般包容一切，所有的美与丑、善与恶，都被笼罩于黑暗之中。它总在你不经意间悄悄降临，当你回过神时，又早已离去。它像一只翱翔的鹰，孤傲地振翅于云霄之上，漠然地注视着人间的一切却又从不为之停留，只在地面上投下它巨大的身影。

轻轻的
放缓呼吸
让心带着你的全部
一同溶解在似水的黑暗之中
只余下夜……

这样的雨，实在是让人烦恼，接连数日，没有停的时候。

这样的雨里，想做的事情实在很少。天空灰蒙蒙的，心情也仿佛蒙了灰尘，让人感觉整个世界变得忧郁而烦闷。

对于雨天，从小就是心怀不平的。

只那么一夜，树叶洒落一地，不由得惊叹秋雨竟如此冰冷无情，想起曾经读过的许多雨天的文章，总是不了解作家的心境，不了解他们怎么会有那样美妙、美好的感觉，自己始终无法体味。

就在深秋的一个黄昏，那拍落了叶的街头树与自己相对而立，默默无语地看着一如既往的街景和匆匆的行人，偶尔有一片叶悠悠落下，就这样悄然而立，接受暮里落叶飘零的情意。

难道花季来过，雨季已悄然来临？

花季……风和日丽的港湾……

虽然是在措手不及间踏上这样一条未知的路，虽然花季初至也曾经彷徨，但永远无法忘却的是美丽的心情；永远不放弃的是成长的意义，没有任何感伤，只有如期而至的平静与欣慰。

没有显赫的身世，没有令人瞩目的才能，却很早就学会用神的笔画着：“我爱祖国”……

没有英俊的外表，没有名牌的衣裳，但这并不重要，阳光、闲适不就是一种自然舒适的心情？

没有人注意自己，也不期待有人为自己鼓掌。毕竟花季不是一路鲜花，一路喝彩……

因为花季中也有无数飘雨的日子……

常常被一些真挚的情意感动而流泪，是在花季里呢？

喜欢在黑夜里孤灯下遥望繁星，聆听“吱吱”的昆虫声，是在花季里呢？

那些被伤害的日子里，学会去思考，去面对，去品悟，是在花季里吧？

我的花季，不是浪漫的粉红色。

以为 19 岁时开满鲜花的，19 岁的字典里也没有“忧伤”这个词，但走进花季，才明白自己和别人不同，也没有资格拥有他们拥有的一切欢笑，自己保留的是一种真诚，不断地使自己完整，不断地寻求自知，体验生活自己拥有的，也只是心底纯净的蔚蓝色的天空。

那一切缤纷的往日在脑中一遍遍重复，像一部黑白的老电影，亲切至极而依然毫无厌倦，是不是他也曾注意，那时的许多美丽的黄昏？

花季是一条路，注定每人都要走过，都要面对，站在这个路口，会想起失败和失败者，想起跋涉和跋涉者……但别无选择，我们属于这条路。

总是想起年少时有过的许多幻想，都在岁月积累的颠簸中碰撞坍塌了，伤心、感慨，昔时难再的悲伤，但谁不是这样？谁的心不是在这样的坎坷中成长起来的，庆幸的是有失去就有得到，就在这些磨难之后，才会进入一种境界，才会拥有一种面对现实的决心，一种明了生命的镇定，就算付出了生命中最宝贵的年华，也无需太在意，不是么？我们所追求的一切，在自己看来却是美丽令人心悸，但最终要得到它还要经过岁月的洗礼，这难道不是一种无可奈何的安排吗？

那么，就让自己忘记得与失。

走了，花季终于永远地走了，而自己永远也无法再抓住那纯好梦幻时光，可是，如果在走出花季后，能得到一种原本无法认知的感悟，那么又何不笑着面对命运呢？

让自己向花季道别吧！如果心真的已不再年轻，再也想不起回忆，那么，就像花季道别吧。

如果走出花季以后，每一件伤心的往事都能让自己深深地醒悟，每一次感悟都能让自己成长许多，每一次成长都能让自己正视过去与现在，每一次回顾中，每个有雨的日子，都能在心底抽出一张浅浅淡淡的风景……那么走出花季又有什么不好呢？

于是，就在雨季中道别花季……

然而，夕阳里，风景依旧迷人。