这是一个创建于 1644 天前的主题，其中的信息可能已经有所发展或是发生改变。
我不是软件从业人员，这个问题可能问的比较业余。使用者应该是产品经理，如何准确的把客户的业务逻辑描述清楚，转达给开发人员。
当业务逻辑越来越复杂的时候，特别是牵扯到很多交互、与底层设备的通讯、状态等待的时候，如果全写出来基本也是很难的，很多时候就是先写各大概，然后边做边搞清楚。等到最后，全部把这些逻辑写出来基本也是跟天书一样，没人再去看了。
想跟大家交流一下，这方面比较好的实践是什么。
 |
1
cigarzh 2020-06-27 22:03:17 +08:00
U M L
|
 |
2
yannxia 2020-06-27 22:06:34 +08:00
分层 + 模块化
----- 分层：把相对独立的一层当成一个黑盒处理，比如写 Java 的时候，你可以认为操作系统那是一个黑盒。先把最大的分层搞出来，每个分层里面还有自己分层，俄罗斯套娃。 模块化：每次就讲一个小模块，分层之后里面总是有几个模块，分开讲，模块很复杂的话，里面再分层+模块。 |
 |
3
sayhier OP 有时候还要处理不同任务之间的连锁交互。我在想关于这个是不是应该有一套理论指导，查了一下状态机之类的处理现实问题还是显得无力了点
|
 |
4
xuanbg 2020-06-27 22:24:24 +08:00
多画几个思维导图，把层次结构和关系先理理清楚，然后把不必要的都干掉，剩下的就是简单的了。
|
 |
5
imn1 2020-06-27 22:56:52 +08:00
不是技术人员应该很难写 UML，简单讲还是抓住 5W1H
大部分程序是按顺序执行，所以业务有顺序的话，按时间分开步骤 有些业务无关时间，只是不同状态之间切换（例如颜色不同引发不同业务），这种情况就按状态分 如果你有能力把大任务拆分为小任务，那其他都是小事 |
 |
6
ljpCN 2020-06-27 23:47:47 +08:00 via Android
@sayhier 不知道你说的状态机是不是指形式语言与自动机理论中的状态机。如果是的话，我想状态机应该是表达能力最强的了，为什么会无力？是指繁琐吗？
|
 |
7
rocyhua 2020-06-27 23:52:34 +08:00
泳道流程图或者时序图比较合适
|
 |
8
harde 2020-06-27 23:56:34 +08:00
脑图 -> 流程图 + 时序图
|
 |
9
across 2020-06-27 23:58:00 +08:00
Axure ？
|
 |
10
kiroter 2020-06-28 10:13:08 +08:00
ddd
|
|
11
sayhier OP 看来没啥好办法，就是大拆小，指望一个文档写清楚不可能的还是要靠多交流
|
|
12
sayhier OP @ljpCN 当状态多了，或者动态过程，就很难了。感觉状态机这东西也就平时针对具体问题整理一下思路的时候有用
|
 |
13
sleepm 2020-06-28 17:54:43 +08:00
excel
|
Select Language