看板Soft_Job
作者IhateOGC (我討厭)
標題[討論] FSM狀態機程式架構是不是災難?
時間2022-07-02 00:42:00
吐泡一下 最近在維護一個交易老程式碼 就像是依照流程圖畫出來的狀態機實作 主狀態機有N個case 每個case又各自註冊可以重複的條件 FSM主要的狀態是有順序的 但是下面登記的function重覆性有87% 一個flag就可以解決的事情搞到變成很巨大的狀態機 有股想砍掉重練的衝動...但是只能自己驗證 QQ -- ※ 發信站: 批踢踢實業坊(ptt-club.com.tw), 來自: 116.241.146.114 (臺灣) ※ 文章網址: https://ptt-club.com.tw/Soft_Job/M.1656693758.A.975
→ ybite: 我認為看設計 良好設計下可以迴避可能問題 07/02 01:05
推 w180112: 設計問題…不要怪東怪西 07/02 01:44
→ labbat: 主管請你來是維護的，亂動手腳而不提出規格變更申請是找死 07/02 01:45
→ Apache: 不是 幾乎所有DP教材都會講到SM 07/02 01:47
→ pot1234: 87%像的程式碼沒有共用code，這不是fsm的問題吧 07/02 06:16
推 peoples: 包養真亂 07/02 06:16
推 k798976869: IC數位設計都是狀態機啊 07/02 07:06
推 MacPerson: 如果改狀態，大家都自己去異動flag就好，那才是真正的 07/02 07:07
→ MacPerson: 災難 07/02 07:07
推 TWkobe: 要看驗證還有主管同意 07/02 07:22
推 wulouise: fsm最好要有辦法auto gen流程圖，不然維護起來很痛苦， 07/02 07:23
推 wilmer: 演藝圈一堆包養好嗎 07/02 07:23
→ wulouise: 而且要是每個流程都在那邊改一堆singleton..算了 07/02 07:23
→ milk830122: 各有好處吧 設計模式看情況用 flag遇到大架構要改直接 07/02 07:48
→ milk830122: 累死 07/02 07:48
→ tofuflower: 用 flag 也會有 flag 的雷 07/02 08:45
→ tofuflower: 如果每個 func 的業務邏輯是獨立的， code 有 87 % 07/02 08:51
推 badlip: 政治圈一堆包養好嗎 07/02 08:51
→ tofuflower: 像也不是問題 07/02 08:51
→ tofuflower: 把看起來一樣的程式碼共用等於把所有業務邏輯耦合在一 07/02 08:53
→ tofuflower: 起，這更雷 07/02 08:53
噓 kkes0001: 怎麼看都覺得問題是實現架構的人 07/02 09:41
噓 smallcar801: 沒壞的東西不要修 07/02 09:58
推 piggyoil: 有錢人一堆包養好嗎 07/02 09:58
→ alongalone: 存在必有道理. 人的問題不要怪東西 07/02 10:26
推 wulouise: 重複不表示他們可以同時被改 07/02 11:19
推 NDark: 大部分是. 原因很複雜不能歸咎於一處. 07/02 11:25
→ NDark: 最大的問題常發生在幾處: 07/02 11:26
→ NDark: - (後續)需求就超出設計之初的範圍 07/02 11:26
推 TwixBar: 學生妹被包養多嗎 07/02 11:26
→ NDark: - 維護的人沒有照著狀態機的方式來撰寫邏輯 07/02 11:27
→ NDark: 邏輯分離得好就算switch也能運作得很好. 07/02 11:28
→ NDark: 狀態機有點像是緊錮圈.是頭要去適合圈. 07/02 11:29
→ NDark: 不是每個開發者/團隊都有受過足夠的訓練能用得好. 07/02 11:29
推 airtsubasa: 沒壞的東西不要修，但頻繁修改(例如一樣的邏輯要改n個 07/02 11:36
推 boggicer: 亞洲最大包養網上線啦 07/02 11:36
→ airtsubasa: 地方，然後變數還不一樣) 那到底要不要修呢 07/02 11:36
推 Odia: 在沒有提出更好的設計前別說是災難 07/02 13:11
→ s678131: FSM明明是個好東西 07/02 13:46
→ dnabossking: 我接收過這種賺錢中程式碼，我直接翻寫掉了，我滿肯 07/02 14:19
→ dnabossking: 定 07/02 14:19
推 Chiason: 我哥上包養網被我抓包.. 07/02 14:19
→ dnabossking: 不是狀態機的問題 07/02 14:19
→ DrTech: 標題是災難，看一個程式有問題，就說整個世界有問題。 07/02 14:59
→ alan3100: 差多了吧...感覺上是你不知道為何要用FSM 07/02 15:25
→ alan3100: 邏輯規模大到覺得測試麻煩大概就可猜想你不應該改成flag 07/02 15:43
噓 wave1et: 自己為是阿，你快搞懂後把狀態數合併吧 07/02 17:02
推 Markell: 有人包養過洋鬼子嗎 07/02 17:02
推 easyman: 使用FSM 肯定不會太災難, 用flag 才災難 07/02 17:19
推 chuegou: 聽你在屁 10幾個flag在那邊if else你連文件都寫不出來 07/02 17:45
→ chuegou: 你是不是要說沒文件是災難 07/02 17:46
→ lturtsamuel: 誰叫你要用狀態來實作fsm，用class或variant不好嗎 07/02 19:48
噓 pttano: 你才是災難，跟程式沒關係 07/02 20:58
推 fuoya: 有錢人為啥都想包養 07/02 20:58
噓 ichunlai: 用flag才是災難 07/02 22:39
推 viper9709: 三樓正解 07/02 23:54
→ peter98: 這個還真不一定 07/03 00:38
推 APTON: 有辦法提供sample code給大家討論嗎？不然也只是聽你抱怨而 07/03 00:54
→ APTON: 已 07/03 00:54
推 Apasiri: 有人被洋鬼子包養過嗎 07/03 00:54
→ molimoli: 怎麼感覺你比較雷 07/03 01:00
→ Lipraxde: 不然有更好的寫法嗎？ 07/03 08:31
噓 KanzakiHAria: 笑死 自己不會改狀態機說那是災難 07/03 11:58
推 za755188: 狀態機如果文件還在 不容易大災難 07/03 17:56
→ za755188: 至少很容易理解他裡面在幹嘛 07/03 17:58
推 litidi: 到底要多有錢才會想包養 07/03 17:58
→ revorea: flag災難中的災難 07/04 00:52
推 CaptainH: 沒有FSM的話就是一堆if-elseif 有比較簡單？ 07/04 08:07
→ bear1414: FSM是有用的控制架構 會變成災難通常是用的人的問題 07/04 11:08
→ bear1414: 另 砍掉重練可以 但test case涵蓋率要趨近99.9%以上 07/04 11:10
→ bear1414: 尤其是邊界條件或很少出現的條件的test都要涵蓋 07/04 11:11
推 Merzario: 閨蜜上包養網還推薦我... 07/04 11:11
→ notBeing: 先生出100% coverage 的test env再改阿XD 07/04 13:00
→ freef1y3: flag是災難 所以把flag每個組合都弄成state就不是災難了 07/04 14:38
→ hongsiangfu: 擴展便利，修改便利，過度最佳化不一定是好事 07/05 12:08
推 snaketsai: 若真如你說，那應該有大量的狀態轉換可以縮減吧，離散 07/07 13:57
→ snaketsai: 數學基本概念 07/07 13:57
推 Muzaffer: 包養? 07/07 13:57