产品经理要懂的开发规范与接口文档-技术圈

这是Kevin的第 866 篇原创，

持续日更，做产品经理的创业斜杠青年。

做产品经理久了，你会发现自己越来越像一个开发。
Kevin

长期埋头在产品设计、需求评审、开发流程、BUG优化的研发场景里，导致沟通对象要要么是开发、要么就是拉着开发和业务讨论技术实现；

可见做任何产品，不管产品如何简易设计化，都绕不过实际编码、和新技术学习过程。

PMTalk的技术故事

比如对于PMTalk团队来说，曾经就在苦恼做app这块自主研发。主要因为安卓和IOS双客户端，导致了必须要花2个客户端做开发人员的技术招募上。

一听说有一个新的技术：flutter，可以直接双开客户端。就麻烦投入到这块新技术的学习过程中了。在当前阶段Flutter是开发利器，性能也在可接受范畴。

对于flutter技术的报告，来自阿里巴巴淘系技术这样说道

“在保证客户端体验的前提下，flutter可以尽可能的提高研发效率，就意味着更高的生产力。

某些场景下，产品其实不需要依附于传统的 Native 业务研发 iOS/Android 双端需要分别投入，这样会导致研发成本高，端差异性大且依赖端侧发版，尤其是在微信生态集中运营的我们，主要是H5、小程序，产品集中在前端侧，flutter一套代码无差异的同时跑在 iOS 与 Android 两端；”
阿里巴巴技术

总结下来：

优点：1.开发效率高、2.调试效率高、3.目前性能最好的跨平台解决方案

缺点：1.初始包体积大、2.相同业务包体积略大于原生、3.不支持热更新（iOS端）4、生态还不健全

通flutter，实现了安卓、IOS只需要一个人即可解决。招聘原生客户端开发替换为招聘一个前端开发即可。

不仅减少了团队的成本，还为团队增加了活力。

这是产品经理为什么会变得像研发的理由之一。同样的在PMTalk用户量逐渐上升，我们还做过技术架构的升级。为了提升用户体验从单体架构上升到微服务。

1.什么是单体架构

在软件设计的时候经常提到和使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，一个典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。此时服务架构如图

2.微服务架构

通常跟微服务相对的是单体应用，即将所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的，这是一个逐渐演变的过程。

▲ 引用知乎上说明

以上都是基于用户体验、效率、快速验证的背景去提升在技术上的升级。是不是感觉产品经理是不是离开所谓的用户太远了？

不仅如此，产品经理其实还应该了解到规范的开发流程和代码管理规范。

我们做产品设计本质是一群团队协同办公，要想提升团队办公效率，就要针对人加强管理、制定人的规范和流程；通过规范可以告知开发人员什么该做、什么不该做，以及打破团队浑浊不堪的情况

1.代码管理

代码管理主要分三大角色：系统管理者、项目管理者、部署者、开发者。系统管理者负责创建新项目、权限分配、用户增加删除和代码库备份。项目管理者负责对具体的某一个项目的权限分配，代码管理。部署者负责对测试代码和正式代码进行发版部署。开发者负责从项目分支代码进行代码开发。

2.安全规范

安全规范是环境、代码所使用的开源框架是否有存在XSS攻击漏洞问题。在小团队来说，这一点几乎交给了云服务器厂商。而中大型企业，数据资产、代码安全则需要依靠严谨的安全规范。比如通过建立自由的SVN来管理代码

3.版本命名规范

版本命名包含：主版本号、次版本号、修正版本号、里程碑版本号。例如：2.2.0.Beta2，该版本号代表主版本为2，次版本为2，修正版本无，且为发布的第二个公测版本。这个可以是产品和开发主动协商来定。

4.开发流程规范

选择瀑布流还是敏捷方式进行开发。通常都是如下步骤

需求调研-产品设计-需求评审- UI设计-前端开发-后端开发-测试-灰度发布。团队大的企业会把产品设计分为：产品设计、UED设计2个环节；同时还会增加UI评审这个环节
开发流程

5.统一编码规范

这里主要是涉及到命名，可以参考下面4个命名方式

- camelCase命名法(驼峰式命名)
  开头单词小写，后面单词首字母大写。在Java的官方标准中，Camel命名法被作为主要命名法。使用的很普遍，很多人习惯这种命名方法。示例：userName
- PascalCase命名法(帕斯卡命名)
  与camelCase命名类似，所有单词首字母大写。有时会有人称为大驼峰式命名。使用很普遍，变量名，方法名等。示例：UserName
- kebab-case(短横线命名)
  单词以 ‘-’ 短横线连接，常见的class命名方法。示例：user-name
- UnderScoreCase(下划线命名)
  单词以 ‘_’ 下划线连接，常见文件名的命名。示例：user_name
命名规范

6.注释规范

功能函数、接口、类都要有对应的注视规范，比如版本时间、业务描述、针对关键代码也要增加详细描述。

7.开发环境规范

主要是要统一开发语言、统一开发框架、统一开发方法、和开发环境。这是最基础的规范。

8.代码管理规范

代码管理要有一个readme.md

这个文件：项目调试/运行依赖的环境有什么，项目第一次从代码库拉下来必须要进行的配置文件在哪里，项目如何打包/运行，项目的输入输出都在哪里这部分代码从何看起如何对这个项目进行测试。

产品经理要搞定的接口文档

接口文档是产品经理整合第三方能力的入口，每个平台通过对外接口提供了自家的技术能力，做产品的时候最基础的必入微信、微博、抖音这些第三方接入点，都需要平台方提供接口。

开发人员在设计接口之前，还要了解到产品的技术架构，涉及到高内聚、低耦合、数据压力等方面外，还需要做下面3个步骤

了解需求:从“客户端-接口-数据库”的层次上看，接口明显扮演着承上启下的角色，一方面要明白接口要什么数据，另一方面要考虑如何从数据库获取、组织数据。所以如果不了解需求，你就无法正确抽象对象来组织数据给客户端，也无法验证数据库的数据结构能否满足需求。
了解数据库结构:既然接口要明白如何从数据库获取、组织数据，就当然要了解数据库结构啦。
了解客户端原型:了解原型，其实更多是为了帮助你设计接口时需要提供的数据和结构。

接口文档的出现在项目内是因为产品研发分前后端、算法、大数据中心等版块。版块与版块的对接需要由各个部门工程师定义接口，通过文档的方式固定标准的数据传输格式、安全策略。

接口文档一直要维护到项目结束，甚至是在当前框架下的版本。接口文档既然是文档，就是方便后续随时查阅。以及人员维护和更新

接口文档的规范分为4个部分

1.方法

包括新增、修改、删除、获取，在代码用post\put\delete\get4个来表示

2.URL

开头都以/a开头，如果涉及到用户登录信息才能使用的接口需要加/a/u，

3.请求参数和返回参数

这个是产品经理继续要关注的，能够通过返回参数判断要想实现的产品设计方法能不能实现。比如微信支付中可以给开发者返回支付成功、支付失败、以及支付执行）

4.返回参数的结构

（1）只返回调用成功或失败

那结构体是：code、message

（2）返回某些参数参数

结构体分别是：code/message/data、code/message/object

（3）如果要返回列表

code/mesage/data,data是object，里面放置page/size/total/totalPage/list 5个参数，其中list是Arrary类型，list里放object，object里是具体的参数。

无论哪种做什么样的简易设计，以上的开发都是基础。只有团队提前设计好规范

今天的分享就在这。

今日Bonus：加我好友 pmkevin001，领取「Kevin的原型部件库」，同时还有运营模版，带你了解快速提升产品运营进阶

👇阅读原文、或扫码加入打卡训练营，每天体验1款APP

每天体验1款app知识星球

有1200名产品经理在圈子里。加入后365天，每天体验一款APP。提升产品设计能力，同时有1500+份体验报告帮助你找到竞品。

平均1天1块钱，扫码购买即可加入

连续体验90款应用，通过后原路退回