產(chǎn)品經(jīng)理要懂的開發(fā)規(guī)范與接口文檔
這是Kevin的第 866 篇原創(chuàng)，
做產(chǎn)品經(jīng)理久了，你會發(fā)現(xiàn)自己越來越像一個開發(fā)。
Kevin
長期埋頭在產(chǎn)品設(shè)計(jì)、需求評審、開發(fā)流程、BUG優(yōu)化的研發(fā)場景里，導(dǎo)致溝通對象要要么是開發(fā)、要么就是拉著開發(fā)和業(yè)務(wù)討論技術(shù)實(shí)現(xiàn)；
可見做任何產(chǎn)品，不管產(chǎn)品如何簡易設(shè)計(jì)化，都繞不過實(shí)際編碼、和新技術(shù)學(xué)習(xí)過程。
PMTalk的技術(shù)故事
比如對于PMTalk團(tuán)隊(duì)來說，曾經(jīng)就在苦惱做app這塊自主研發(fā)。主要因?yàn)榘沧亢虸OS雙客戶端，導(dǎo)致了必須要花2個客戶端做開發(fā)人員的技術(shù)招募上。
一聽說有一個新的技術(shù)：flutter，可以直接雙開客戶端。就麻煩投入到這塊新技術(shù)的學(xué)習(xí)過程中了。在當(dāng)前階段Flutter是開發(fā)利器，性能也在可接受范疇。
對于flutter技術(shù)的報(bào)告，來自阿里巴巴淘系技術(shù)這樣說道
某些場景下，產(chǎn)品其實(shí)不需要依附于傳統(tǒng)的 Native 業(yè)務(wù)研發(fā) iOS/Android 雙端需要分別投入，這樣會導(dǎo)致研發(fā)成本高，端差異性大且依賴端側(cè)發(fā)版，尤其是在微信生態(tài)集中運(yùn)營的我們，主要是H5、小程序，產(chǎn)品集中在前端側(cè)，flutter一套代碼無差異的同時跑在 iOS 與 Android 兩端；” 阿里巴巴技術(shù)
總結(jié)下來：
優(yōu)點(diǎn)：1.開發(fā)效率高、2.調(diào)試效率高、3.目前性能最好的跨平臺解決方案
缺點(diǎn)：1.初始包體積大、2.相同業(yè)務(wù)包體積略大于原生、3.不支持熱更新（iOS端）4、生態(tài)還不健全
通flutter，實(shí)現(xiàn)了安卓、IOS只需要一個人即可解決。招聘原生客戶端開發(fā)替換為招聘一個前端開發(fā)即可。
不僅減少了團(tuán)隊(duì)的成本，還為團(tuán)隊(duì)增加了活力。
這是產(chǎn)品經(jīng)理為什么會變得像研發(fā)的理由之一。同樣的在PMTalk用戶量逐漸上升，我們還做過技術(shù)架構(gòu)的升級。為了提升用戶體驗(yàn)從單體架構(gòu)上升到微服務(wù)。
1.什么是單體架構(gòu)
在軟件設(shè)計(jì)的時候經(jīng)常提到和使用經(jīng)典的3層模型，即表現(xiàn)層，業(yè)務(wù)邏輯層，數(shù)據(jù)訪問層。雖然在軟件設(shè)計(jì)中劃分了3層模型，但是對業(yè)務(wù)場景沒有劃分，一個典型的單體架構(gòu)就是將所有的業(yè)務(wù)場景的表現(xiàn)層，業(yè)務(wù)邏輯層，數(shù)據(jù)訪問層放在一個工程中最終經(jīng)過編譯，打包，部署在一臺服務(wù)器上。此時服務(wù)架構(gòu)如圖
2.微服務(wù)架構(gòu)
通常跟微服務(wù)相對的是單體應(yīng)用，即將所有功能都打包成在一個獨(dú)立單元的應(yīng)用程序。從單體應(yīng)用到微服務(wù)并不是一蹴而就的，這是一個逐漸演變的過程。
▲ 引用知乎上說明
以上都是基于用戶體驗(yàn)、效率、快速驗(yàn)證的背景去提升在技術(shù)上的升級。是不是感覺產(chǎn)品經(jīng)理是不是離開所謂的用戶太遠(yuǎn)了？
不僅如此，產(chǎn)品經(jīng)理其實(shí)還應(yīng)該了解到規(guī)范的開發(fā)流程和代碼管理規(guī)范。
我們做產(chǎn)品設(shè)計(jì)本質(zhì)是一群團(tuán)隊(duì)協(xié)同辦公，要想提升團(tuán)隊(duì)辦公效率，就要針對人加強(qiáng)管理、制定人的規(guī)范和流程；通過規(guī)范可以告知開發(fā)人員什么該做、什么不該做，以及打破團(tuán)隊(duì)渾濁不堪的情況
1.代碼管理
代碼管理主要分三大角色：系統(tǒng)管理者、項(xiàng)目管理者、部署者、開發(fā)者。系統(tǒng)管理者負(fù)責(zé)創(chuàng)建新項(xiàng)目、權(quán)限分配、用戶增加刪除和代碼庫備份。項(xiàng)目管理者負(fù)責(zé)對具體的某一個項(xiàng)目的權(quán)限分配，代碼管理。部署者負(fù)責(zé)對測試代碼和正式代碼進(jìn)行發(fā)版部署。開發(fā)者負(fù)責(zé)從項(xiàng)目分支代碼進(jìn)行代碼開發(fā)。
2.安全規(guī)范
安全規(guī)范是環(huán)境、代碼所使用的開源框架是否有存在XSS攻擊漏洞問題。在小團(tuán)隊(duì)來說，這一點(diǎn)幾乎交給了云服務(wù)器廠商。而中大型企業(yè)，數(shù)據(jù)資產(chǎn)、代碼安全則需要依靠嚴(yán)謹(jǐn)?shù)陌踩?guī)范。比如通過建立自由的SVN來管理代碼
3.版本命名規(guī)范
版本命名包含：主版本號、次版本號、修正版本號、里程碑版本號。例如：2.2.0.Beta2，該版本號代表主版本為2，次版本為2，修正版本無，且為發(fā)布的第二個公測版本。這個可以是產(chǎn)品和開發(fā)主動協(xié)商來定。
4.開發(fā)流程規(guī)范
選擇瀑布流還是敏捷方式進(jìn)行開發(fā)。通常都是如下步驟
需求調(diào)研-產(chǎn)品設(shè)計(jì)-需求評審- UI設(shè)計(jì)-前端開發(fā)-后端開發(fā)-測試-灰度發(fā)布。團(tuán)隊(duì)大的企業(yè)會把產(chǎn)品設(shè)計(jì)分為：產(chǎn)品設(shè)計(jì)、UED設(shè)計(jì)2個環(huán)節(jié)；同時還會增加UI評審這個環(huán)節(jié) 開發(fā)流程
5.統(tǒng)一編碼規(guī)范
這里主要是涉及到命名，可以參考下面4個命名方式
camelCase命名法(駝峰式命名)
開頭單詞小寫，后面單詞首字母大寫。在Java的官方標(biāo)準(zhǔn)中，Camel命名法被作為主要命名法。使用的很普遍，很多人習(xí)慣這種命名方法。示例：userNamePascalCase命名法(帕斯卡命名)
與camelCase命名類似，所有單詞首字母大寫。有時會有人稱為大駝峰式命名。使用很普遍，變量名，方法名等。示例：UserNamekebab-case(短橫線命名)
單詞以 ‘-’ 短橫線連接，常見的class命名方法。示例：user-nameUnderScoreCase(下劃線命名)
單詞以 ‘_’ 下劃線連接，常見文件名的命名。示例：user_name
命名規(guī)范
6.注釋規(guī)范
功能函數(shù)、接口、類都要有對應(yīng)的注視規(guī)范，比如版本時間、業(yè)務(wù)描述、針對關(guān)鍵代碼也要增加詳細(xì)描述。
7.開發(fā)環(huán)境規(guī)范
主要是要統(tǒng)一開發(fā)語言、統(tǒng)一開發(fā)框架、統(tǒng)一開發(fā)方法、和開發(fā)環(huán)境。這是最基礎(chǔ)的規(guī)范。
8.代碼管理規(guī)范
代碼管理要有一個readme.md
這個文件：項(xiàng)目調(diào)試/運(yùn)行依賴的環(huán)境有什么，項(xiàng)目第一次從代碼庫拉下來必須要進(jìn)行的配置文件在哪里，項(xiàng)目如何打包/運(yùn)行，項(xiàng)目的輸入輸出都在哪里這部分代碼從何看起如何對這個項(xiàng)目進(jìn)行測試。
產(chǎn)品經(jīng)理要搞定的接口文檔
接口文檔是產(chǎn)品經(jīng)理整合第三方能力的入口，每個平臺通過對外接口提供了自家的技術(shù)能力，做產(chǎn)品的時候最基礎(chǔ)的必入微信、微博、抖音這些第三方接入點(diǎn)，都需要平臺方提供接口。
開發(fā)人員在設(shè)計(jì)接口之前，還要了解到產(chǎn)品的技術(shù)架構(gòu)，涉及到高內(nèi)聚、低耦合、數(shù)據(jù)壓力等方面外，還需要做下面3個步驟
了解需求:從“客戶端-接口-數(shù)據(jù)庫”的層次上看，接口明顯扮演著承上啟下的角色，一方面要明白接口要什么數(shù)據(jù)，另一方面要考慮如何從數(shù)據(jù)庫獲取、組織數(shù)據(jù)。所以如果不了解需求，你就無法正確抽象對象來組織數(shù)據(jù)給客戶端，也無法驗(yàn)證數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)能否滿足需求。
了解數(shù)據(jù)庫結(jié)構(gòu):既然接口要明白如何從數(shù)據(jù)庫獲取、組織數(shù)據(jù)，就當(dāng)然要了解數(shù)據(jù)庫結(jié)構(gòu)啦。
了解客戶端原型:了解原型，其實(shí)更多是為了幫助你設(shè)計(jì)接口時需要提供的數(shù)據(jù)和結(jié)構(gòu)。
接口文檔的出現(xiàn)在項(xiàng)目內(nèi)是因?yàn)楫a(chǎn)品研發(fā)分前后端、算法、大數(shù)據(jù)中心等版塊。版塊與版塊的對接需要由各個部門工程師定義接口，通過文檔的方式固定標(biāo)準(zhǔn)的數(shù)據(jù)傳輸格式、安全策略。
接口文檔一直要維護(hù)到項(xiàng)目結(jié)束，甚至是在當(dāng)前框架下的版本。接口文檔既然是文檔，就是方便后續(xù)隨時查閱。以及人員維護(hù)和更新
接口文檔的規(guī)范分為4個部分
1.方法
包括新增、修改、刪除、獲取，在代碼用post\put\delete\get4個來表示
2.URL
開頭都以/a開頭，如果涉及到用戶登錄信息才能使用的接口需要加/a/u，
3.請求參數(shù)和返回參數(shù)
這個是產(chǎn)品經(jīng)理繼續(xù)要關(guān)注的，能夠通過返回參數(shù)判斷要想實(shí)現(xiàn)的產(chǎn)品設(shè)計(jì)方法能不能實(shí)現(xiàn)。比如微信支付中可以給開發(fā)者返回支付成功、支付失敗、以及支付執(zhí)行）
4.返回參數(shù)的結(jié)構(gòu)
（1）只返回調(diào)用成功或失敗
那結(jié)構(gòu)體是：code、message
（2）返回某些參數(shù)參數(shù)
結(jié)構(gòu)體分別是：code/message/data、code/message/object
（3）如果要返回列表
無論哪種做什么樣的簡易設(shè)計(jì)，以上的開發(fā)都是基礎(chǔ)。只有團(tuán)隊(duì)提前設(shè)計(jì)好規(guī)范
今天的分享就在這。
今日Bonus：加我好友 pmkevin001，領(lǐng)取「Kevin的原型部件庫」，同時還有運(yùn)營模版，帶你了解快速提升產(chǎn)品運(yùn)營進(jìn)階
每天體驗(yàn)1款app知識星球
有1200名產(chǎn)品經(jīng)理在圈子里。加入后365天，每天體驗(yàn)一款A(yù)PP。提升產(chǎn)品設(shè)計(jì)能力，同時有1500+份體驗(yàn)報(bào)告幫助你找到競品。
平均1天1塊錢，掃碼購買即可加入
連續(xù)體驗(yàn)90款應(yīng)用，通過后原路退回