大道理讲了很多，来实战一下。首先来看看，我们深恶痛绝的历史问题。光讲理论太枯燥，也难以理解，会以实际例子的形式进行分享总结。
历史问题
错误思路
起因：某项目反馈小程序端有异常，下午定位是OK的，但无法获取具体地址，影响了正常的业务流程。今天上午是好的，前几天没大规模推广使用也没问题。
经过：获取项目源代码，然后交由研发人员排查。前端同事表示，这个定位是调用服务端的接口，目前调用接口失败。后端同事排查，发现使用的是高德地图的API，该API调用返回错误码。查找官方document，发现是接口调用次数超额。
定性：高德地图API次数不足，通过切换或增加证书解决。目前使用个人证书，配额6000。企业证书为个人证书500倍，300万。根据现有业务场景，企业证书能满足定位请求。
结果：先让项目团队相关人员申请多几个个人证书，优先让业务正常跑。然后联系企业，申请企业证书。
例子很偏技术，但贴合主题。很多时候，我们的思考到上述的结果就结束，开始行动了。我个人认为这种是有用的思考，而不是有效的思考。即便是我们认为思维相对严谨的程序员，在进度压力下通常也会埋雷。为更好的帮助产品落地，我们遇到问题要仔细分析。
三段论分析
以上的思考过程，在我认为可以转换为三段论的形式。但是，不是一个，而是两个。
所有调用接口错误都是接口端的问题，项目调用接口错误，所以是接口端的问题
高德的定位接口都是限额的，我们使用的是高德的定位接口，所以我们是被限额的。
我个人认为，两个三段论都是错误的。我来讲一下我的思路，看看有没有道理：
首先讲第二个三段论，乍一眼看过去是完全合理的，其实犯了三个词项的典型错误。高德的接口都是限额的，我们使用的是高德Web服务的定位接口，所以我们是被限额的？这里面包含了两个高德接口，一个是正在使用的Web服务接口，的确是限额的。但是，高德的定位接口包含Web服务、Android、iOS和JS。更重要的是，Android、iOS和JS等前端API，是不限额的。
推翻了第二个三段论，我们再来看看第一个。第一个三段论是最可怕的，在很多企业的研发体系里面，这是公理般的存在。本人认为，这很有甩锅的意思，头痛医头脚痛医脚。目前高德地图封装JS API，分为Web端和微信小程序。那么，是不是关于获取定位对应地址的操作，应该交由小程序端来完成？这么做有三大好处，第一是解决了API限额，第二加快定位速度，最后降低服务器并发（上下班时间统一打卡定位）。所以从根源来说，根本不是服务端的问题，小程序端更新代码重新上架就好了。
复盘分析
问题解决了，复盘下为啥会挖下这个坑：
小程序官方没有提供获取精准地址的能力，颗粒度只到县级市\区
高德当初没有微信小程序的SDK，只能使用Web端
原有研发离职，交接混乱，导致这块的预警没做好
我们还是要保持清醒，认识到直接原因和根本原因。不过说实话，一些应该由前端做，由于各种原因放到了服务端的事情，是司空见惯了。
全新问题
错误思路
起因： 某项目需求调研过程中，项目经理直接找到总部技术平台研发，说要增加小程序端推送的能力。希望研发迅速拟定方案，方便引导客户。
经过： 研发询问具体诉求，项目反馈下订单后，订单审批流和收发货业务流都需要推送给对应人员。研发查看小程序官方文档，了解现有小程序的推送能力
定性： 小程序官方推送触发条件比较严格，无法完整实现客户的诉求。使用WebSocket，则需要保证小程序在前台，作为工具类小程序，这个不太友好。公众号这方面就相对灵活，只要小程序绑定公众号后使用公众号的能力即可。
结果：使用小程序+公众号的组合形式，快速落地。
又是一个偏技术的例子，上面的思考过程看起来合理，但又走在错误的路上了。
三段论分析
以上的定性思考过程，简单的转换为三段论的形式：
小程序官方的推送是推送给小程序使用者本人，我们推送是给另一个小程序的使用者，所以我们无法使用小程序官方的推送
工具类小程序都是即用即走基本不在前台，我们是工具类小程序，所以我们基本不在前台。
WebSocket自建的推送需要小程序在前台，此种小程序基本不在前台，所以我们基本不能使用WebSocket的推送
公众号推送没有前台和最近7日内活跃的约束，我们希望推送没有前台和最近7日内活跃的约束，所以公众号的推送适合
这里面错的是第一个三段论，不是无法使用小程序官方的推送。我们知道，技术上最不缺的就是黑科技。官方的限制，很多时候是有漏子可以钻的（Android的保活骚扰、绕过应用市场的热更新等）。比较尴尬的是，直接百度一下，第一页就有相关的方法：
这个方法是讨巧的，还是要满足最近7日内活跃的条件，但在实际业务上是7日内活跃是95%以上的。实际策略就是用户实用小程序的时候，每次提交表单，都偷偷的把推送码存起来。然后需要推送的时候，从这里面取过期日期最早的推送码（超过7日的就废弃掉）。成功实现：A下单，推送给B审批处理。
另外还满足了其他的扩展场景：
无条件的定时自动推送，如最常规的每日上下班打卡推送
满足特殊条件的定时自动推送，如月末自动下属的KPI完成情况
备注：图片来源网络，本人与小打卡无任何关系
立场决定方案
当然，公众号的方案也是可行的，只是背离了技术平台的初衷。这个方案复用困难，项目自行落地就行。如果技术选型决定公众号方案，也需要对业务方案重新包装。18年9月，小程序发布了公众号关注组件，就可以更方便的让小程序和公众号进行绑定了。完全可以使用公众号关注组件，以更好的推动项目落地。
总结归纳
下面简单总结下，个人认为的行动方法。分为历史问题和全新问题，都是短句，不做过多的展开解释。
应对历史问题报障，现有思路大体如下：
应对全新问题，现有思路大体如下：
资源评估里面，综合现有项目合同、人力资源和功能上线的时间考虑。
效率评估，是评估这个方案，在业务执行中，会否造成效率下降。
业务线，是要综合其他业务线的一些诉求，非通用平台类的诉求忽略掉。
