pup软件开发过程特点 (pup 软件)
本文目录导航：
pup软件开发过程特点
什么是人啊
如何绘画状态机来描述业务变化
对于设计过商品、订单、优惠券等复杂功能的产品经理（PM）来说，描述清楚功能的本质会遇到挑战。
技术团队会不断追问：有几种状态？如何转移？何时转移？系统根据什么条件判断状态？这样的问题，往往是因为缺乏清晰的状态定义和转换规则。
本文将深入探讨如何使用状态机来描述业务变化，以及状态机的原理和应用方法。
为什么需要使用状态机？让我们从一个亲身经历的例子开始。
去年，我在设计电商系统的订单模块时，就遇到了上述问题。
最初，我参照淘宝的订单系统，将订单状态设计为待付款、已付款、已发货、已完成和已关闭等五种状态。
然而，上线后很快就发现了问题：付款之后直接传给仓库发货，导致很多订单信息有误时来不及修改；用户下单后想修改地址或商品，而发货信息已经传给仓库，修改起来非常困难。
因此，我们不得不新增了一个中间状态“已确认”，让客服审核无误后，再传给仓库进行发货流程。
随着业务的发展，我们又引入了退款退货功能，需要引入“退款中”状态，并且增加退款子状态机、退货子状态机。
这些变化最初是通过文字描述和流程图来表示的，但服务端的开发人员难以理解，不得不多次确认。
后来，我研究了状态机的概念，发现使用一张图就可以清晰地表示所有状态及转换条件，这极大地简化了沟通。
状态机的来源和发展状态机最早起源于电路设计领域，用于根据电路信号按照预设状态进行转移，协调相关信号动作并完成特定操作。
后来，这个概念被软件编程领域继承，用来表示有限多个状态以及在这些状态之间转移和动作的模型，称为有限状态机（FSM），是常见的软件设计模式之一。
对于产品经理来说，理解和应用状态机的概念，可以更好地阐述业务实体的功能本质，并让技术团队更容易理解。
如何定义状态机？从产品经理的角度来看，状态机是用来表示业务实体的所有状态以及相互间的转移关系的模型。
业务实体可以是客观上可以相互区分的事物，如订单、优惠券、商品等。
对于大部分对象，尽管存在状态的概念，但不一定需要画出状态机图。
在本文中，我们将重点探讨状态机的描述方法、常见状态机实例以及如何画出状态机。
状态机的描述方法文字描述是最古老的方法，但繁琐且不易理解。
表格可以更系统地描述状态和转换条件，但不够直观。
图形是最推荐的方法，通过圆角矩形表示状态，有向线条上的文字表示条件，线条的方向表示状态迁移。
一般从左向右画图表示初始到终止的顺序，无需特别标注。
常见状态机实例我们可以通过灯泡状态机和订单状态机等实例来理解状态机的基本概念。
灯泡状态机描述了电灯开关的简单状态迁移，而订单状态机则展示了网购过程中订单状态的复杂变化。
状态机的要素状态机的核心要素包括开始状态、终止状态和中间状态。
当达到终止状态，状态机停止。
在状态机中，条件和动作通常可以合并为一个描述，以明确状态迁移的具体条件。
命名时应站在用户立场，力求标准化。
如何画出状态机通常使用状态图工具如Axure来表示状态机。
在状态图中，“状态”用圆角矩形表示，“条件”用有向线条上的文字表示，线条的方向表示状态迁移。
状态图的起点和终点通常用实心圆圈表示。
在画图时，应去除无关状态，确保结构清晰，并考虑状态机的扩展性。
总结与思考并非所有的业务实体都需要产出状态机图，关键在于识别需要清晰定义状态转换的复杂功能。
在设计过程中，可以考虑京东小程序首页的领券功能、电商领域中优惠券功能模块等，尝试画出状态机图，以优化用户体验和业务流程。
此外，思考如何通过状态机图提升设计的可理解性和可维护性，对于提高团队协作效率具有重要意义。
[因为我不懂啊]-什么是状态机编程（设计模式）（3）
上一篇文章写完之后，我一直在想做一个游戏示例，想将之前学到的状态机模式运用在其中。
然而一直遇到各种奇怪的bug（之后写出来），所以一直没有完成这件事。
而且加之自己又犯懒了，所以我决定做一件更简单的事，以更容易接近的目标来引诱懒的不行的自己。
废话说完，来说正经事了。
前几天认真看了一篇 博客-游戏状态机（侵立删），觉得挺不错的，建议盆友们认真看一看。
读完博客之后，之前计划的示例貌似有了头绪，（废话型）总结出来，实现一个游戏状态机结构需要进行如下几步：
我要做一个简单的UI切换示例，所以简述需求就是: 打开程序进入主界面，主界面中点击开始游戏，进入游戏界面，游戏界面中点击结束游戏，进入结算界面，结算界面可以点击回到主界面，进入主界面，也可以点击重新开始游戏，再次进入游戏界面。
从需求描述来看，状态有三个:
事件有四个:
然后（装模作样的）画了一个状态转换表：
之前一篇文章中有提到过的，在Cocos2d-x游戏开发中，刚好使用Scene来作为控制器，由Scene来控制各层的出现和消失。
这里贴出Scene的源码(完整的源文件，包括了后续步骤才会出现的状态基类，以及派生的状态类)：
上面可以看到，Scene中主要包含了:
包含了以上内容，本示例中的这个Scene就能起到控制器的作用了。
状态基类是很有必要的，为了达到各个同级状态都能通过同一个控制器来进行状态转换的目标，各个状态类进行切换时必须有一套统一的流程。 这里贴出本示例中状态基类的源码:
这个源文件中包含了:
所有的派生状态类都会 include 这个文件，实现虚基类 GameTwoState 中的方法，所以所有的状态类都有统一的切换流程:
而且在完成某个事件，需要进行状态转换时，可以通过发送自定义事件来完成消息的传递，自定义事件名放在这里也是为了方便起见。
这里直接贴出几个State的源码了，其中包含注释，废话就不重复再写了:
到这里，上面所提到的步骤全部进行完了。
这个UI切换的状态机示例也就完成了。
在中，直接进入Scene中:
进入主界面 :
此时的Log:
点击Start，进入游戏界面 :
此时的Log:
<Exit>->MainLayer <Enter>->GameLayer <Execute> ->GameLayer
点击Over，进入结算界面 :
此时的Log:
<Enter>->GameLayer <Execute> ->GameLayer [Event]->Game_Over <Exit>->GameLayer
<Enter>->ResultLayer <Execute> ->ResultLayer
点击Replay，重新进入游戏界面 : 此时的Log:
<Enter>->GameLayer <Execute> ->GameLayer [Event]->Game_Over <Exit>->GameLayer
<Enter>->ResultLayer <Execute> ->ResultLayer [Event]->Result_Replay <Exit>->ResultLayer
<Enter>->GameLayer <Execute> ->GameLayer
点击Over，再次进入结算界面，然后在结算界面点击Home，回到主界面 上面的两次操作完成后，Log如下:
<Enter>->GameLayer <Execute> ->GameLayer [Event]->Game_Over <Exit>->GameLayer
<Enter>->ResultLayer <Execute> ->ResultLayer [Event]->Result_Replay <Exit>->ResultLayer
<Enter>->GameLayer <Execute> ->GameLayer [Event]->Game_Over <Exit>->GameLayer
<Enter>->ResultLayer <Execute> ->ResultLayer [Event]->Result_Home <Exit>->ResultLayer
<Enter>->MainLayer <Execute> ->MainLayer
这里用FSM实现UI切换示例只是众多方法中的一种，暂时还没有去比较它们的优劣。(使用markdown编辑器的经验值+1)
可能性多种多样，如果有小伙伴比较过这些方法。
求留言告知，求分享经验。
phper