中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

剛入門產品，和開發溝通的時候總是被懷疑智商？沒事，本文和你分享一下那些溝（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. 充分的測試?。。?！

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

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.要做小程序開發，你得裝個開發工具，微信提供的；

附上開發地址：
https://developers.weixin.qq.com/miniprogram/dev/devtools/download.html?t=20171227

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

3.接著你就要去學js；

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

十二、寫在最后

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

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

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

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

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

題圖來自 Unsplash ，基于 CC0 協議