起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理：不得不懂的基礎技術知識
剛入門產品，和開發溝通的時候總是被懷疑智商？沒事，本文和你分享一下那些溝（si）通（bi）經歷，并告訴你產品經理必須知道的基礎技術知識！
一入產品深似海。身為產品汪，我想說產品汪和程序猿是兩個物種，一個來自金星，一個來自火星，腦結構、腦回路截然不同，關鍵是他們還健忘！
雖說“人人都是產品經理”，但也造成產品成為整個行業“鄙視鏈”的末端。
C開發看不起做C++開發，C++開發看不起Java開發，Java開發看不起C#開發，C#開發看不起做前端開發。但他們確都有個共同點，就是一致覺得產品是超低智商生物。
溝通不易，但不得不溝通！
聽不懂的時候怎么辦，如果只是干等，那等同挖坑埋自己。和開發溝通之前一定要做足功課，否則分分鐘被噴！十幾個開發一起噴你，那就是群毆。
希望這篇文章能給剛入門的產品補點技術能量，關愛程序猿。
曾經你以為，產品的日常黑話是：
我不管，反正你要實現！
做這么點東西要那么久嗎，分分鐘就能搞定吧！
要不你先做一版，先看看效果再說，不行再改。
我的需求很簡單，很簡單的，照著這個做就行了，一模一樣就好！
現實卻是：
好的，我今晚加班，晚上把原型和RFP郵件發給你們。
別慌，我去跟領導申請下增加開發資源！
穩住，你們先榮耀一把吧，晚上一起加班呀。
如果你還行走在互聯網圈子里，基礎技術知識是產品必須要了解的。
我日常游走在一群前后端狂魔中，被灌輸很多毒藥，但也只能自行一一消化，現在一一吐露。
一、少不了的接口
說到接口，它“無處不在”，當打開APP的時候，你會看到一個菊花轉啊轉啊轉呀，然后加載出來的那些文字、圖表、炫酷的動畫就是前端ajax通過接口提交數據從后端請求回來的數據。
一個完整的APP項目一般都是由客戶端（前端）和服務端（后端）相結合。
- 接口，就是后端將數據源或數據庫提供給外部應用去調用的一段程序。
- 接口可以完成某個任務，但是它需要有相應的輸入（即入參）。在工作中，少不了要定義五花八門的接口。
后端定義好URL，前端按照規定的格式請求它，它就會把數據給你，這就是接口。
前端負責將數據展示給用戶并快速響應用戶所有的操作（點擊、長按、左滑、右滑、下拉刷新等等），后端則負責將數據在服務器上進行一系列處理（增、刪、改、查）后返回給前端。
前端負責拿到數據并處理數據展示出來。
千萬不要覺得前端工作簡單，不就是寫個html頁面展示數據，但是他們需要考慮各種瀏覽器的兼容性、各種土豪、土鱉等設備適配性，響應式設計、VR、AI、3D效果層出不窮的新概念新挑戰，且行且珍惜。
接口四要素：
- 方法 ：Post（增）、Delete（刪）、 put（改）、Get（查）
- url： /userinfo
- 請求參數：字段、說明、類型、備注、是否必填
- 返回參數：code/message/data
看個示例：
｛
“code”：200，
“msg”：“成功”，
“time”：“677788888”，
“data”：｛“name”：“張三”，“age”：“23”}，
}
規范的接口得保證：
- 要保持好身材，瘦，瘦，瘦！盡量前端不要處理業務邏輯、不進行金額計算、且減少處理請求參數的校驗；
- 要有可拓展性：文章、圖片最好由后端來提供；
- 要可靠安全、性能優化、體驗流暢。
在項目進行中，接口聯調尤為關鍵。
接口聯調，就是［前后端平心靜氣、坐在一起校對數據］＝＝［一言不合就開懟、項目一完就吹水。
聯調主要是為了解決數據格式問題和數據參數問題。
這里提一下接口文檔。
接口文檔一般由后端進行編寫，需要和前端一起協商補充，注意要溝通、溝通、溝通！在項目開發過程中，前后端工程師會根據這份文檔為主，要共同維護和更新它，直到項目結束。
- 它可以讓前后端工程師圍繞一個統一的文檔進行溝通交流開發，減少溝通成本；
- 項目維護中或者項目人員更迭，方便后期人員查看、維護，減少學習成本；
- 也可一定程度上體現程序猿的表（wen）達（mang）能力；
- 最重要一點，它可以是后期甩鍋的強有力證據。
通常，前端開發人員和后臺開發人員是不同的人。當然，部分種子選手兩者兼顧，曰全棧工程師（仰望大神）。不過，前后端的思維模式不一樣，要打造一個全棧工程師，學習成本極高。
一般來說，核心業務都會分離開，畢竟人的精力有限，要保質保量保安全，一個人兼顧不過來。
附上一小段前后端聯調接口日常對話：
后臺：接口好了，你試試。
前端：不行，500。
后臺：我看看。
半個小時飄過。
后臺：好了，修復了個bug，你再試試。
前端：不行呀，還是500。
過了很久……
后臺：好了，我重構了下代碼，參數改了，接口文檔有更新，你看看。
前端：好的（心里MMP）。
產品：下周一提測哦。
前端、后臺：網易云音樂－涼涼……
二、坑不死你的“寫死”
不是你們說的那個編劇又把男主角寫死的那個意思。
回到正題，我們前面說到了接口可以請求到數據。
對一個頁面而言，頁面的數據一方面由前端直接寫死，也就是靜態數據，另一部分需要有后端接口提供，前端需要從后端請求接口拿到數據并按照要求展示到頁面上，比如淘寶的商品列表。
但數據有靜態數據和動態數據，有些數據可以由前端寫死的，雷打不動。這就是靜態數據。
例如某些APP首頁下方的那些TAB欄，就是寫死的，因為那些TAB基本不會有變化。
類比你去飯店吃飯，你點了個螺獅粉，老板問你要不要辣，你腦子一熱就說加辣，那端上來的肯定是紅通通的一端，基本就這樣了。如果你覺得辣，那你只能重新點一碗。
- 優點：減少和服務端進行請求。
- 缺點：后期如有擴展，要填坑。
三、高逼格的組件及框架
跟前端小伙交（si）流（bi）多了，組件這個詞，除非你聾，不然一定會有所耳聞。
前端在寫頁面的時候，發現很多頁面有相似的地方，相似的地方功能也相同。比如都是一個表單，一個banner輪播圖，一個下拉框。So，為了提高代碼復用性，減少重復性的開發，就把頁面封裝起來以便下次復用，這就是一個組件。
組件可以看作是自定義的CSS＋HTML+JavaScript重新組合，它是一種可拼裝的功能集合。
簡單說下HTML＋CSS+JavaScript，舉個某寶的首頁，首頁看到的圖片、文字都是一個個的HTML元素，然后頁面的背景顏色、圖片大小，按鈕位于整個頁面的什么位置，這就是CSS做的。
至于JavaScript，簡稱js，可以看成首頁的大腦，主要實現內部的邏輯，比如按鈕點擊之后怎么處理，界面之間如何跳轉，什么時候刷新信息，如何請求數據。它需要把后端返回的數據添加到頁面中，或者讓元素運動起來，或者是改變頁面的CSS，或者是操作HTML元素。
?類比產品Axure作原型圖，每個頁面都需要有頂部狀態欄，我們會運用幾個按鈕、矩形框進行組合，命名為母版。
類比我們以前高考備戰采用大量的習題戰術，我們會有一本錯題集，學霸們會怎么利用這本錯題集呢？他們會按照考點對錯題集分類。對組件也是一樣，有相似的功能可以歸并為一類。
你寫的代碼越來越多，你封裝的組件就越來越多。慢慢的，你就有個組件庫，包括樣式組件、UI組件、基礎組件、業務組件等等。Perfect，組件還可以進行再組合，把組件再整合起來，是一種組件間相互關系的設計。
類比你手機裝了支付寶APP，它可以用來買理財產品、可以用來買保險，可以使用第三方服務，但是對一些人而言，他不需要這些功能，他只是把錢放在余額寶里，偶爾迷茫的時候去看一眼。
框架不是越大越好?？蚣苤恍璞Ａ艋镜墓δ?，但是它會提供方式給你去擴展，這才是好的框架。
四、天天念叨的DOM
- DOM全稱Document Object Model，翻譯就是文檔對象模型。
- DOM是一系列功能集合，是處理HTML和XML文檔的編程接口。
- DOM允許開發人員從文檔中增、刪、查、改頁面數據。直白的講，它給文檔提供了一種結構化的表示方法，可以改變文檔的內容和呈現方式。
- DOM技術使頁面可以動態地變化，如可以動態地顯示或隱藏一個元素，改變它們的屬性，增加一個元素等。
- 可以把DOM認為是頁面上數據和結構的一個樹形表示。
- DOM的功能是把瀏覽器支持的文檔（包括HTML、 XML、 XHTML）都當成對象來解析。
請看下面這個HTML文件：
html
head
titleDOM/title
/head
body
h1DOM Lesson one/h1
phello world/p
/body
/html
你可以看出，最外面一層是html，html嵌套著head和body標簽，head嵌套著title標簽，body嵌套著p標簽。
同理，DOM也是一層一層嵌套著，這種層級關系不是隨便定的，是有一定的規則。
- 這可類比于我們存放的文件路徑: 我的電腦-CDEFG盤-學習資料-日本語音-島國電影。
- 也可類比于我們博大精深的親人關系表。
DOM它易用性強，并且遍歷簡單，直接操作DOM無所不能。
但操作DOM效率低，解析速度慢，內存占用量過高，且DOM機制中所運用的大量對象的創建和銷毀影響效率。
所以出現了虛擬DOM。這個我就編不下去了。
五、Cookie、Session、Token哪家強
在傳統的web應用中，服務器端通過一種存儲機制保存了會話信息（Session）。
Session可以理解為后臺服務器的一小片內存。
每個會話信息都對應一個唯一的編號：Session ID，這個字符串隨機產生，服務器端會把Session ID放在Cookie里面，Cookie數據存放在客戶端。Session的狀態是存儲在服務器端，客戶端存的只有Session id。
Cookie是服務器給客戶端的憑證，可以理解為存在客戶端的一個txt文件。
里面包括你登錄信息之類，這樣你下次在登錄某個網站，就會自動調用Cookie，取到Session id到后端服務器獲取對應的Session具體信息，進行數據的保存和修改，但Cookie存放在客戶端易被盜用篡改，不是很安全。
這類比于你去逛超市，你存放了私人物品在儲物柜子里，它會給你個取件的紙條，等你逛完超市后，就可以掃描紙條打開柜子。
在前后端沒有分離的時候，前端頁面往往都屬于后臺管理，這個大部分是同源請求。
但是在前后端分離后，這個時候一般涉及到跨域，跨域的請求不攜帶Cookie，要攜帶Cookie又要后臺指定允許的跨域地址，比較麻煩，于是出現了Token。
Token就是令牌。
Token一般是由uid＋時間戳＋設備號＋自定義規則經過算法加密后的一串字符串。字符串通常很長，難偽造。
這類比于服務器生成了一個單號返回給客戶端，客戶端帶著單號過來請求請求器，這時候怎么證明單號是服務器生成的呢，可以通過單號來檢查。
比如你授權（登錄）一個程序時，它就是個依據，判斷你是否已經授權程序；Token的狀態是存儲在客戶端。
在APP開發中，都是使用Token作為驗證后的憑證。
一般采取的措施是客戶端輸入用戶名和密碼，客戶端登錄后，服務器端會返回一個Token，之后所有的請求都會帶著Token，客戶端把Token放在請求頭（header）里，在應用中一般使用https會增加安全性，拿到Token才能進入頁面內。
后端通過檢驗請求頭判斷是否登錄、是否正常請求、是否安全后再提供服務。
六、程序猿又說要重構
開發人員經常抱怨 ：
“這么爛的代碼，維護不了啦，需要重構！”
“這代碼怎么能這么不優雅？誰來重構一下？”
我。。。。忍不住給你們這些卓越的工程師打Call。
重構是對代碼做任何更動，以增加可讀性或者簡化結構，而不影響輸出結果。
- 輕一點：優化原有代碼，改善代碼質量，比如三行代碼用一行就解決，降低復雜度。
- 重一點：完全重寫，幾乎不用原來的代碼。
- 再嚴重一點說：為了有事干！知道它的重要性了吧！
重構成功的話，從長遠來看應該是利大于弊的，對用戶而言：更快、更流暢、更美觀；對碼農而言：易維護，更易讀，一看就是優雅的代碼，特別是人員流動比較大的項目。
作為產品經理，我表示：重構有風險，重構需謹慎，得做到：
1. 充分的測試！?。。?/strong>
看似簡單，但是往往都做不到，項目成員對于充分的定義標準都不一樣，產品經理永遠都覺得沒有測試足夠，也不可能百分百的覆蓋率。這個時候，利用自動化測試工具未免不是一個有效途徑。
2. 充分的溝通?。。?！
很多需求提出方不理解為什么要重構，但他們卻要為重構買單，在他們看來往往就像個騙局。
對于新功能的重構，應該融入到正常開發過程中，如何讓上帝理解重構的價值，反思一下遇到的問題：是由于早起技術架構的缺陷，還是業務領域模型變動太大？如何避免今后再次遇到，得到上帝的理解和認可，這至關重要。
3. 充分的思量?。。。?/strong>
考慮時間成本！人力成本！學習成本！盡量避免大的重構，這樣可以減少多方的工作量，也會減少項目延期的風險。
對于一些核心功能，進行重構之前盡早告知團隊，并重點闡述下重構的周期、目的以及會涉及到的業務區域，這樣做一方面可以讓項目經理合理地安排排期。盡量避免上線前進行重構，因為風險無法預估。
七、調試、打包、部署
啊，不是那個你去店里點餐，跟老板說的那個打包！
程序猿做項目的時候，會在本地搭建一個開發環境，用于調試自己的代碼。
程序猿說的碼代碼只有程序猿自己才認識，計算機根本不認識，計算機只認識二進制。
打包，就是將自己寫的代碼（Bug）打包成一個文件，即二進制文件（010101這種格式）。
但要區分下，前端的打包，實質是合并壓縮處理前端資源文件：包含HTML文件、js文件、CSS文件、圖片、字體、svg等等。
前端的打包工具, 流行的有：Gulp、Grunt、Webpack等工具。
打包工具可以讓開發網頁的時候使用import export require，像后端程序員一樣進行模塊化開發，每個模塊異步請求加載，可以減少請求提高性能，這樣瀏覽器可以通過少量的請求獲取到所需要的前端資源,節省流量，加快頁面加載速度，關鍵還起到混淆代碼的作用。
打包是為了運行，打包完了就代表整裝待發了。
項目要上線的時候，程序猿要將自己的代碼部署到生產環境上。這需要你準備就緒：版本號要高于線上版本、去除一些調試信息、混淆、簽名、做對齊等等。
部署，一般指服務器端程序上線，但是要給程序提供所需要的資源，讓它好好的運行起來。
就像你養花，你如何讓它在花盆里面存活，你得有空氣，有水，有養料。
同樣，要運行起你的一大坨代碼，就要配置好環境，比如使用幾個服務器、放在什么服務器上、開什么端口、怎么才能扛住大量的請求等等。
八、負載均衡有一手
負載均衡（又稱為負載分擔），英文名稱為Load Balance。
官方說法：
將負載（工作任務）進行平衡、分攤到多個操作單元上進行執行，例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等，從而共同完成工作任務。
通俗來講：就是將用戶請求分發到N臺服務器，一臺服務器需要處理的任務分給N臺服務器來處理，但不能簡單理解為分配給所有服務器一樣多的任務，因為服務器的承載能力各不相同。N臺服務器一起處理任務叫集群。
負載均衡設備不是基礎網絡設備，而是一種性能優化設備。
負載均衡的核心就是“分散壓力”，使所有的服務器都不會超過自己可承受的程度，避免宕（dang）機。
為什么要有負載均衡，對于網絡應用而言，并不是一開始就需要負載均衡，當網絡應用的訪問量不斷增長，單個處理單元無法滿足負載需求時，網絡應用流量將要出現瓶頸時，負載均衡才會起到作用。
類比你每逢節假日逛超市的時候，就能看到“負載均衡“的例子，收銀員高峰期只能服務10位顧客，當做活動時有20位顧客需要服務的話可能就會排長隊，這樣購物體驗將會很差(類比客戶抱怨系統/網站訪問太慢)。最簡單的辦法就是再招個營業員，重新開通一個收銀窗口。
九、F5不是一個快捷鍵
其實，一說到負載均衡，就會聯想到F5=刷新快捷鍵嗎？就服你！
其實F5是只是負載均衡產品的一個品牌，其地位類似于諾基亞在手機品牌中的位置。
F5作為一級路由器，它是流量總入口，相當重要，因為它扛著外界所有的請求壓力。
有人會問？為什么不搞多臺F5？
F5如此卓越穩定，當然貴呀！貴呀！貴呀！死心了吧。
所以在它這里不會去做運算，它需要做的就是轉發流量<，轉發給二級路由器nginx，nginx需要解析協議內容，做更加精細化路由。
F5和nginx其實只是負載工具，只是分工不同而已，這是他們的價值所在。
十、負載均衡實現一二三
1. 重定向
這種方式，是通過將請求全部發送到前置機，由前置機通過算法得出要分配給那臺應用服務器，然后響應給客戶端，由客戶端重定向到應用服務器的一種方式。
類比個例子，一家公司舉辦招聘活動，每個人都可能要去往不同的樓層進行投遞簡歷，所有的面試者都會先集中在一樓前臺處，然后由前臺MM為大家一一查詢所對應的樓層，然后告知每一個面試者對應的樓層，由面試者自行前往自己的樓層投遞簡歷。
你可以看到，每一個的請求，都要重定向一下，效率不高。
2. 反向代理
這種方式，是通過在前置機使用反向代理方式，將請求分發到應用服務器，客戶端無需再請求一次，實現方式通常有兩種，一種是用交換機實現，還有一種是用nginx實現。
這就相當于前臺MM為面試者查詢到對應的樓層之后，直接將簡歷分發到對應樓層。不需要面試者再自行跑一趟。樓層收到簡歷后，也會響應請求。
這種方式，對比重定向，效率較高，但是由于請求和響應都是通過前置機來的，所以對前置機的考驗很大。
3. 數據鏈路返回
這種方式，通過給應用服務器設置虛擬IP，然后通過修改mac地址的方式，將請求分發出去，而應用服務器收到請求后，可以直接響應給客戶端，而不需要經過前置機。
這類比于面試者不需要通過前臺MM，自己直接將簡歷投遞到對應樓層，樓層收到簡歷后，會想要面試者的請求。
這種方式中，由于前置機只需要接受請求，不需要響應數據，所以，效率較第二種較高。
十一、風風火火的小程序
上次前端小伙在進行內部分享的時候，我去偷師了一下。
小程序＝高逼格一點的H5頁面。
微信自己定義一套html標簽，稱之為wxml，又封裝了一些樣式規則，叫wxss，其實就等同于html+css+js。
封裝一方面是為了降低開發成本，根本上是為了收攏控制權限，開發者能用的東西越多，微信需要操心的事情也就越少。
1.要做小程序開發，你得裝個開發工具，微信提供的；
附上開發地址：
https://developers.weixin.qq.com/miniprogram/dev/devtools/download.html?t=20171227
2.然后，你需要去微信公眾平臺開通個小程序賬號；
3.接著你就要去學js；
微信小程序用js來作為開發語言，用定義的wxml來描述界面，用wxss來表達樣式，這些也是最基本的幾個要素。開發語言不用說，js非常成熟，解析js的引擎也有很多。
十二、寫在最后
作為打不死的產品，我的座右銘：與天斗 、與地斗、 與程序猿斗， 其樂無窮。
千萬不要影響他們的開發，程序猿需要一片凈土。沒有買賣就沒有傷害。
最后，腦容量有限，歡迎各位補充。寫這種文章，我也很慌，有不對之處請多多指教，謝謝！
作者：黃麗嫦，微信公眾號：野生派產品錄
本文由 @黃麗嫦 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
寫的好棒
很干貨，謝謝
小姐姐寫的很好啊，請問這邊是有幾年經驗了。我感覺干了好幾年了 吵架還是吵不過開發啊。
寫的不錯，怎么可以加到作者的微信
新手想問一下：接口定義是由產品來寫嗎？我們公司要求我們產品會寫接口定義。。就是需要多少接口，接口需要入參什么，輸出什么都要寫出來，直接給后端來編寫？
接口入參、出參、使用場景、性能要求，這些是產品來寫的—來自美團
太牛了吧，我們這都是開發寫，產品要會寫必須懂很多開發知識了吧
如獲至寶，謝謝老師
沒有買賣就沒有傷害……笑尿
看一半 對新人很有幫助，謝謝！先收藏。
有收益
厲害啊，小姐姐，能幫我生動的解釋一下code是啥意思么，網上搜到的都太官方。
200是服務器返回的請求狀態碼，比如：500，表示服務器錯誤。你經常見的404，表示頁面找不到的意思。而200，表示請求成功的意思。
非常不錯，比某本書有用多了
文章整理的很用心，可能是因為內容比較多，出現了一個Bug：“打包，就是將自己寫的代碼（Bug）打包成一個文件……”
只是作者的一種調侃罷了
很棒啊，生動形象！
不錯。通俗易懂。
不錯。收藏了
到目前還只接觸到接口，前端后端，重構，組件，寫死，全是排在前面的。。
先mark了，很有用。
本人前端轉產品4個月，真是自愧不如，小姐姐真是很厲害了，膜拜膜拜
反手一個訂閱+轉發
對于我這個學八個月ui設計出來啥也不懂就被逼進產品坑的小小白來說，這篇文章我看到了幾個很親切的字眼。css js token 重構，打包，接口這樣的字眼時，相當親切，看文從不留言，這篇文章我甚是喜歡，同樣是九年義務教育，小姐姐你怎么可以那么有趣還有才，
作為產品狗，看完之后我覺得這下可以去硬剛程序猿了，因為知彼知己
年輕的brother，保持謙虛、學習的心態。這些都還只是基礎，冰山一角呢。
嗯嗯，曉得曉得，謙虛、學習 ??
一口氣看完這篇文章，深深感覺這為小姐姐是一個有趣的人，2333333
你會看到一個菊花轉啊轉啊轉呀。。。233333333 小姐姐你是認真的嗎
菊不菊花的無所謂，主要是轉啊轉啊
別的公司開發不收膝蓋了？
哈哈，感謝，好文啊！先知道有這么回事再說吧，具體還要等業務上遇到了再細細理解
太厲害啦，小白也能看懂一大半，現在正在經歷被各種強勢開發懟的階段，學習！
表白一個，作為無技術基礎的產品這些只停留在概念中，受教了
作為一個后端出身的全干型產品，表示你這技術還不錯啊！程序猿一定搞不過你哈哈哈
受教了