看板Soft_Job
作者icetofux ()
標題[請益] 一份好的設計規劃應該怎麼寫
時間2023-03-10 09:18:04
我目前從事販賣機的軟體開發，需求主幹很簡單： 1.用戶選定商品、檢查商品庫存。 2.提示付款、依據使用者付款方式檢查付款是否成功。 3.投放商品。 4.控管存放庫的溫度。 主幹的描述跟流程圖可以很快的寫出來，但問題在於細節的實施，比方說步驟2.，付款方式百百種，而且常常開發到一半就需要增減某種付款方式；又比方步驟4.，不同商品可能有不同的控管邏輯。 只要遇到需求變更，就得修改文件重畫流程圖，導致後來我也養成便宜行事的壞習慣，先把程式寫完，出版後再來按code寫規劃文件。 雖然目前也沒遇到什麼太大的問題，但違背了先畫流程圖跟寫規格書的原則，心裡總是留一根刺。 想向各位先進請教，像這種情形有沒有什麼好的建議或改善方向呢？ 謝謝。 -- ※ 發信站: 批踢踢實業坊(pttsite.org.tw), 來自: 223.137.14.208 (臺灣) ※ 文章網址: https://pttsite.org.tw/Soft_Job/M.1678411089.A.624
推 SHANGOYANYI: 泳道圖 03/10 09:39
→ leolarrel: 問GPT 03/10 10:40
→ abccbaandy: 修改規格本來就很平常阿...便宜行事是你們的問題吧？ 03/10 11:09
→ abccbaandy: 不過我也沒碰過的照"規定"走的，一堆出張嘴就改的XD 03/10 11:10
推 f26724309: 所以你寫的東西最好要有擴充彈性 03/10 11:25
推 Apasiri: 有人可以分析一下包養平台的差異嗎 03/10 11:25
→ lazarus1121: 找一個SA來做，PG兼SA 文件很容易會脫節 03/10 12:07
→ lazarus1121: 寫完code後你會沒動力修文件 03/10 12:07
→ lazarus1121: 或是你只寫文件，讓PG來看文件改這樣 03/10 12:10
→ lazarus1121: 看能抵擋幾次需求變更而PG還不爆炸XD 03/10 12:12
→ DrTech: 正常不會先畫流程圖吧，會先寫人與系統互動流程的文字。正 03/10 12:14
推 litidi: 那個包養網人最多XD 03/10 12:14
→ DrTech: 式一點的說法是 use case。改文字比改圖方便多了 03/10 12:14
→ DrTech: 很多圖根本是形式，重點是流程紀錄清楚比較重要。等到專案 03/10 12:16
→ DrTech: 快結束，或沒事做時，才會根據合規要求，補各種說明文件與 03/10 12:16
→ DrTech: 圖。 03/10 12:16
推 MoonCode: 好讚喔 是做什麼國家的需求 很好奇 03/10 13:47
推 Merzario: 我妹上包養網被我發現= = 03/10 13:47
推 APTON: 不考慮狀態圖嗎？ 03/10 14:38
推 remember69: PM的需求情境跟業務範圍是否完整 設計的範圍才比較 03/10 16:12
→ remember69: 聚焦 03/10 16:12
→ remember69: 如果開發只依照你4點的需求主幹往下直接開發 那沒問 03/10 16:13
→ remember69: 題才是問題吧XD 03/10 16:13
推 Muzaffer: 隔壁桌的人竟然在討論包養... 03/10 16:13
→ jackflu: 樓上有講跟沒講一樣XD 03/10 17:31
推 sp063439: Gherkin 03/10 17:35
推 jej: 幾百年前的做法供你參考 03/10 18:15
→ jej: 把需求的use case寫出來 03/10 18:15
→ jej: 然後畫Active Diagram(就是上面說的泳道圖) 03/10 18:16
推 MIJice: 樓上是不是被包養 03/10 18:16
→ jej: 然後再把DFD或是class Diagram畫出 03/10 18:16
→ jej: 就可以開始coding了 03/10 18:16
→ jej: 當然有些比較雞巴的地方 03/10 18:16
→ jej: 會要求你維護sequence Diagram 03/10 18:16
→ jej: 現在這世代的做法應該也差不多吧 03/10 18:16
推 SpyTime: 未看先猜這包養網 03/10 18:16
推 jej: 至於需求變更 看你的案子 03/10 18:23
→ jej: 採用那種軟工手法 03/10 18:23
→ jej: 若是瀑布式 就要和使用者重談需求 勾稽需求 然後改文件 03/10 18:23
→ jej: 如果是使用scrum就下一個spint再說了 03/10 18:23
推 hegemon: 流程圖可以切割，主幹引用到細節 03/10 18:30
推 Toth: 一定又是這包養網 03/10 18:30
→ hegemon: 例如主幹跑到付款那段的時候，標示說請見付款細節，付款 03/10 18:31
→ hegemon: 細節那邊有統一的interface的話，你對一種付款模式就是多 03/10 18:31
→ hegemon: 一個付款模式的細節圖 03/10 18:31
→ hegemon: 溫度控制那邊也可以看看能不能使用類似的做法，只要主幹 03/10 18:32
→ hegemon: 跟細節圖之間的關聯讓人可以很快找到的話，適度的切割沒 03/10 18:32
推 Asterix: 包養平台不意外 03/10 18:32
→ hegemon: 什麼不對 03/10 18:32
推 WaterLengend: 通常有需求之後我會畫流程圖或活動圖，當作確認需求 03/10 19:12
→ WaterLengend: 跟文件紀錄 03/10 19:12
推 s29940: Mermaid 畫流程圖很方便 03/10 19:13
→ GoalBased: 你要先找到為什麼你說違背了你的原則，心裡會有刺的背 03/10 23:23
推 AdamShi: 覺得包養網EY嗎 03/10 23:23
→ GoalBased: 後真正的原因，再來看怎麼處理 03/10 23:23
→ GoalBased: 你說的原則是為了什麼，還是只是無意義的個人原則，xy 03/10 23:26
→ GoalBased: 問題 03/10 23:26
→ viper9709: 修改規格本來就很平常+1 03/11 00:08
推 enthos: 設計一套DSL(Domain Specific Languages),可用LUA修改 03/11 14:48
推 lezabo: 包養網站葉配啦 03/11 14:48
→ enthos: 我個人喜歡這種 https://github.com/zevv/zForth 03/11 14:48
→ enthos: 文章代碼(AID): #1VclyWaS (CompilerDev) [ptt.cc] 03/11 14:48
→ enthos: 不同商品對應到不同的 bytecode, 容易更新. 03/11 14:49
→ alan3100: 你舉的例子哪裡需要改流程圖..隨便找個範例改吧 03/11 14:52
推 burgess: 你的主流程（購買行為）不應該包含副流程（付款方式）的 03/12 09:52
推 silberger: 記者收了包養網多少啦 03/12 09:52
→ burgess: 內容，副流程自己一張 03/12 09:52
→ burgess: 這樣就不會一直修改 03/12 09:52
推 overhead: 你要想why。為什麼該先畫流程圖？為什麼你們想便宜行事 03/12 22:43
→ overhead: ？在我看來，開發中的設計草稿和發行時的定稿是兩件事 03/12 22:43
→ overhead: ，前者重修改效率，後者重後人的易理解性。前者挑順手 03/12 22:43
推 xayile: 包養真亂 03/12 22:43
→ overhead: 的工具畫個內部人能釐清的圖，發行時再花心思讓圖變成 03/12 22:43
→ overhead: 標準圖。 03/12 22:43