另类架构之驾车感悟.docx

? ? ? ? ? ? ? ? 【另类架构】之驾车感悟 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 本系列说明 遥想当年研发们仰视的架构师，一出手一出口必是一套套(?)，让人感觉他们如扫地神僧般深不可测，反驳都找不到趁手的词汇，虽然当时总觉得哪里不对。现而今不同了，架构师理论方面的书籍或者视频资料已然汗牛充栋，整个程序员群体都可以或多或少说上一些架构理论，可能理解不深刻，但是起码有武器可以拿来跟架构师怼。所以，现在架构师真的没那么容易混了。本文(或者系列???...如果我不懒的话)的立意与常规的架构讲述套路不同，笔者想通过生活小细节或者小启发来延伸出一些架构思想，以期让人有更加深刻的理解。 最近干货的出货量大大降低，实在是精力不太够(其实正在酝酿，敬请期待)。最近的几篇都是生活中的灵光一现，写出来的东东竟然也有不小的启发性和可读性。今天要说道的，正是迎着朝阳驾车上班途中偶感所得。 变道提前打灯 上海中环和罗山高架路上的不少电子警示牌，不厌其烦地提示着变道请提前3秒打转向灯，以前看到了也就看到了，因为笔者一直很守法，一般提前5秒就打了，所以此警示从未惊起什么波澜。某日清晨脑回路猛然搭住，就想如果变道不打灯被视作违章的话，这个识别的程序逻辑该怎么设计呢？ 砍材不误磨刀功，不了解的领域准备工作还是要充分调研的： 大众熟知的闯红灯识别，步骤是通过路口的三个感应线圈触发摄像头的三次拍照，命中三次就视为违章，笔者开始也是想当然的认为摄像头大部分都是靠拍照。 后来跟专业的同学求证，新一代交通摄像头的工作原理其实大约是这样子的：摄像头会持续拍摄交通情况的视频，而在摄像头所在位置附近会有个本地的存储器和处理器，视频就存储在那里，而后处理器会基于图像识别或者人工智能blablabla等技术手段分析视频中的违章情况，一旦识别出就会截取视频生成图片，最后这些高清截图会上传到远程的市局服务器存储，而违章截图也是从此而来（该信息只是单方面求得，如有偏差欢迎指正）。 继续又去查了一下，汽车转向灯的频闪间隔大约是1Hz，也就是一秒钟闪烁一次，当然也有0.5秒闪烁一次的，这个汽车行业和国家并没有硬性规定。 抛开图像识别的领域不谈，剩下的实现难度在哪里呢？且让我直接写三个案例来阐明： Case 1 变道前的4.01秒开启转向灯，到3.01秒的时候转向灯刚好熄灭，到2.01秒的时候转向灯再次亮起。 Case 2 变道前的4.99秒开启转向灯，到3.99秒的时候转向灯刚好熄灭，到2.99秒的时候转向灯再次亮起。 Case 3 需求只提到了提前3秒这个下限值，那上限值应该是多少呢？我可否提前5秒打转向，甚至提前1分钟打灯呢？很明显间隔太久的转向灯完全没有意义，所以这个需求描述是有缺陷的。 剖析解读 Case 1 2两个案例类似，都在3秒前打灯了所以肯定不违章，但是3秒这个时点上转向灯都是熄灭状态。视频分析所需的时间窗口当然不能卡在3秒这个时点上，那么需要放大到多少合适呢？案例1的时间窗口必须不小于3.02秒，案例2不小于4秒。注意，这里说的是时间窗口的下限。 而Case 3主要说的是时间窗口的上限，因为我不可能把时间窗口设置到无限大，按照交通实际情况，1分钟开外的转向警示基本无意义了。经查交通法规里确实没有这方面的描述，看来对于“提前”这件事情大家都知道很难量化的定义它。 再考虑一下需求设计问题： （架构师的基本素质之一 --?质疑需求明确需求） 1. 是选择提前“时间”合适还是提前“距离”合适？选择“时间”就会出现上面的时间窗口临界问题。选择“距离”，在不同的车速状况下，“车速”越快打转向灯的提前距离就应该越大，若是需要再严谨些的描述，这个“车速”应该是前后车的“相对速度”，想想是不是如此？ 2.?对于汽车的转向灯频闪频率国家似乎并没有一个统一标准，那就意味着有长有短，进一步造成时间窗口的不可确定性。 3.?闪烁次数前文也简单提过，基于频闪频率的最小闪烁次数也需要保证，否则连2S的时间窗口都看不到转向灯亮起过，这视频没法分析了。 另外，基于3个案例假设我们设定时间窗口为变道前的[-5s, -3s]，表示这个时间区间内必须出现过转向灯的亮起状态。如果某个极端情况转向灯在[-5s，-3s]仅亮起一次，(-3s, 0) 再也没有亮起过，也就是转向灯总共就闪了一次而已，警示作用很不明显，那么对于转向灯的最小闪烁次数是否有要求呢？经笔者对自己车子的多次测试，开启一下转向即使马上关闭，转向灯也至少闪烁3次。(对测试当日跟我车屁股后面的司机师傅们深表同情，你们可能一直在骂前面那个傻叉为什么一直在打转向？) 解决方案 透过问题看本质无非就是时间窗口的临界设定问题。 首先简单放大时间窗口这么低级的方案肯定为架构师所不齿，因为再大的时间窗口