[討論] FSM狀態機程式架構是不是災難?

軟工

42166

吐泡一下

最近在維護一個交易老程式碼

就像是依照流程圖畫出來的狀態機實作

主狀態機有N個case

每個case又各自註冊可以重複的條件

FSM主要的狀態是有順序的

但是下面登記的function重覆性有87%

一個flag就可以解決的事情搞到變成很巨大的狀態機

有股想砍掉重練的衝動...但是只能自己驗證

QQ

--

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 116.241.146.114 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1656693758.A.975.html

→ ybite1樓我認為看設計良好設計下可以迴避可能問題 07/02 01:05

w1801122樓設計問題…不要怪東怪西 07/02 01:44

→ labbat3樓主管請你來是維護的，亂動手腳而不提出規格變更申請是找死 07/02 01:45

→ Apache4樓不是幾乎所有DP教材都會講到SM 07/02 01:47

→ pot12345樓87%像的程式碼沒有共用code，這不是fsm的問題吧 07/02 06:16

k7989768696樓IC數位設計都是狀態機啊 07/02 07:06

MacPerson7樓如果改狀態，大家都自己去異動flag就好，那才是真正的 07/02 07:07

→ MacPerson8樓災難 07/02 07:07

TWkobe9樓要看驗證還有主管同意 07/02 07:22

wulouise10樓fsm最好要有辦法auto gen流程圖，不然維護起來很痛苦， 07/02 07:23

→ wulouise11樓而且要是每個流程都在那邊改一堆singleton..算了 07/02 07:23

→ milk83012212樓各有好處吧設計模式看情況用 flag遇到大架構要改直接 07/02 07:48

→ milk83012213樓累死 07/02 07:48

→ tofuflower14樓用 flag 也會有 flag 的雷 07/02 08:45

→ tofuflower15樓如果每個 func 的業務邏輯是獨立的， code 有 87 % 07/02 08:51

→ tofuflower16樓像也不是問題 07/02 08:51

→ tofuflower17樓把看起來一樣的程式碼共用等於把所有業務邏輯耦合在一 07/02 08:53

→ tofuflower18樓起，這更雷 07/02 08:53

kkes000119樓怎麼看都覺得問題是實現架構的人 07/02 09:41

smallcar80120樓沒壞的東西不要修 07/02 09:58

→ alongalone21樓存在必有道理. 人的問題不要怪東西 07/02 10:26

wulouise22樓重複不表示他們可以同時被改 07/02 11:19

NDark23樓大部分是. 原因很複雜不能歸咎於一處. 07/02 11:25

→ NDark24樓最大的問題常發生在幾處: 07/02 11:26

→ NDark25樓- (後續)需求就超出設計之初的範圍 07/02 11:26

→ NDark26樓- 維護的人沒有照著狀態機的方式來撰寫邏輯 07/02 11:27

→ NDark27樓邏輯分離得好就算switch也能運作得很好. 07/02 11:28

→ NDark28樓狀態機有點像是緊錮圈.是頭要去適合圈. 07/02 11:29

→ NDark29樓不是每個開發者/團隊都有受過足夠的訓練能用得好. 07/02 11:29

airtsubasa30樓沒壞的東西不要修，但頻繁修改(例如一樣的邏輯要改n個 07/02 11:36

PTT鄉民日記

[討論] FSM狀態機程式架構是不是災難?

軟工