作者IhateOGC (我讨厌)
看板Soft_Job
标题[讨论] FSM状态机程式架构是不是灾难?
时间Sat Jul 2 00:42:00 2022
吐泡一下
最近在维护一个交易老程式码
就像是依照流程图画出来的状态机实作
主状态机有N个case
每个case又各自注册可以重复的条件
FSM主要的状态是有顺序的
但是下面登记的function重覆性有87%
一个flag就可以解决的事情搞到变成很巨大的状态机
有股想砍掉重练的冲动...但是只能自己验证
QQ
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 116.241.146.114 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1656693758.A.975.html
1F：→ ybite: 我认为看设计 良好设计下可以回避可能问题 07/02 01:05
2F：推 w180112: 设计问题…不要怪东怪西 07/02 01:44
3F：→ labbat: 主管请你来是维护的，乱动手脚而不提出规格变更申请是找死 07/02 01:45
4F：→ Apache: 不是 几乎所有DP教材都会讲到SM 07/02 01:47
5F：→ pot1234: 87%像的程式码没有共用code，这不是fsm的问题吧 07/02 06:16
6F：推 k798976869: IC数位设计都是状态机啊 07/02 07:06
7F：推 MacPerson: 如果改状态，大家都自己去异动flag就好，那才是真正的 07/02 07:07
8F：→ MacPerson: 灾难 07/02 07:07
9F：推 TWkobe: 要看验证还有主管同意 07/02 07:22
10F：推 wulouise: fsm最好要有办法auto gen流程图，不然维护起来很痛苦， 07/02 07:23
11F：→ wulouise: 而且要是每个流程都在那边改一堆singleton..算了 07/02 07:23
12F：→ milk830122: 各有好处吧 设计模式看情况用 flag遇到大架构要改直接 07/02 07:48
13F：→ milk830122: 累死 07/02 07:48
14F：→ tofuflower: 用 flag 也会有 flag 的雷 07/02 08:45
15F：→ tofuflower: 如果每个 func 的业务逻辑是独立的， code 有 87 % 07/02 08:51
16F：→ tofuflower: 像也不是问题 07/02 08:51
17F：→ tofuflower: 把看起来一样的程式码共用等於把所有业务逻辑耦合在一 07/02 08:53
18F：→ tofuflower: 起，这更雷 07/02 08:53
19F：嘘 kkes0001: 怎麽看都觉得问题是实现架构的人 07/02 09:41
20F：嘘 smallcar801: 没坏的东西不要修 07/02 09:58
21F：→ alongalone: 存在必有道理. 人的问题不要怪东西 07/02 10:26
22F：推 wulouise: 重复不表示他们可以同时被改 07/02 11:19
23F：推 NDark: 大部分是. 原因很复杂不能归咎於一处. 07/02 11:25
24F：→ NDark: 最大的问题常发生在几处: 07/02 11:26
25F：→ NDark: - (後续)需求就超出设计之初的范围 07/02 11:26
26F：→ NDark: - 维护的人没有照着状态机的方式来撰写逻辑 07/02 11:27
27F：→ NDark: 逻辑分离得好就算switch也能运作得很好. 07/02 11:28
28F：→ NDark: 状态机有点像是紧锢圈.是头要去适合圈. 07/02 11:29
29F：→ NDark: 不是每个开发者/团队都有受过足够的训练能用得好. 07/02 11:29
30F：推 airtsubasa: 没坏的东西不要修，但频繁修改(例如一样的逻辑要改n个 07/02 11:36
31F：→ airtsubasa: 地方，然後变数还不一样) 那到底要不要修呢 07/02 11:36
32F：推 Odia: 在没有提出更好的设计前别说是灾难 07/02 13:11
33F：→ s678131: FSM明明是个好东西 07/02 13:46
34F：→ dnabossking: 我接收过这种赚钱中程式码，我直接翻写掉了，我满肯 07/02 14:19
35F：→ dnabossking: 定 07/02 14:19
36F：→ dnabossking: 不是状态机的问题 07/02 14:19
37F：→ DrTech: 标题是灾难，看一个程式有问题，就说整个世界有问题。 07/02 14:59
38F：→ alan3100: 差多了吧...感觉上是你不知道为何要用FSM 07/02 15:25
39F：→ alan3100: 逻辑规模大到觉得测试麻烦大概就可猜想你不应该改成flag 07/02 15:43
40F：嘘 wave1et: 自己为是阿，你快搞懂後把状态数合并吧 07/02 17:02
41F：推 easyman: 使用FSM 肯定不会太灾难, 用flag 才灾难 07/02 17:19
42F：推 chuegou: 听你在屁 10几个flag在那边if else你连文件都写不出来 07/02 17:45
43F：→ chuegou: 你是不是要说没文件是灾难 07/02 17:46
44F：→ lturtsamuel: 谁叫你要用状态来实作fsm，用class或variant不好吗 07/02 19:48
45F：嘘 pttano: 你才是灾难，跟程式没关系 07/02 20:58
46F：嘘 ichunlai: 用flag才是灾难 07/02 22:39
47F：推 viper9709: 三楼正解 07/02 23:54
48F：→ peter98: 这个还真不一定 07/03 00:38
49F：推 APTON: 有办法提供sample code给大家讨论吗？不然也只是听你抱怨而 07/03 00:54
50F：→ APTON: 已 07/03 00:54
51F：→ molimoli: 怎麽感觉你比较雷 07/03 01:00
52F：→ Lipraxde: 不然有更好的写法吗？ 07/03 08:31
53F：嘘 KanzakiHAria: 笑死 自己不会改状态机说那是灾难 07/03 11:58
54F：推 za755188: 状态机如果文件还在 不容易大灾难 07/03 17:56
55F：→ za755188: 至少很容易理解他里面在干嘛 07/03 17:58
56F：→ revorea: flag灾难中的灾难 07/04 00:52
57F：推 CaptainH: 没有FSM的话就是一堆if-elseif 有比较简单？ 07/04 08:07
58F：→ bear1414: FSM是有用的控制架构 会变成灾难通常是用的人的问题 07/04 11:08
59F：→ bear1414: 另 砍掉重练可以 但test case涵盖率要趋近99.9%以上 07/04 11:10
60F：→ bear1414: 尤其是边界条件或很少出现的条件的test都要涵盖 07/04 11:11
61F：→ notBeing: 先生出100% coverage 的test env再改阿XD 07/04 13:00
62F：→ freef1y3: flag是灾难 所以把flag每个组合都弄成state就不是灾难了 07/04 14:38
63F：→ hongsiangfu: 扩展便利，修改便利，过度最佳化不一定是好事 07/05 12:08
64F：推 snaketsai: 若真如你说，那应该有大量的状态转换可以缩减吧，离散 07/07 13:57
65F：→ snaketsai: 数学基本概念 07/07 13:57