算法和业务逻辑

‘壹’ 什么是业务逻辑

不同的项目有不同的功能，不同的功能需要不同的实现，实现这些核心功能的代码就叫业务逻辑。比如让你实现一个功能，给你两个数，让你获取它的和。你所写的“如何才能获得任意给定的两个数的和”这个程序的实现过程即可称为业务逻辑处理。

‘贰’ java 中表现逻辑 业务逻辑和持久化逻辑各自负责什么的

从MVC的思想去考虑
（控制器Controller）- 负责转发请求，对请求进行处理。
（视图View） - 界面设计人员进行图形界面设计。
（模型Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
3对3 ，自己对应着，很快就能找到答案的

‘叁’ 从哪些点上可以体现一个程序员的实力

对于一个程序员来说，刚上任的新手，如果能够将工作任务高效地处理，证明其工作能力还是具备一定的基础的，企业大可继续留任试用。如果这个程序员不仅能够在短时间内高效处理工作内容，且对于工作的细节也十分地考究，充分全面地考虑，必然也代表其工作思维和普通员工不同。一个程序员如果对于工作只是在应付差事，那么必然其能力也不会好到哪里去，因此，一定要观察期对待工作态度是否认真，然后进行其能力的初步判断。

‘肆’ 问下大家三层架构中,业务逻辑层到底是做啥用的不理解为什么非要有这样一层啊

业务逻辑层处于三层结构的中间层，它是实现你程序功能的核心部分。举例来说，如果你要设计一个三层架构的计算器程序，计算的来源数据来自服务器端，计算结果在客户端显示，那么中间层（即所谓的业务逻辑层）就是实现你计算功能的核心部分，是需要你完成的一个最主要部分。所以该层是必不可少的，而且也是你需要完成的主要工作。

‘伍’ 产品经理之流程图表达业务逻辑

在看文章时，我们时不时会碰到各种流程图：业务流程图、功能流程图、页面流程图、用户操作流程图、系统流程图等等这些叫得出名叫不出名的流程图，这着实让人头痛不已，这里作者分享一些自己对于流程图的理解，着重介绍产品中会用到的相关流程图，希望能够抛砖引玉。

定义

网络：以特定的图形符号加上说明，表示算法的图，称为流程图或框图；

智库网络：流程图是流经一个系统的信息流、观点流或部件流的图形代表；

维基网络：A flowchart is a type of diagram that represents an algorithm, workflow or process, showing the steps as boxes of various kinds, and their order by connecting them with arrows. This diagrammatic representation illustrates a solution model to a given problem.

（译文：流程图是一类代表算法、工作流或过程的图表，它通过一些用箭头连接的各类图形来展示其中的步骤。这类图形表示方法常用来阐述一个给定问题的解决模型。）

通俗来说，流程图就是一个有特定逻辑顺序的步骤地图，在这份地图的帮助下，我们可以预知某类步骤走法所能到达的终点，同时，我们也可以通过这份地图找到某个目的地的具体实现路径。

种类

维基网络原文引述Types部分：

Sterneckert (2003) suggested that flowcharts can be modeled from the perspective of different user groups (such as managers, system analysts and clerks) and that there are four general types:

Document flowcharts, showing controls over a document-flow through a system

Data flowcharts, showing controls over a data-flow in a system

System flowcharts, showing controls at a physical or resource level

Program flowchart, showing the controls in a program within a system

Notice that every type of flowchart focuses on some kind of control, rather than on the particular flow itself。

However, there are several of these classifications. For example, Andrew Veronis (1978) named three basic types of flowcharts: the system flowchart , the general flowchart , and the detailed flowchart . [11] That same year Marilyn Bohl (1978) stated “in practice, two kinds of flowcharts are used in solution planning: system flowcharts and program flowcharts …”. [12] More recently Mark A Fryman (2001) stated that there are more differences: “Decision flowcharts, logic flowcharts, systems flowcharts, proct flowcharts, and process flowcharts are just a few of the different types of flowcharts that are used in business and government”.

大意：

Sterneckert在2003年提出流程图可以根据不同的用户群（例如管理人员、系统分析师、书记员）这个角度来绘制，并且划分出了四种常用的种类：

文档流程图：展示经过一个系统中的文档流的控制；

数据流程图：展示对一个系统中数据流的控制；

系统流程图：展示对于物理层面或资源层面上的控制；

程序流程图：展示一个系统中对于程序的控制；

值得注意的是：相较于特定的流程图本身，每一类流程图都更关注于某一种类型的控制。

然而，这些分类还有好几种。比如说，Andrew Veronis (1978)命名了3类基本种类的流程图：系统流程图、通用流程图、详细流程图。同一年，Marilyn Bohl提出：“事实上，在解决方案规划领域有2类流程图：系统流程图和程序流程图”；离现在更近的是2001的Mark A Fryman，他提出：“在商业和管理领域，流程图有更多的种类如决策流程图、逻辑流程图、系统流程图、产品流程图、过程流程图”

在上文中我想强调与重申的是“Notice that every type of flowchart focuses on some kind of control, rather than on the particular flow itself。”

相较于特定的流程图本身，每一类流程图都更关注于某一种类型的控制。

看到这里，坚强如你是不是也得吐槽一句：“真是B了狗，怎么就没有一个固定的标准，我怎么数得清有多少种，说不定明天又出来一种新类型的流程图”。其实，在这里我引用这么一大段东西，不止是为了让大家吐槽。更是想要传递一个观点：“现实世界中不像程序中那么非0即1，某件事物的定义或定性没有一个统一的标准是不难见到的。”但中式教育似乎又更加严格强调标准答案这个概念，就如我们小时候，教材被视为绝对的真理，语文课上考察背诵时，就需一字不多不少得背下来，句子中加个语气助词“了”可能都算错。种种这种类似的经验就很容易造就了一堆死记硬背的读书人，当他们遇到一个新概念时就会查看其定义，如果定义有严格的标准，那就不管是否已经理解先背下来（当然，这种背诵行为不是说不好），但如果缺乏一份严格的标准，他们就会惊慌失措，不知道何去何从。互联网产品行业又是一个新兴领域，其中许多标准与规范也没有达成共识，这就需要我们勇于探索和总结了，希望这段话能够给鼓励一些迷茫于没有标准教材学习的朋友。

话题扯回来，对于PM，我们经常接触到的流程图又有哪些种类呢？按照产品设计过程中的时间先后顺序，我想分享一下自己对于 产品业务流程图、产品功能流程图、产品页面流程图 的思考和总结（这里请注意我们将讨论前提限制在了产品领域）。

标准

虽然流程图的类别没有严格的分类标准，但对于其图形表达已经有一套基本的共识。在介绍具体的流程图前，我们先对常用的图形标准达成共识：

产品业务流程图（绘制人：产品经理）

1. 定义

产品业务流程图就是通过图形化的表达形式，阐述产品在业务层面控制的图表。 产品业务流程图通常作为产品设计初期阶段的工具使用，通过图形化，能够更清晰、直观地传达产品在业务层面的控制（如业务动作、方向、逻辑等信息）。

2. 作用

业务流程图通常用于介绍产品业务，如产品经理需要向老板介绍产品业务时，用流程图辅助讲解的效果，相较于纯语言或文字表达要好得多。

绘制业务流程图的过程能够帮助PM根据产品定位对产品业务进行设计、分析与优化。

3. 实例

注：这里我们以ofo小黄车为例，粗略地绘制其业务流程图、功能流程图、页面流程图，希望能够帮助理解

产品功能流程图（绘制人 : 产品经理）

1. 定义

产品功能流程图就是通过图形化的表达形式，阐述产品在功能层面控制的图表。 产品功能流程图通常作为产品设计中期阶段的工具使用，通过图形化，能够更清晰、直观地传达产品在功能层面的控制（如功能动作、方向、逻辑等信息）。

2. 作用

功能流程图通常用于介绍产品功能模块的相互关系或某个功能模块的具体组成，如产品经理需要向开发人员介绍某个新增功能模块时，可以在原型图宣讲之前使用功能流程图让其对功能的轮廓和走向了然于胸。

绘制功能流程图的过程能够帮助PM确定产品的功能范围同时避免不合理的功能使用逻辑。

3. 实例

产品页面流程图（绘制人:交互设计师、产品经理）

1.定义

产品页面流程图就是通过图形化的表达形式，阐述产品在页面层面控制的图表。 产品页面流程图通常作为产品设计后期阶段的工具使用，通过图形化，能够更清晰、直观地传达产品在页面层面的控制（如页面功能和信息、方向、逻辑等信息）。

2. 作用

页面流程图通常用于介绍产品页面元素及页面之间的跳转关系。

产品页面流程图一般由专门的交互设计师进行设计，其绘制过程能够帮助交互设计师确定产品页面之间合理自然的跳转顺序以及页面本身的功能及信息构成。

3.实例

总结

通过上面的实例我们不难发现：业务流程图、功能流程图、页面流程图的主要区别在于矩形图形（流程或节点）的内容的所处层次，其分别对应着 业务动作、功能动作、页面功能和信息。

整体上来说，产品业务流程图、功能流程图、页面流程图分别是产品设计阶段早、中、晚时期的阶段性产物。 在产品设计阶段，从业务到功能再到具体页面设计，这是一个抽象到具体实现的过程，也是产品概念转变为产品介质的核心过程。在这个过程中，产品业务确定了产品功能范围，产品功能又进一步确定了页面的实现范围。

最后，作者整理了引言中涉及到的各类流程图的对比关系图

后话

现在你还在意能否数清流程图的种类吗？其实流程图就是一个图形化的表达工具，其绘制过程能够帮助我们思考系统在某个层面的控制，流程图本身的图形化表达也能更简洁、清晰的传达系统在某个层面的控制信息（节点、流转方向等）。对于这个工具，我们最好不要钻牛角地非要数清流程图的“界门纲目科属种”（如上文介绍也没有这么一个通用的标准），根据实际情况灵活使用和理解才是第一位。

参考:

（1） 维基网络：流程图

（2） 全面解读流程图｜附共享单车摩拜ofo案例分析

（3） 产品经理之流程图表达业务逻辑 https://www.cnblogs.com/WUXIAOCHANG/p/10570343.html

‘陆’ 什么叫业务逻辑

业务逻辑是在智能网中，对利用积木式组件（SIB）和基本呼叫处理（BCP）模块的组合来完成每项业务特征的过程描述。

智能网是用于生成和提供电信新业务的网路结构体系。主要由业务交换点、业务控制点、业务管理点和业务创建点组成。主要目标是实现新业务的快速引入。

业务逻辑是在智能网中，对利用积木式组件(SIB)和基本呼叫处理(BCP)模块的组合来完成每项业务特征的过程描述。

智能网业务逻辑在不同的平面中有不同的表示，在总功能平面中，有一组总业务逻辑(GSL)，它说明了完成各个业务独立模块(SIB)链接在一起的次序；

在分布功能平面中，分布业务逻辑(DSL)是实现SIB功能时各个功能实体的动作和各个功能实体间的信息流；在物理平面中，包含业务控制功能(SCF)的物理实体执行业务逻辑程序。通信有限状态机模型是由表示进程的有限状态机和表示进程之间通道的先进先出队列(FIFO)组成。

(6)算法和业务逻辑扩展阅读：

业务逻辑层又可以细分为业务实体、业务组件和业务工作流。

业务实体(Entity)相当于以面向对象的类实例来代表数据库中的实体，可能使用过DataReader或者Dataset之类的对象来代表数据库中访问的行，不过，在使用这些对象时，需要通过列名称或索引来访问各列中的数据。

这将导致使用这些对象的页面与数据库实现耦合。通过编写一个实体层，将这种耦合性转移到了业务逻辑层中；于是，如果数据库发生了某些变动，可以修改业务逻辑层，而不需要维护页面层。

实体层中，不会包含业务逻辑；实体只是一个数据的集合体。

业务组件负责业务规则(例如，计算税率、折扣等)，同时负责实体层到数据访问层的过渡工作。

‘柒’ 在MVC模式中,业务逻辑及算法的类是属于M还是C

属于Model

‘捌’ 算法是不是产品经理应该考虑的问题为什么

开发问这个问题是因为大多数开发其实只是懂编程的语言，并不太懂数学/业务/用户行为（心理）/场景等。
产品经理就算不太懂数学，但是肯定比开发懂业务和用户行为，引导算法设计的关键问题指向应该是没问题的。
另一方面，产品经理必须要深刻理解算法的关键参数，因为这些关键参数直接影响功能设计，算法是产品经理应该考虑的问题，至少产品经理应该提供上层解决方案或看得明白最终方案。这俩年产品经理有俩细分比较吃香：大数据（或个性化推荐）产品经理、人工智能产品经理，这俩细分就很要求产品经理在算法逻辑上的能力，这是硬实力（产品汪相比攻城狮敲代码很少有拿得出手的硬实力）。算法类分析对于产品经理真不是大问题，自己迈出这一步你会发现原来自己还有更多可扩展的空间，而不是仅限于画原型及分析用户点击层面上的体验。这里给俩真实案例参考，是我之前14年在UC任职平台产品经理时，在所负责产品中应用的2个算法，之后写成了专利提案。

‘玖’ 经常有人提到业务逻辑,到底什么是业务逻辑

http://ke..com/view/1030527.htm

业务逻辑就是业务规则的制定、业务流程的实现、业务需求有关的系统设计

通俗来讲：就是把业务需求按照一定的逻辑关系分成几块方面，比如先有什么然后有什么，最后有什么。这里强调要有逻辑性，不能乱来，否者业务无法正常进行。

‘拾’ 【产品日思录】vol46.产品经理一定要写PRD么

这两天遇到一个问题，产品经理除了画原型外，是否 还要单独写一份PRD 文档？今天的话题就来聊聊这个问题我的看法。

我觉得，产品经理是否要产出PRD，还是 依据公司实际情况而定 ，需要同时权衡公司 工作习惯 、 开发人员使用方法 、 文档管理的便捷性 等几个方面，择优而取。

为什么这么说呢？以我本人经验为例，从开始做产品经理那天，我就没有PRD这个概念，最早的时候写的是《软件概要设计文档》、《软件详细设计文档》，接触互联网后，就直接上手Axure原型，开始做的时候喜欢炫技，尝试高保真，就是所有点击交互都做出来，但开发经常抱怨看不懂，不知道点哪儿怎么点，于是就把原型拆开，用流程图组成交互稿，再后来觉得流程图无法说明问题，就在交互稿上标注各种逻辑说明，字段描述，最后又觉得光放交互稿无法说明为什么要这么做，就把每次迭代的项目说明、开发目标、需求List、上线价值等也用Axure写上，直到现在也还在不断补充这个大Axure原型，最终结果类似下图：

从结果来看，大家还是很认可这样的需求描述形式的，原因有如下2点：

1、需求管理方便

每次维护一个版本迭代，直接保存当时的原型文件即可，需要修改、更新，也直接修改一个文件即可，非常方便。

2、需求沟通方便

无论是和需求方沟通，还是和开发、设计沟通，直接对照着一个个页面讲解即可，通常一个页面，交互、需求、逻辑、字段都有标注，能够做到 高效评审 。

依我的经验，还是比较推崇 把PRD和原型文档合在一起交付 。

当然，这样做也有如下缺点：

1、需求比较“散”，很难验收

原型毕竟是以“页面”为信息承载媒介，而需求是以“列表”形式存在，二者通常会 交叉存在 ，也就是说，很可能一个页面上的交互稿会实现多个需求，而1个需求也可能由多个页面实现。从而对开发、测试人员造成一定 识别困难 。通常这种情况我会单独在Axure开一个页面，把需求List和原型页面之间的关系画一个 映射表格 给开发、测试来对照。如下图所示：（“主题”一列为页面跳转链接，“redmine”一列为需求列表跳转链接）

2、算法、业务逻辑和字段标识，很难用原型标明

比如排序逻辑、热门算法、数据传输协议、埋点规则，这样的内容通常是没有用户界面的，也就无法和交互界面融合。通常这种情况我也会针对这样的需求，单独开一个页面，用文字、流程图的方式描述清楚。

因此， 很多公司也会通过单独撰写一份PRD文档，来解决我说的上述问题 。

总之，是否需要PRD文档，关键在于你写的需求 是否真正能被开发、测试、设计、需求方识别、认可 ，毕竟需求文档的使用者是他们。所以我觉得不用拘泥于形式，只要你的思路清晰、主次明确、逻辑顺畅，选择一个大家都认可的方式产出需求即可。

以上就是今天的思考，你们公司是怎么写需求的？期待你的留言~