作者icetofux ()
看板Soft_Job
标题[请益] 一份好的设计规划应该怎麽写
时间Fri Mar 10 09:18:04 2023
我目前从事贩卖机的软体开发，需求主干很简单：
1.用户选定商品、检查商品库存。
2.提示付款、依据使用者付款方式检查付款是否成功。
3.投放商品。
4.控管存放库的温度。
主干的描述跟流程图可以很快的写出来，但问题在於细节的实施，比方说步骤2.，付款方式百百种，而且常常开发到一半就需要增减某种付款方式；又比方步骤4.，不同商品可能有不同的控管逻辑。
只要遇到需求变更，就得修改文件重画流程图，导致後来我也养成便宜行事的坏习惯，先把程式写完，出版後再来按code写规划文件。
虽然目前也没遇到什麽太大的问题，但违背了先画流程图跟写规格书的原则，心里总是留一根刺。
想向各位先进请教，像这种情形有没有什麽好的建议或改善方向呢？
谢谢。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.137.14.208 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1678411089.A.624.html
1F：推 SHANGOYANYI: 泳道图 03/10 09:39
谢谢，我来查一下这是什麽。
2F：→ leolarrel: 问GPT 03/10 10:40
3F：→ abccbaandy: 修改规格本来就很平常阿...便宜行事是你们的问题吧？ 03/10 11:09
4F：→ abccbaandy: 不过我也没碰过的照"规定"走的，一堆出张嘴就改的XD 03/10 11:10
5F：推 f26724309: 所以你写的东西最好要有扩充弹性 03/10 11:25
6F：→ lazarus1121: 找一个SA来做，PG兼SA 文件很容易会脱节 03/10 12:07
7F：→ lazarus1121: 写完code後你会没动力修文件 03/10 12:07
8F：→ lazarus1121: 或是你只写文件，让PG来看文件改这样 03/10 12:10
我工作的场合编制没有这麽齐全，所以工程师被要求从文件到产品都得做。
9F：→ lazarus1121: 看能抵挡几次需求变更而PG还不爆炸XD 03/10 12:12
10F：→ DrTech: 正常不会先画流程图吧，会先写人与系统互动流程的文字。正 03/10 12:14
所以流程图并不是必要的吗？以前学写程式都一直被灌输要先画出流程图，再按照流程图写程式。
11F：→ DrTech: 式一点的说法是 use case。改文字比改图方便多了 03/10 12:14
12F：→ DrTech: 很多图根本是形式，重点是流程纪录清楚比较重要。等到专案 03/10 12:16
13F：→ DrTech: 快结束，或没事做时，才会根据合规要求，补各种说明文件与 03/10 12:16
14F：→ DrTech: 图。 03/10 12:16
※ 编辑: 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
15F：推 MoonCode: 好赞喔 是做什麽国家的需求 很好奇 03/10 13:47
16F：推 APTON: 不考虑状态图吗？ 03/10 14:38
17F：推 remember69: PM的需求情境跟业务范围是否完整 设计的范围才比较 03/10 16:12
18F：→ remember69: 聚焦 03/10 16:12
19F：→ remember69: 如果开发只依照你4点的需求主干往下直接开发 那没问 03/10 16:13
20F：→ remember69: 题才是问题吧XD 03/10 16:13
21F：→ jackflu: 楼上有讲跟没讲一样XD 03/10 17:31
22F：推 sp063439: Gherkin 03/10 17:35
23F：推 jej: 几百年前的做法供你参考 03/10 18:15
24F：→ jej: 把需求的use case写出来 03/10 18:15
25F：→ jej: 然後画Active Diagram(就是上面说的泳道图) 03/10 18:16
26F：→ jej: 然後再把DFD或是class Diagram画出 03/10 18:16
27F：→ jej: 就可以开始coding了 03/10 18:16
28F：→ jej: 当然有些比较鸡巴的地方 03/10 18:16
29F：→ jej: 会要求你维护sequence Diagram 03/10 18:16
30F：→ jej: 现在这世代的做法应该也差不多吧 03/10 18:16
31F：推 jej: 至於需求变更 看你的案子 03/10 18:23
32F：→ jej: 采用那种软工手法 03/10 18:23
33F：→ jej: 若是瀑布式 就要和使用者重谈需求 勾稽需求 然後改文件 03/10 18:23
34F：→ jej: 如果是使用scrum就下一个spint再说了 03/10 18:23
35F：推 hegemon: 流程图可以切割，主干引用到细节 03/10 18:30
36F：→ hegemon: 例如主干跑到付款那段的时候，标示说请见付款细节，付款 03/10 18:31
37F：→ hegemon: 细节那边有统一的interface的话，你对一种付款模式就是多 03/10 18:31
38F：→ hegemon: 一个付款模式的细节图 03/10 18:31
39F：→ hegemon: 温度控制那边也可以看看能不能使用类似的做法，只要主干 03/10 18:32
40F：→ hegemon: 跟细节图之间的关联让人可以很快找到的话，适度的切割没 03/10 18:32
41F：→ hegemon: 什麽不对 03/10 18:32
42F：推 WaterLengend: 通常有需求之後我会画流程图或活动图，当作确认需求 03/10 19:12
43F：→ WaterLengend: 跟文件纪录 03/10 19:12
44F：推 s29940: Mermaid 画流程图很方便 03/10 19:13
45F：→ GoalBased: 你要先找到为什麽你说违背了你的原则，心里会有刺的背 03/10 23:23
46F：→ GoalBased: 後真正的原因，再来看怎麽处理 03/10 23:23
47F：→ GoalBased: 你说的原则是为了什麽，还是只是无意义的个人原则，xy 03/10 23:26
48F：→ GoalBased: 问题 03/10 23:26
49F：→ viper9709: 修改规格本来就很平常+1 03/11 00:08
50F：推 enthos: 设计一套DSL(Domain Specific Languages),可用LUA修改 03/11 14:48
53F：→ enthos: 不同商品对应到不同的 bytecode, 容易更新. 03/11 14:49
54F：→ alan3100: 你举的例子哪里需要改流程图..随便找个范例改吧 03/11 14:52
55F：推 burgess: 你的主流程（购买行为）不应该包含副流程（付款方式）的 03/12 09:52
56F：→ burgess: 内容，副流程自己一张 03/12 09:52
57F：→ burgess: 这样就不会一直修改 03/12 09:52
58F：推 overhead: 你要想why。为什麽该先画流程图？为什麽你们想便宜行事 03/12 22:43
59F：→ overhead: ？在我看来，开发中的设计草稿和发行时的定稿是两件事 03/12 22:43
60F：→ overhead: ，前者重修改效率，後者重後人的易理解性。前者挑顺手 03/12 22:43
61F：→ overhead: 的工具画个内部人能厘清的图，发行时再花心思让图变成 03/12 22:43
62F：→ overhead: 标准图。 03/12 22:43