最近参与开发的小程序2.0终于上线了。我将原项目的登录绑定，与打开跳转相关的内容整体重构了一下。在这里分享一下项目开发中登录可能遇到的问题。
首先登录功能在多数项目中都会有。
简单的说。这是用户通过一个身份标示进行授权，前端得到获取数据权限的过程。
这个身份标示可以是多样的，比如手机号与验证码，微信小程序中返回的code（获取openID），或者其他各种平台的sdk中，授权功能返回的唯一ID。有些项目也允许使用设备唯一ID（早年的各种设备唯一编码，udid，openUDID，IMEI等等）。
有些项目在设计阶段不严谨，会导致一个实际用户产生2个甚至多个账户的情况。这种情况多数由于允许多种标示进行注册（注意不是登录）造成的。
举个🌰：
app端手机号注册。
小程序端照顾用户体验，允许用户通过微信ID注册，然后绑定手机号。
当用户在2端都注册过后，再绑定手机号时，他已经注册2份用户数据。如果要进行合并，多数时候是难以实现并且容易引发各种问题。
还好，目前的项目是以手机号作为唯一标示，然后绑定微信ID的方式做的。这种方式虽然会强制用户先进行手机号登录，但至少能避免部分问题。
强烈建议使用微信系统进行登录或注册的。统一使用UnionID作为唯一ID，这是微信为开发者提供的多平台统一ID方案：包括公众号、移动应用，小程序。获取方式:点这里查看
好了，接下来回到最开始的问题，我为什么要重构之前项目的登录部分呢，当然最重要的是因为他有bug，第二是原开发者已经离开，而那部分代码实在是有些不够，额，优雅。
先简述一下这个小程序有些不寻常的登录流程。
首先，根据微信id获取是否绑定。
这看起来简直平平无奇。成功就进入app，没有绑定就进入绑定/注册流程。
但这个项目还有一个一个逻辑（已经废弃），如果用户没有订单数据，就强制登出，让他更换手机号登录。
看起来也不是很麻烦～～～重点来了
这个小程序项目的注册/绑定流程有3个页面！
如果这个情况出现在app或者h5项目中，完全没有什么问题～～因为app中用户的页面流转是完全可控的，你可以有自己的页面流转控制
但是小程序中却。。。微信的相关文档:https://developers.weixin.qq.com/miniprogram/dev/framework/runtime/operating-mechanism.html
这里重点描述一下小程序入口的问题。小程序的入口是不固定的。用户通过不同方式进入时，路径参数中的页面就会成为小程序开启的第一个页面。同时会清除路由的历史信息（清空页面栈）！
而用户进入/退出小程序的时机是不可控的。当你的一个功能需要在多个页面间流转时，就会因为这个机制而多出很多的页面逻辑
我想小伙伴们肯定已经发现了为什么会多出很多页面逻辑
再举个🌰：
从分享中打开小程序，进入分享页-->需要登录-->登录页1-->登录页2-->用户右上角退出了小程序-->从分享中打开：
再次打开的时候如果要求用户按照刚刚的流程再走一遍实在是太不优雅。所以额外增加逻辑，如果这时用户正在登录，那么进入之前的登录流程中。
可是路由被清空了，你没法返回上一页继续登录，只能自己存储状态并跳转，而这只是流程中多种情况中的一个
一个更难吃的🌰：
从分享中打开小程序，进入分享页-->...流程1234-->登录中。。。-->用户右上角退出了小程序-->从分享中打开：
这时，出现了薛定谔的登录状态！
入口页需要等待登录信息坍塌（返回），才可以进行下一步逻辑。
很多小伙伴在开发过程中不注意薛定谔状态（这只是我随便起的名字～不要在意）。很多时候我们确实不关注信息返回过程中会有什么额外逻辑。加个loading什么的～
但是在这个流程中，等待登录信息返回再进行下一步逻辑变得非常重要！
入口页需要登录信息来进行页面流转，而这个登录信息获取的接口，可能并不是在当前页面内。
在薛定谔的状态下（checking_bind/waiting_login/wait_data/...） 注册回调，代理，接受广播消息等等～～各种方案都有，选一个合适的走起
其实这不是一个多么难的技术问题。然而上一个开发小伙伴就倒在这里～～他没有在这里做额外的等待消息逻辑，导致了这个流程上出现各种问题。（酒吧上线了，回测通过了，一个顾客点了份炸酱面，酒吧炸了～）
剩下的都比较常规，不再赘述。
登录问题到此为止，但其实并不是这一篇的重点
其实想借助登录这个app 中的第一个流程，来说说需求分析这个事情。
软件开发第一（二）步
需求分析这个事情一说出来，还是感觉 平平无奇
很多小伙伴都认为其实自己做了的，只不过需求变化太快（或者是其他借口）。目前大环境来说，确实优秀的产品经理不好找。但是大部分开发小伙伴，需求分析这件事做的也都还有提升空间。
开发小伙伴么很多比较含蓄内敛，需求里模糊的内容，有些小伙伴就按照自己的想法补充，实现完成，验收～～～重做！
还有一些项目设计与平台结构不搭的情况下，开发应该给产品提出专业的意见并解释，这是一个优秀的开发人员需要做的工作。埋头写代码不是程序员的全部工作，至少对优秀的程序员来说，不是。
以这个登录流程为例，他与小程序平台的设计完全不搭。可以参考市面上多数小程序，授权登录功能都是弹窗蒙层类的实现。这个时候就应该
产品经理，拔剑吧，今天不是你死，就是！@#
上面是开玩笑的，我们要动之以情，晓之以理，再看看竞品，正常人就会做出正常的选择。
程序员也是要练口才的各位。至少参与团队开发的程序员，需要清晰明确的表达的自己观点，条理清晰，令人信服（定个小目标～）。
这个时候再说重点是不是晚了点？
说了需求分析的重要，但具体怎么做需求分析，这个事情吧一千个人有一千个多态实现，各位小伙伴也可以多多交流～～方式方法，各种工具
庞有，面向对象知道发，面向对象
面向对象的概念从计算机软件开发中提出来，到现在也已经很久了。小伙伴们耳熟能详，并且熟练使用。个人理解它不光是一种编程范式或者软件开发方法。也是我们分析需求解决问题的一种思考方式。
抽象都做不好～～怎么面向对象
面向对象第一步，就是抽象，个人认为也是最重要的一步。
多数时候我们会自动完成抽象的基础工作。
因为这就是人认识事物的基本方式之一：贴标签
快看，那有个漂亮小姐姐！
你瞬间就给这个路人抽象了几个属性
外貌：漂亮
性别：女（也许吧）
年龄：额。。不是很大？
这种自动完成的抽象一方面依靠经验（你逐步完善的世界观，价值观～还有审美），一方面流于表面（我要在心里呐喊：心灵美才是真的美～～～）
开发过程中，很多小伙伴们面对需求也是自动完成抽象，开始埋头苦干。
‘我艹，不对’（重写吧）
‘等等，好像有什么不对劲’（bug）
下面是脱离程序开发，广义的抽象，小伙伴们可以自行体会。
百度百科，抽象：https://baike.baidu.com/item/%E6%8A%BD%E8%B1%A1/9021828?fr=aladdin
（作为一个程序员，我竟然贴出了百度百科的链接，这不严谨）
做好了抽象，才有后续的封装等等～～
对事物、需求、问题。先定性，抽象出属性、状态，结构。然后再根据抽象出的内容进行分析，这就是我想与小伙伴们分享的软件开发第一步
各位开发的小伙伴们，尤其是经验值攒的不多的～～理论知识决定高度，基础牢固决定下限
小伙伴们在开发过程中遇到的问题，往往不是史无前例的，艰难的，极度复杂的逻辑问题。这些问题的解决方式，避免出现问题的做法，基本上都已经有前人总结出来。都放在了one piece～～
程序员的核心价值不是打字速度，也不是一块熟悉业务的固态硬盘，是脑花
