程序-产品的分歧

为啥程序人员总和产品人员吵架，或许是天生的吧。

或许程序人员是理性的，产品人员是感性的。

但是作为把生活提取出来成为产品的第一步，产品人员也应该具有理性思维。

此文我主要想说离散数学在整个产品开发中的重要性，主要是离散数学的归纳和总结。

离散数学是什么，我们先举些例子吧。

场景.

要做一个聊天室，聊天室主要内容有，谁说话，谁送礼，谁对谁说话送礼，某人进来了、出去了，发送了一个超大叫喊（就是展示的很大的字）；权限，谁把谁禁言了，踢出去了，还有等级，谁说话多了，等级会提升，什么开玩笑等级，魅力等级等。

最后可能获取到的最简单的原子操作是这样的（用最小的表示方法代表所有内容）：

1. A 说话：blabla

2. A对B说话：blabla

3. A 对B 超大叫喊：blabla

4. A大声叫喊：blabla

5. A送B礼物：X

6. A把B 禁言了

7. A把B 踢出去了

8. A的玩笑等级提升到 ：4

9. A的魅力等级提升到 ： 4

看到这里大家觉得怎么样，如果在添加新的功能，比如A对B 换个动作（啥都可以），又得出来一大堆不同的，而且整个看起来很乱，包括添加新协议的时候扫描（bianli）以前有没有都很复杂，可能1-9的数字是打乱的，更复杂。这个对于开发、后期维护，包括测试进行测试都极其复杂。

总结以上的逻辑，其实完全可以把以上的逻辑进行划分，如 说话，送礼，权限操作，升级 4个点

于是就有了这样的表格：

干啥	类型	属性
1（说话）	1说话	内容
	2大声叫喊	内容
2（送礼）	1 送礼	礼物名
3（权限）	1 禁言	操作还是反操作
	2 踢出	操作还是反操作
4（升级）	1玩笑	等级
	2 魅力	等级

所有协议里面包括操作和被操作者，如果被操作人没有，即空。

对产品来说：

比如要添加其他的等级升级，产品人员仅需要在4号里面查看喝添加就行，而且其他特性都保留，比人的各种属性，比如登记啊，穿的衣服啊。这方面一般不会动，而且产品也不用特意说这个任务要哪些属性。。。。。（何须一张张的美术UI画面，一个数字总结表即可）。
同时产品在项目数值上面也更加清晰内容，更易于别人接手。

对程序来说：

表整洁，一系列的switch case出来，代码清晰。修改说话公共 部分，全部都改了。bug避免非常多。就说这么多，开发猿自己体会。

对测试来说：

整体性测试和分类也做完了，相关测试要点在心里一目了然。
其他......

其实这个工作也不一定全由产品做，开发也可以做或fix，最后反馈给产品到整个项目。

总结：

这里其实就是用到了离散数学中的归纳的思维，将面或线性的生活数据，转换成点（软件可处理的数据）。这个过程其实越早做愈好。当然这个例子仅是展现的归纳的一部分（归纳的数据模型），其他还有逻辑范式，统计模型等等。

如果对此文有疑义，请直接在评论中留言和讨论。