PTT職涯區 / Soft_Job (軟體人)

[請益] 一份好的設計規劃應該怎麼寫

看板Soft_Job (軟體人)作者時間1年前 (2023/03/10 09:18), 1年前編輯推噓14(14推 0噓 48→)
留言62則, 21人參與, 1年前最新討論串1/3 (看更多)
我目前從事販賣機的軟體開發，需求主幹很簡單： 1.用戶選定商品、檢查商品庫存。 2.提示付款、依據使用者付款方式檢查付款是否成功。 3.投放商品。 4.控管存放庫的溫度。 主幹的描述跟流程圖可以很快的寫出來，但問題在於細節的實施，比方說步驟2.，付款方式百百種，而且常常開發到一半就需要增減某種付款方式；又比方步驟4.，不同商品可能有不同的控管邏輯。 只要遇到需求變更，就得修改文件重畫流程圖，導致後來我也養成便宜行事的壞習慣，先把程式寫完，出版後再來按code寫規劃文件。 雖然目前也沒遇到什麼太大的問題，但違背了先畫流程圖跟寫規格書的原則，心裡總是留一根刺。 想向各位先進請教，像這種情形有沒有什麼好的建議或改善方向呢？ 謝謝。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.14.208 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1678411089.A.624.html
推
03/10 09:39, 1年前 , 1F
泳道圖
03/10 09:39, 1F
謝謝，我來查一下這是什麼。
→
03/10 10:40, 1年前 , 2F
問GPT
03/10 10:40, 2F
→
03/10 11:09, 1年前 , 3F
修改規格本來就很平常阿...便宜行事是你們的問題吧？
03/10 11:09, 3F
→
03/10 11:10, 1年前 , 4F
不過我也沒碰過的照"規定"走的，一堆出張嘴就改的XD
03/10 11:10, 4F
推
03/10 11:25, 1年前 , 5F
所以你寫的東西最好要有擴充彈性
03/10 11:25, 5F
→
03/10 12:07, 1年前 , 6F
找一個SA來做，PG兼SA 文件很容易會脫節
03/10 12:07, 6F
→
03/10 12:07, 1年前 , 7F
寫完code後你會沒動力修文件
03/10 12:07, 7F
→
03/10 12:10, 1年前 , 8F
或是你只寫文件，讓PG來看文件改這樣
03/10 12:10, 8F
我工作的場合編制沒有這麼齊全，所以工程師被要求從文件到產品都得做。
→
03/10 12:12, 1年前 , 9F
看能抵擋幾次需求變更而PG還不爆炸XD
03/10 12:12, 9F
→
03/10 12:14, 1年前 , 10F
正常不會先畫流程圖吧，會先寫人與系統互動流程的文字。正
03/10 12:14, 10F
所以流程圖並不是必要的嗎？以前學寫程式都一直被灌輸要先畫出流程圖，再按照流程圖寫程式。
→
03/10 12:14, 1年前 , 11F
式一點的說法是 use case。改文字比改圖方便多了
03/10 12:14, 11F
→
03/10 12:16, 1年前 , 12F
很多圖根本是形式，重點是流程紀錄清楚比較重要。等到專案
03/10 12:16, 12F
→
03/10 12:16, 1年前 , 13F
快結束，或沒事做時，才會根據合規要求，補各種說明文件與
03/10 12:16, 13F
→
03/10 12:16, 1年前 , 14F
圖。
03/10 12:16, 14F
※ 編輯: icetofux (223.137.14.208 臺灣), 03/10/2023 13:08:49 ※ 編輯: icetofux (223.137.14.208 臺灣), 03/10/2023 13:09:49 ※ 編輯: icetofux (223.137.14.208 臺灣), 03/10/2023 13:12:26
推
03/10 13:47, 1年前 , 15F
好讚喔 是做什麼國家的需求 很好奇
03/10 13:47, 15F
推
03/10 14:38, 1年前 , 16F
不考慮狀態圖嗎？
03/10 14:38, 16F
推
03/10 16:12, 1年前 , 17F
PM的需求情境跟業務範圍是否完整 設計的範圍才比較
03/10 16:12, 17F
→
03/10 16:12, 1年前 , 18F
聚焦
03/10 16:12, 18F
→
03/10 16:13, 1年前 , 19F
如果開發只依照你4點的需求主幹往下直接開發 那沒問
03/10 16:13, 19F
→
03/10 16:13, 1年前 , 20F
題才是問題吧XD
03/10 16:13, 20F
→
03/10 17:31, 1年前 , 21F
樓上有講跟沒講一樣XD
03/10 17:31, 21F
推
03/10 17:35, 1年前 , 22F
Gherkin
03/10 17:35, 22F
推
03/10 18:15, 1年前 , 23F
幾百年前的做法供你參考
03/10 18:15, 23F
→
03/10 18:15, 1年前 , 24F
把需求的use case寫出來
03/10 18:15, 24F
→
03/10 18:16, 1年前 , 25F
然後畫Active Diagram(就是上面說的泳道圖)
03/10 18:16, 25F
→
03/10 18:16, 1年前 , 26F
然後再把DFD或是class Diagram畫出
03/10 18:16, 26F
→
03/10 18:16, 1年前 , 27F
就可以開始coding了
03/10 18:16, 27F
→
03/10 18:16, 1年前 , 28F
當然有些比較雞巴的地方
03/10 18:16, 28F
→
03/10 18:16, 1年前 , 29F
會要求你維護sequence Diagram
03/10 18:16, 29F
→
03/10 18:16, 1年前 , 30F
現在這世代的做法應該也差不多吧
03/10 18:16, 30F
推
03/10 18:23, 1年前 , 31F
至於需求變更 看你的案子
03/10 18:23, 31F
→
03/10 18:23, 1年前 , 32F
採用那種軟工手法
03/10 18:23, 32F
→
03/10 18:23, 1年前 , 33F
若是瀑布式 就要和使用者重談需求 勾稽需求 然後改文件
03/10 18:23, 33F
→
03/10 18:23, 1年前 , 34F
如果是使用scrum就下一個spint再說了
03/10 18:23, 34F
推
03/10 18:30, 1年前 , 35F
流程圖可以切割，主幹引用到細節
03/10 18:30, 35F
→
03/10 18:31, 1年前 , 36F
例如主幹跑到付款那段的時候，標示說請見付款細節，付款
03/10 18:31, 36F
→
03/10 18:31, 1年前 , 37F
細節那邊有統一的interface的話，你對一種付款模式就是多
03/10 18:31, 37F
→
03/10 18:31, 1年前 , 38F
一個付款模式的細節圖
03/10 18:31, 38F
→
03/10 18:32, 1年前 , 39F
溫度控制那邊也可以看看能不能使用類似的做法，只要主幹
03/10 18:32, 39F
→
03/10 18:32, 1年前 , 40F
跟細節圖之間的關聯讓人可以很快找到的話，適度的切割沒
03/10 18:32, 40F
→
03/10 18:32, 1年前 , 41F
什麼不對
03/10 18:32, 41F
推
03/10 19:12, 1年前 , 42F
通常有需求之後我會畫流程圖或活動圖，當作確認需求
03/10 19:12, 42F
→
03/10 19:12, 1年前 , 43F
跟文件紀錄
03/10 19:12, 43F
推
03/10 19:13, 1年前 , 44F
Mermaid 畫流程圖很方便
03/10 19:13, 44F
→
03/10 23:23, 1年前 , 45F
你要先找到為什麼你說違背了你的原則，心裡會有刺的背
03/10 23:23, 45F
→
03/10 23:23, 1年前 , 46F
後真正的原因，再來看怎麼處理
03/10 23:23, 46F
→
03/10 23:26, 1年前 , 47F
你說的原則是為了什麼，還是只是無意義的個人原則，xy
03/10 23:26, 47F
→
03/10 23:26, 1年前 , 48F
問題
03/10 23:26, 48F
→
03/11 00:08, 1年前 , 49F
修改規格本來就很平常+1
03/11 00:08, 49F
推
03/11 14:48, 1年前 , 50F
設計一套DSL(Domain Specific Languages),可用LUA修改
03/11 14:48, 50F
→
03/11 14:48, 1年前 , 51F
我個人喜歡這種 https://github.com/zevv/zForth
03/11 14:48, 51F
→
03/11 14:48, 1年前 , 52F
文章代碼(AID): #1VclyWaS (CompilerDev) [ptt.cc]
03/11 14:48, 52F
→
03/11 14:49, 1年前 , 53F
不同商品對應到不同的 bytecode, 容易更新.
03/11 14:49, 53F
→
03/11 14:52, 1年前 , 54F
你舉的例子哪裡需要改流程圖..隨便找個範例改吧
03/11 14:52, 54F
推
03/12 09:52, 1年前 , 55F
你的主流程（購買行為）不應該包含副流程（付款方式）的
03/12 09:52, 55F
→
03/12 09:52, 1年前 , 56F
內容，副流程自己一張
03/12 09:52, 56F
→
03/12 09:52, 1年前 , 57F
這樣就不會一直修改
03/12 09:52, 57F
推
03/12 22:43, 1年前 , 58F
你要想why。為什麼該先畫流程圖？為什麼你們想便宜行事
03/12 22:43, 58F
→
03/12 22:43, 1年前 , 59F
？在我看來，開發中的設計草稿和發行時的定稿是兩件事
03/12 22:43, 59F
→
03/12 22:43, 1年前 , 60F
，前者重修改效率，後者重後人的易理解性。前者挑順手
03/12 22:43, 60F
→
03/12 22:43, 1年前 , 61F
的工具畫個內部人能釐清的圖，發行時再花心思讓圖變成
03/12 22:43, 61F
→
03/12 22:43, 1年前 , 62F
標準圖。
03/12 22:43, 62F
‣ 更多 icetofux 的文章
文章代碼(AID): #1a2eLHOa (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 icetofux 的文章
文章代碼(AID): #1a2eLHOa (Soft_Job)