產品經理：不得不懂的基礎技術知識

6 人贊了文章

一入產品深似海。身為產品汪，我想說產品汪和程序猿是兩個物種，一個來自金星，一個來自火星，腦結構、腦迴路截然不同，關鍵是他們還健忘！

雖說「人人都是產品經理」，但也造成產品成為整個行業「鄙視鏈」的末端。

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機制中所運用的大量對象的創建和銷毀影響效率。

五、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. 充分的測試！！！！

看似簡單，但是往往都做不到，項目成員對於充分的定義標準都不一樣，產品經理永遠都覺得沒有測試足夠，也不可能百分百的覆蓋率。這個時候，利用自動化測試工具未免不是一個有效途徑。

2. 充分的溝通！！！！

很多需求提出方不理解為什麼要重構，但他們卻要為重構買單，在他們看來往往就像個騙局。

對於新功能的重構，應該融入到正常開發過程中，如何讓上帝理解重構的價值，反思一下遇到的問題：是由於早起技術架構的缺陷，還是業務領域模型變動太大？如何避免今後再次遇到，得到上帝的理解和認可，這至關重要。

3. 充分的思量！！！！

考慮時間成本！人力成本！學習成本！盡量避免大的重構，這樣可以減少多方的工作量，也會減少項目延期的風險。

對於一些核心功能，進行重構之前儘早告知團隊，並重點闡述下重構的周期、目的以及會涉及到的業務區域，這樣做一方面可以讓項目經理合理地安排排期。盡量避免上線前進行重構，因為風險無法預估。

七、調試、打包、部署

啊，不是那個你去店裡點餐，跟老闆說的那個打包！

程序猿做項目的時候，會在本地搭建一個開發環境，用於調試自己的代碼。

程序猿說的碼代碼只有程序猿自己才認識，計算機根本不認識，計算機只認識二進位。

打包，就是將自己寫的代碼（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.要做小程序開發，你得裝個開發工具，微信提供的；

附上開發地址：

2.然後，你需要去微信公眾平台開通個小程序賬號；

3.接著你就要去學js；

微信小程序用js來作為開發語言，用定義的wxml來描述界面，用wxss來表達樣式，這些也是最基本的幾個要素。開發語言不用說，js非常成熟，解析js的引擎也有很多。

十二、寫在最後

作為打不死的產品，我的座右銘：與天斗 、與地斗、 與程序猿斗， 其樂無窮。

千萬不要影響他們的開發，程序猿需要一片凈土。沒有買賣就沒有傷害。

最後，腦容量有限，歡迎各位補充。寫這種文章，我也很慌，有不對之處請多多指教，謝謝！

作者：黃麗嫦，微信公眾號：野生派產品錄

本文由 @黃麗嫦 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基於 CC0 協議

原文鏈接：產品經理：不得不懂的基礎技術知識 | 人人都是產品經理