吐泡一下
最近在維護一個交易老程式碼
就像是依照流程圖畫出來的狀態機實作
主狀態機有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就不是災難了

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

若真如你說，那應該有大量的狀態轉換可以縮減吧，離散數學基本概念