吐泡一下
最近在维护一个交易老程式码
就像是依照流程图画出来的状态机实作
主状态机有N个case
每个case又各自注册可以重复的条件
FSM主要的状态是有顺序的
但是下面登记的function重复性有87%
一个flag就可以解决的事情搞到变成很巨大的状态机
有股想砍掉重练的冲动...但是只能自己验证
QQ

我认为看设计 良好设计下可以回避可能问题

设计问题…不要怪东怪西

主管请你来是维护的，乱动手脚而不提出规格变更申请是找死

不是 几乎所有DP教材都会讲到SM

87%像的程式码没有共用code，这不是fsm的问题吧

IC数位设计都是状态机啊

如果改状态，大家都自己去异动flag就好，那才是真正的灾难

要看验证还有主管同意

fsm最好要有办法auto gen流程图，不然维护起来很痛苦，而且要是每个流程都在那边改一堆singleton..算了

各有好处吧 设计模式看情况用 flag遇到大架构要改直接累死

用 flag 也会有 flag 的雷如果每个 func 的业务逻辑是独立的， code 有 87 %像也不是问题把看起来一样的程式码共用等于把所有业务逻辑耦合在一起，这更雷

怎么看都觉得问题是实现架构的人

没坏的东西不要修

存在必有道理. 人的问题不要怪东西

重复不表示他们可以同时被改

大部分是. 原因很复杂不能归咎于一处.最大的问题常发生在几处:- (后续)需求就超出设计之初的范围- 维护的人没有照着状态机的方式来撰写逻辑逻辑分离得好就算switch也能运作得很好.状态机有点像是紧锢圈.是头要去适合圈.不是每个开发者/团队都有受过足够的训练能用得好.

没坏的东西不要修，但频繁修改(例如一样的逻辑要改n个地方，然后变量还不一样) 那到底要不要修呢

在没有提出更好的设计前别说是灾难

FSM明明是个好东西

我接收过这种赚钱中程式码，我直接翻写掉了，我满肯定不是状态机的问题

标题是灾难，看一个程式有问题，就说整个世界有问题。

差多了吧...感觉上是你不知道为何要用FSM逻辑规模大到觉得测试麻烦大概就可猜想你不应该改成flag

自己为是阿，你快搞懂后把状态数合并吧

使用FSM 肯定不会太灾难, 用flag 才灾难

听你在屁 10几个flag在那边if else你连文件都写不出来你是不是要说没文件是灾难

谁叫你要用状态来实作fsm，用class或variant不好吗

你才是灾难，跟程式没关系

用flag才是灾难

三楼正解

这个还真不一定

有办法提供sample code给大家讨论吗？不然也只是听你抱怨而已

怎么感觉你比较雷

不然有更好的写法吗？

笑死 自己不会改状态机说那是灾难

状态机如果文件还在 不容易大灾难至少很容易理解他里面在干嘛

flag灾难中的灾难

没有FSM的话就是一堆if-elseif 有比较简单？

FSM是有用的控制架构 会变成灾难通常是用的人的问题另 砍掉重练可以 但test case涵盖率要趋近99.9%以上尤其是边界条件或很少出现的条件的test都要涵盖

先生出100% coverage 的test env再改阿XD

flag是灾难 所以把flag每个组合都弄成state就不是灾难了

扩展便利，修改便利，过度最佳化不一定是好事

若真如你说，那应该有大量的状态转换可以缩减吧，离散数学基本概念