一个坑了又坑的“解决方案”

今天不分享技术，也不是翻译文章，讲一个昨天和早上亲身遇到的工作中一个技术问题，“技术”不是重点，重点是“问题”。
本文仅是娱乐调侃，看完请误对号入座。😬

背景

笔者参与开发的 app 应该算是一个生活记录类的工具，可以像写日记一样随手记录文字、图片、视频等内容。这类工具性 app 本质上所需的技术含量应该是较高的，甚至可能是一个技术导向的工具。

上面说到 app 会记录图片，为了更“人性化”，app 还提供人脸识别的功能，在 app 内拍照后会进行人脸识别的处理，得出以下数据：

[
    人脸大小象素宽度,
    人脸大小象素高度,
    人脸区域左上角坐标X,
    人脸区域左上角坐标Y
]

通过以上数据，的确能对人脸进行定位。问题也在这里产生了。

下面我们来详细说一下这个问题来由和“解决办法”。

直接的原因就是 android / ios 对于这个数据格式结果输出不统一：

两类数据前后俩俩是反的。

这类问题在任何 app 中都会多多少少的存在，平台不一样嘛，这倒是可以被接受的。但也应该是在一定的程度上，好的 app 应该尽量(实际上也不是很难)将差异抹平，对其它端的开发者提供一个透明的一致化接口。

至少是提供一种足够稳定的方法，让数据、接口使用者能区分出来，进行兼容性的使用。

对啊，你看到这里肯定会觉得笔者矫情了：你兼容使用一下就行呗~。知道啊~，但真正的问题是：这两类数据压根没进行区分，整体以一个字符串的形式直接入库了~~~！

WTF !!!! ???

这让数据使用者怎么用？我就是其中一个。

遇到这个问题，笔者找了两客户端和后台的同事，它们倒是挺淡定的😱：因为这个问题已经存在快一年了 ！

我立刻问他们是怎么使用这些数据？毕竟客户端用的也是最多，他们给出的办法才是真正让我大跌眼镜：

不区分数据源的平台类型，而是根据使用数据的平台进行区分：比如，ios 拿到数据就按 ios 的坐标格式来处理，android 拿到就用 android 的格式，不管这个数据真正平台的格式。

理由也很给力：

一般用 ios 的人不会用 android (牛逼1！😱)，android 的同事瞟了一眼😦：“excuse me!”。
用 ios 的人周围的人、亲属也基本用的是 ios（牛逼2！😱），android 的同事无话算是默认了。这里补充一下，这个 app 是将用户组合成一个个群进行共同记录和分享的，你看到的并不只是你的。
“问题已经存在了，就想办法解决它，这样至少可以将正确的概率从 50% 提高到 70%”，这是原话（牛逼3！😱）

我不知道这些结论是不是他们进行过详细调查得出的，但至少第三个是明显错的。

我也想问题已经存在了，可以让后台同事将数据进行鉴别后加上平台标识，因为长宽和x/y坐标的数据还是有一定的区分性的。就给后台说了一下。

后台同事和客户端商议后的解决办法也让我有点无语：

我这边的使用场景是一个分享出去的 h5，更不很区分数据源的平台了，难不成通过 ua，用户拿 ios 看就按 ios 的格式走？他们的方法倒是“高级”了一点点：分享出去的时候，客户端给加个参数，h5 这边就知道是哪来的了（牛逼4！😱）

理由继续给力：

到这里，我是彻底被说服了，（送上我的膝盖~~~）。然后默默的按照最后的“办法”去处理。

alt

我真不知道这样的解决办法会让这个花力气实现的功能最终显现给用户的正确率是否能有 60%-70%。

但这不应该是一个程序员应该有的解决方案，别说这是一个解决方案，应该连一个方法都算不上。

一个工具性质的 app 不像是做内容的 app 会主动给用户提供信息，这就需要将其精致程度做到足以让用户“喜欢用”。

其它的不说，这些人脸识别的数据随着时间的推移，受：

最终呈现的正确率也是无限接近于：50% — 这是最理想的情况，千万别再有其它需求或终端使用这个数据了🙏🏻🙏🏻🙏🏻。

发现了问题就在问题并不严重的情况下趁早修正，还来的及，要继续按错误的思路进行下去那只能是付出更大的代价来挽回了。

或者是就没想过挽回，没打算这个需求有用，那作它搞毛？甚至没计划这个 app 会活个3-5年？（逃~~~）这些根本上也还是做这个 app 的人决定的吧。