近期救火的些许感悟

背景

近期由于新上马的项目以及主要技术人员休假，于是只能各处救火，参与到多个项目的多个疑难杂症的解决以及临期项目的关键节点的推进，感觉对于解决问题的认知又有了些许新的认知。下面就简单梳理一下。

救火回顾

三维Gis可视化组件尺寸变化后，比例尺异常问题

在某个项目中，遇到了需要让三维可视化组件尺寸大幅度变化的需求，某个小伙伴实现后发现了一个bug，就是尺寸变化后比例尺也跟着小幅变化貌似还找不到一个确定性的规律，解决了一段时间没有结果，转而求助。
我复现了一遍确实是这样的，感觉虽然变化幅度很小但确实是变化了，而且用户注意力就在这块，很容易发现这个问题。于是建议还是尽量修复，并提供了重新对齐的思路。小伙伴搞了2个小时依然没有什么进展，考虑到项目进度，这个问题先交给我来研究一下，小伙伴去搞别的问题吧。
没办法打开IDE，切换到小伙伴的分支，启动项目，100%复现问题。这个三维可视化组件是内部封装的一个开源组件，至少有开发组件的小伙伴和源码两层支援，我感觉问题不大。于是找到尺寸变化后的地方，这很简单嘛，心理想着。比例尺变化了，那肯定是显示范围不对，加上一个延迟，直接按照应该的组件的长宽比例设定组件的显示范围。试一下，额，不行，果然不行，要是这么简单，小伙伴应该早就解决了。额，对了这个方法不就是我告诉他的思路么，应该早就试过了。
看来得深入研究一下了，于是通过debug找到变化后生效的代码，再打印出找到变化后的组件显示范围。我去，这个显示范围的比例都不是固定的，即显示范围的(东边界-西边界)/(北边界-南边界)，好神奇，但仔细一想确实是这样的因为地球是一个近似球形，相同经度差在不同的纬度下距离必然不同，好吧现在不是感叹的时候，解决问题为第一要务。
于是着手研究其代码，发现其实整个可视化组件并没有一个准确的度量表示目前的比例尺。界面显示的比例尺是通过屏幕中心中心两点的距离反算出来的。那中心两点的距离会变化呢因就是根据需求手动调整了组件的尺寸，而尺寸的变化并不是高和宽等比例的变化于是地图为了适应变化智能的调整了横纵向的显示范围，显示范围的变化导致中心点距离的变化。这也就是说组件内部关于显示范围是有自己的逻辑的，不合理的显示范围会被调整为合理的范围，这并不是一个好的预兆，因为这很可能是内部开源组件实现的问题，那这个问题的解决代价就会很大了。
再回想一下我们要的效果，地图显示的比例尺不变，也就是以下两个条件：1.那个两点的地理上的距离不变;2.地图的中心点不变。其实问题的最终还是回到设定显示区域的API，但这个显示区域是通过精确计算的，才能确保上面的两个条件。
截止目前为止已经花费了小伙伴一天&我半天的时间了。于是我找来组件开发的小伙伴来确认我分析的是否正确，他确定没问题，同时表示尺寸变化的响应策略确实还有待完善。。。
然后上面的思路，梳理了一下实现思路：

1. 获取当前的屏幕中心的水平和垂直距离
2. 以水平距离为准根据组件显示的尺寸得到东西边界长度
3. 以垂直距离为准，根据显示组件的高度得到南北边界长度
4. 根据中心点和长宽值，计算得到显示范围
5. 设定组件的显示范围
6. 延时获取组件的中心距离，以便确认比例尺是否变化
   代码一气呵成，再简单的处理一下几个小bug。搞定，赶紧试试，额还是不行，这个比例尺还是变啊，还不如默认情况变化的小呢。我去，这是什么鬼。赶紧叫来组件小伙伴来检查一下我的代码，额，这个思路应该没问题，代码也没看出问题。就是不行，说明还有我们不知道的东西，小伙伴表示他也一时半会解决不了，后面有时间了回来处理的。考虑到我已经为这个问题投入超过一天的时间了，能够想到的思路都被堵死了，于是只能单独拉了分支大群@小伙伴，然后将这个问题挂起了，同时也通知之前的小伙伴对齐目前的进度和问题。这真是一个bad end。最后我只能总结这个API不听话啊。

单通道影像效果问题解决

这是另一个项目的故事，马上这个项目要发布了，但遇到了一个很大的问题，一个高价值数据的图层显示效果跟预期不符，虽然可以排除掉这个数据但不是想这么多，因为这将直接缩减软件的业务价值，但如果问题和节点最后不可避免的产生冲突只能壮士断腕了。这个可不是我们愿意看到的。于是为了尽可能的在节点前搞定这个问题，找来负责人了解情况，负责人反馈，这个数据跟其他的数据不一样，是单通道的也就是我们所说的灰度图，但在一个特殊的专业处理软件中可以显示为彩色。负责人开始抱怨他也不懂处理软件的操作，找别人帮忙都是连求带哄着，别人还都说很忙，最后他也没办法了。额，好吧，我看看能不能帮着解决一下。负责人本来是没有找我的，但这个项目虽然很小但有特殊意义，我这边看到他应该没有办法按照节点推进完成赶紧主动接入，帮忙解决问题。
基本背景我们应了解清楚了，时间节点也是很明确，如果当天无法将数据处理完成就剔除这个数据。由于这种专业处理软件我也不是很熟，而且安装极为复杂还有授权问题，于是我就带着数据和负责人找了一个专门搞影像处理的人寻求帮助，这个人看过数据后表示确实如负责人所说数据本身是单通道的因此是灰度的，但处理软件有一个颜色映射功能可以将数据渲染为伪彩色，因此在这个软件中是彩色的，但别的软件处理时就是灰色的。“那能否将单通道数据转成多通道数据吗“额，我们没这样用过，应该不能吧。”额，那我们至少应该再试试，看看能不能将数据转换成多通道数据。我找处理小伙伴借了他们有处理软件的一台机器要自己试试，我们伴着机器就上楼了。
经过20分钟的查看，我发现软件有一个导出功能，于是摸索着试试，还有一个渲染颜色映射复选框，我去这不就成了吗。但我又发现不是这么简单的，这个单通道影像是多幅图像组成的，导出功能只能单幅影像导出。至少这是一个进步，好像影像是可以进行拼接的，我赶紧联系处理小伙伴，经过小伙伴的指导，我将多波段影像镶嵌起来，在通过shp过滤得到了最终结果。连摸索带咨询花费了大概两个小时，额赶紧叫来负责人确认结果，没有问题开启下一步处理过程。这个过程虽然形容起来很短，但真正实施起来还是有些难度的，这么短时间能搞定只能说运气还不错。
这个处理软件确实很专业很难用，安装也很困难，但困难总是有的，不要将注意力集中在困难上，而是应该再问题上，总是要试一试的万一成功了呢。

感悟

对于问题量级和行业水准心理有底，快速给出思路

很短的时间要给出大体方向和基本路线，甚至规划好备选路线甚至PlanB。这个感悟在第二个救火过程中体现的比较多，那个项目负责人由于别人给出的意见而错失解决问题的机会。这个专业软件功能极为强大，这么强的软件连一个图像转换功能都没有吗，不应该啊。而PlanB则是通过Python来做一下简单的图像处理。。。。

明确投入边界，适时止损

这个再第一个问题上体现，虽然是一个bad end，但我们已经进行了各种尝试，而且找来了相关领域的小伙伴确认了判断是合理的，就算是再给我两天可能也很难得到实质突破。

不找理由，全力推进

在第二个项目中有很多理由或困难，比如没有人帮忙，比如没有软件，比如没有经验。但实际关键的问题在于小伙伴在这些困难面前已经失去了尝试的勇气和推进的意愿，难以 突破困局。这个要求确实比较高，
但这往往是一个普通打工人和高潜小伙伴的区别。

总结

因此我们在解决一些关键或困难的问题时要关注两点：1. 关注问题，不找理由全力突进。2. 明确边界，及时止损。

来源：卡萨巴