引言
最近外卖骑手、系统、算法已经是大热关键词。《外卖骑手，困在系统里》这篇文章将外卖骑手这个群体的生存现状做了一次详尽的展示，现在大家都知道了骑手们看似不错的收入背后，有着怎样的艰辛与痛苦。
于是大家各抒己见，探讨是什么原因让外卖骑手成了一份“高危职业”。其中有一个无法绕开的问题，就是骑手们手中的终端APP与后台调度服务构成的系统。
这个系统在某种意义上成了一个压榨强制的象征，就如卓别林的经典电影《摩登时代》中的工业生产流水线一样，把人变成系统中的一颗不会思考的螺丝钉。
关于社会性的话题，大家讨论得都不少了，我在这里却想从技术上探究一下，这个系统里用的最基本的算法是什么。
核心问题
抛开其他细枝末节的问题，假如我们在还没有这套系统的时候，我们想要解决的最核心问题是什么？
外卖业务里最重要的角色有三个：商家、骑手、顾客。那么系统要解决的第一问题，就是要怎样将商家与顾客通过骑手连通起来。
假想一个最简单的世界，这里只有一个商家，一位骑手，以及一名顾客，所有的角色都在一条直线上。那么这个逻辑就简单了，骑手先从商家取餐，然后走直线送到顾客手中就可以。
找一个刚学会“hello, world”的程序员来，也能写好这个算法吧。不过现实要是如此简单那就好了，理想有多丰满，现实就有多骨感。
程序员在对系统进行设计时，往往都是从一个简单场景出发，然后不断增加条件，逐渐接近真实世界。所以接下来，我们要加入一个变化，就是路径的选择。
现在骑手与商家之间还是直线，但骑手与顾客之间存在两条分岔的路径了。我们不妨给路径标上长度，一条路是1公里，另一条是100米。那么这个算法怎么写？
只要能独立完成课堂编程作业的同学们，想必也立马就知道，增加一个条件判断就可以了，哪条路线最短就走哪条。
好，我们继续增加难度。现在骑手与顾客之间隔着三个街区，而商家在其中的一条街上。这可能会费一些脑筋，但对于已经度过实习期，将要转为正式员工的同学们来说，这还是可以实现的。
就是穷举每条路线，将所有可能的路径之和计算出来，然后挑选最短的那条，通知骑手，出发！
最后，我们把街区增加到15个，每个街区上有10个商家。算法不变，运行吧。
咦，奇怪了，CPU打到100%了，居然都过去五分钟了，还没算出来，机器中毒了？没有，是需要计算的量太大了，而到目前为止，我们还只有一个骑手，一个顾客……
在顾客的投诉电话打爆之前，老板瞪着血红的眼珠子吼道：“要在骑手与顾客之间快速找到最短路径，怎么破？”
动态规划法
所有人的眼睛落在了公司里最资深的那位老码农身上，他不紧不慢地扶了下深度眼镜框，捋了把稀疏油腻的头发，深吸了一口气，然后吐出来四个字：“动态规划”。
老码农毅然起身，走到白板前拿起碳素笔，开始讲解。
骑手要达到顾客家，必然要穿过十五条街区，而现实情况更为复杂，诸如道路拥堵、断路施工、高峰限流等。为了简化讨论，将不利因素统合为一个权值，即经过这条路所要付出的代价，数值越高越不利。
对于这种场景，动态规划法的思想是最适合的。首先解释一下，动态规划的基本思路类似于分治法。就是将一个大问题划分为一个一个独立的子问题进行解决。所有的子问题解决之后，将子问题的解进行一次归纳，即得到原始问题的最终解。
回到我们所要解决的核心问题上来，就是如何尽快得出骑手的最佳路线？我们可以给街区编号，那么骑手站在一号街区，他最终的目标是要最快地到达十五号街区。
基于动态规划法的思路，我们只需要考虑如何让骑手最快到达下一个街区就可以，而不必把所有街区的可能路径都计算出来。
例如，骑手站在一号街区，我们只要找到通往二号街区的最短路径，把它记下来就可以；当他到达二号街区时，再计算出到达三号街区的最短路径……
以此类推，我们只要十五轮计算，每轮只计算出当前街区路径的最小值，最后将十五个最小值的路径串接起来，通知骑手，出发！
说到这里，老码农潇洒地把碳素笔一甩，补充了一句：“动态规划最大的优点就在于，它的局部最优解集合就是全局最优解，它将计算量降低了几个数量级。”
迎着众人钦佩的目光，老码农飘然坐回了自己的工位。这时老板把桌子一拍，大喊了一声：“今天晚上加班给我做出来，明天上线！”
大数据
系统初步构建好了，商家接入进来了，骑手也招募了，宣传打出去了，客户真的下单了。老板天天在后台盯着数据看，一开始还面有喜色，到后来脸色越来越阴沉。
终于有一天，老板又嚷开了：“对门新开了一家在线外卖，他们的送达时间怎么平均能比我们快两分钟？谁能告诉我为什么！”
没有人可以回答这个问题，办公室里安静的让人窒息，这时候还是老码农慢条斯理地说：“如果我没猜错，他们应该是算法加上大数据的方式，提高了效率。”
老码农又走到白板前开始了讲解。
在程序算法的世界里，骑手们仅是加权有向图中的一个节点，他是男是女、年纪多大、百米跑成绩是多少……这些数据统统没有。
而算法仅是规划出骑手的行动路线，骑手的绩效水平，则取决于他自身的各项要素了。如果将骑手的身体数据，以及他在送餐时的各项数据全都记录下来，那么就能形成他个人的效能数据库。
我们通过大数据的方式，可以对每一位骑手的绩效能力进行评估。然后计算出送餐任务所需耗费的效能点数，再除以他个人的效能值，就得到了最短送餐时间。
每次骑手完成任务，系统中他的效能值都会更新，而为了追求最快速度，系统就会奖励他的最高效能表现，而惩罚低效能表现。这样骑手们就会越跑越快了。
而且大数据对于处理突发情况特别管用，例如某条道路突发事故导致无法通行时，只要骑手没有通行记录，就可以马上标记为无效路径，节省大量时间。
说到这里，老板两眼放光，又一拍桌子，大喊：“还等什么，赶紧给我上！”
老板看看大家有些畏缩的样子，甩下一句话“我不管你们用什么方法，只要我们跑得比对门那家快，所有人加薪50%。” 然后就冲出门去盯着出餐最慢的那户商家了。
技术之外
好了，技术的话题讨论得差不多了，可以谈谈技术之外的那些事儿了。《外卖骑手，困在系统里》关注的是骑手们，而我想谈一谈创造系统的程序员们。
在那篇文章中对程序员们有一些简单的描绘，但还是有些脸谱化了，像是凭着大众印象写出来的。当然，“人物”还是一个很了不起的公号，他们对骑手做的深度调查就极具力量。
只是我想，如果他们有一天能对程序员这个群体也有这样深度的访谈和调查，那么一定也能写出有血有肉的程序员们来。
回到我在文中为了趣味性，加入的“老板”与“老码农”角色。虽然是戏说，但现实中其实在推进工作时，也差不多会发生这样的对话。
只不过有的老板会更彪悍，有的老板会温和一些。说程序员不知人间疾苦，只知埋头在空调房里写程序，这是不准确的。不说程序员也是一项高危职业么。
不知道大家有没有看出来，系统抽在骑手们身上的鞭子，首先就是老板抽在程序员身上的。而老板，也并不是穷凶极恶的大坏蛋，他们也是有理想、有梦想，想改变世界的创业者。
只不过在残酷的商业竞争中，大家比拼的是下限，走到劣币驱逐良币的道路上去了。说到底，这种剩者为王的理念，给社会产生的破坏远大于它所带来的效益。
不过我还是相信，技术的进步终将会消弥商业竞争的残酷。无论是骑手还是程序员们，都会活得更轻松、更有尊严。
