---
title: 两面
date: '2015-10-24'
slug: two-sides
---

我觉得决策没有绝对的正确或错误，所有决策本质上都是权衡利弊，所以要两面思考。现今多数应用或网页上都只有“喜欢”的按钮，而没有“讨厌”，有时候这缺少的一面会变得非常讨厌，比如听歌，有些你真心不喜欢的歌你跳过了一遍又一遍，系统还是自动推荐给你，这用户体验就太糟糕了。为什么不能有个“我很烦这首歌”的按钮呢？其实没有就没有吧，“跳过”这种行为本来也是一种数据，靠谱的数据分析狮应该能嗅到它的价值，可惜好像这个数据并没有被虾米使用，让老夫不厌其烦地跳过《没那么简单》。

举几个码农例子。比如有人[抱怨说**knitr**毁了他的文件](https://github.com/yihui/knitr/issues/1123)，我当然可以提供一个选项，在写输出文件的时候提醒用户要不要覆盖已有文件，可这样做会让绝大多数用户觉得烦，我编译个文档，你为毛老是问我问题。我的导师Heike大人有时候就嘲笑Windows下一些对话框，总是问你，是否确定？是！真的吗？对！确定一定以及肯定？滚！若不问，就可能出现帖子里失误覆盖文件的问题。是去烦多数用户，还是让极少数人粗心犯错付出沉重代价？我选后者。

又比如早些时候**jsonlite**的作者总是打着“严谨”的口号，**RJSONIO**以不严谨著称，有些特殊的情况下，你压根儿无法预测R对象转成JSON对象会变成什么（比如只有1行1列的矩阵）。然而严谨带来了一个巨大的不便，比如长度为1的R对象到底转成JSON数组还是标量？他选择数组。在实际应用中，其实标量更常见一些，但作者原来只提供了标量的标记方式，是一个`unbox()`函数，而在**RJSONIO**包中提供了一个相反方向的标记方式，`I()`函数，告诉转换函数这个对象应该被视为长度为1的数组。于是在[这个帖子](https://github.com/jeroenooms/jsonlite/issues/78)中，我给出了两种方式的对比。如果只有作者原来提供的`unbox()`方式，代码会变得臃肿丑陋，尽管**RJSONIO**各种不靠谱，但这个`I()`标记还是很方便的。要打倒一个旧软件，不意味着它的一切都是糟糕的，自以为严谨了，其实也可能会带来不便。正反两面都需要想想。

这么一想，统计里面风险函数是拿损失函数求期望，如果不两面或多面思考，实际上也就是只考虑了损失函数的一种取值，决策者对风险值并没有整体把握。
