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

看板Soft_Job作者 (我討厭)時間1年前 (2022/07/02 00:42), 編輯推噓9(15642)
留言63則, 40人參與, 1年前最新討論串1/2 (看更多)
吐泡一下 最近在維護一個交易老程式碼 就像是依照流程圖畫出來的狀態機實作 主狀態機有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

07/02 01:05, 1年前 , 1F
我認為看設計 良好設計下可以迴避可能問題
07/02 01:05, 1F

07/02 01:44, 1年前 , 2F
設計問題…不要怪東怪西
07/02 01:44, 2F

07/02 01:45, 1年前 , 3F
主管請你來是維護的,亂動手腳而不提出規格變更申請是找死
07/02 01:45, 3F

07/02 01:47, 1年前 , 4F
不是 幾乎所有DP教材都會講到SM
07/02 01:47, 4F

07/02 06:16, 1年前 , 5F
87%像的程式碼沒有共用code,這不是fsm的問題吧
07/02 06:16, 5F

07/02 07:06, 1年前 , 6F
IC數位設計都是狀態機啊
07/02 07:06, 6F

07/02 07:07, 1年前 , 7F
如果改狀態,大家都自己去異動flag就好,那才是真正的
07/02 07:07, 7F

07/02 07:07, 1年前 , 8F
災難
07/02 07:07, 8F

07/02 07:22, 1年前 , 9F
要看驗證還有主管同意
07/02 07:22, 9F

07/02 07:23, 1年前 , 10F
fsm最好要有辦法auto gen流程圖,不然維護起來很痛苦,
07/02 07:23, 10F

07/02 07:23, 1年前 , 11F
而且要是每個流程都在那邊改一堆singleton..算了
07/02 07:23, 11F

07/02 07:48, 1年前 , 12F
各有好處吧 設計模式看情況用 flag遇到大架構要改直接
07/02 07:48, 12F

07/02 07:48, 1年前 , 13F
累死
07/02 07:48, 13F

07/02 08:45, 1年前 , 14F
用 flag 也會有 flag 的雷
07/02 08:45, 14F

07/02 08:51, 1年前 , 15F
如果每個 func 的業務邏輯是獨立的, code 有 87 %
07/02 08:51, 15F

07/02 08:51, 1年前 , 16F
像也不是問題
07/02 08:51, 16F

07/02 08:53, 1年前 , 17F
把看起來一樣的程式碼共用等於把所有業務邏輯耦合在一
07/02 08:53, 17F

07/02 08:53, 1年前 , 18F
起,這更雷
07/02 08:53, 18F

07/02 09:41, 1年前 , 19F
怎麼看都覺得問題是實現架構的人
07/02 09:41, 19F

07/02 09:58, 1年前 , 20F
沒壞的東西不要修
07/02 09:58, 20F

07/02 10:26, 1年前 , 21F
存在必有道理. 人的問題不要怪東西
07/02 10:26, 21F

07/02 11:19, 1年前 , 22F
重複不表示他們可以同時被改
07/02 11:19, 22F

07/02 11:25, 1年前 , 23F
大部分是. 原因很複雜不能歸咎於一處.
07/02 11:25, 23F

07/02 11:26, 1年前 , 24F
最大的問題常發生在幾處:
07/02 11:26, 24F

07/02 11:26, 1年前 , 25F
- (後續)需求就超出設計之初的範圍
07/02 11:26, 25F

07/02 11:27, 1年前 , 26F
- 維護的人沒有照著狀態機的方式來撰寫邏輯
07/02 11:27, 26F

07/02 11:28, 1年前 , 27F
邏輯分離得好就算switch也能運作得很好.
07/02 11:28, 27F

07/02 11:29, 1年前 , 28F
狀態機有點像是緊錮圈.是頭要去適合圈.
07/02 11:29, 28F

07/02 11:29, 1年前 , 29F
不是每個開發者/團隊都有受過足夠的訓練能用得好.
07/02 11:29, 29F

07/02 11:36, 1年前 , 30F
沒壞的東西不要修,但頻繁修改(例如一樣的邏輯要改n個
07/02 11:36, 30F

07/02 11:36, 1年前 , 31F
地方,然後變數還不一樣) 那到底要不要修呢
07/02 11:36, 31F

07/02 13:11, 1年前 , 32F
在沒有提出更好的設計前別說是災難
07/02 13:11, 32F

07/02 13:46, 1年前 , 33F
FSM明明是個好東西
07/02 13:46, 33F

07/02 14:19, 1年前 , 34F
我接收過這種賺錢中程式碼,我直接翻寫掉了,我滿肯
07/02 14:19, 34F

07/02 14:19, 1年前 , 35F
07/02 14:19, 35F

07/02 14:19, 1年前 , 36F
不是狀態機的問題
07/02 14:19, 36F

07/02 14:59, 1年前 , 37F
標題是災難,看一個程式有問題,就說整個世界有問題。
07/02 14:59, 37F

07/02 15:25, 1年前 , 38F
差多了吧...感覺上是你不知道為何要用FSM
07/02 15:25, 38F

07/02 15:43, 1年前 , 39F
邏輯規模大到覺得測試麻煩大概就可猜想你不應該改成flag
07/02 15:43, 39F

07/02 17:02, 1年前 , 40F
自己為是阿,你快搞懂後把狀態數合併吧
07/02 17:02, 40F

07/02 17:19, 1年前 , 41F
使用FSM 肯定不會太災難, 用flag 才災難
07/02 17:19, 41F

07/02 17:45, 1年前 , 42F
聽你在屁 10幾個flag在那邊if else你連文件都寫不出來
07/02 17:45, 42F

07/02 17:46, 1年前 , 43F
你是不是要說沒文件是災難
07/02 17:46, 43F

07/02 19:48, 1年前 , 44F
誰叫你要用狀態來實作fsm,用class或variant不好嗎
07/02 19:48, 44F

07/02 20:58, 1年前 , 45F
你才是災難,跟程式沒關係
07/02 20:58, 45F

07/02 22:39, 1年前 , 46F
用flag才是災難
07/02 22:39, 46F

07/02 23:54, 1年前 , 47F
三樓正解
07/02 23:54, 47F

07/03 00:38, 1年前 , 48F
這個還真不一定
07/03 00:38, 48F

07/03 00:54, 1年前 , 49F
有辦法提供sample code給大家討論嗎?不然也只是聽你抱怨而
07/03 00:54, 49F

07/03 00:54, 1年前 , 50F
07/03 00:54, 50F

07/03 01:00, 1年前 , 51F
怎麼感覺你比較雷
07/03 01:00, 51F

07/03 08:31, 1年前 , 52F
不然有更好的寫法嗎?
07/03 08:31, 52F

07/03 11:58, 1年前 , 53F
笑死 自己不會改狀態機說那是災難
07/03 11:58, 53F

07/03 17:56, 1年前 , 54F
狀態機如果文件還在 不容易大災難
07/03 17:56, 54F

07/03 17:58, 1年前 , 55F
至少很容易理解他裡面在幹嘛
07/03 17:58, 55F

07/04 00:52, 1年前 , 56F
flag災難中的災難
07/04 00:52, 56F

07/04 08:07, 1年前 , 57F
沒有FSM的話就是一堆if-elseif 有比較簡單?
07/04 08:07, 57F

07/04 11:08, 1年前 , 58F
FSM是有用的控制架構 會變成災難通常是用的人的問題
07/04 11:08, 58F

07/04 11:10, 1年前 , 59F
另 砍掉重練可以 但test case涵蓋率要趨近99.9%以上
07/04 11:10, 59F

07/04 11:11, 1年前 , 60F
尤其是邊界條件或很少出現的條件的test都要涵蓋
07/04 11:11, 60F

07/04 13:00, 1年前 , 61F
先生出100% coverage 的test env再改阿XD
07/04 13:00, 61F

07/04 14:38, 1年前 , 62F
flag是災難 所以把flag每個組合都弄成state就不是災難了
07/04 14:38, 62F

07/05 12:08, 1年前 , 63F
擴展便利,修改便利,過度最佳化不一定是好事
07/05 12:08, 63F
文章代碼(AID): #1YloF-br (Soft_Job)
文章代碼(AID): #1YloF-br (Soft_Job)