本文在知乎專欄首發前端
作爲一名苦逼前端碼農,寫給一塊兒奮戰的產品經理們。java
最近的聊天中產品經理說:「我不懂技術,因此當初也判斷很差這個頁面在技術實現上有多複雜」。因而想起來有好幾回:bootstrap
有好幾回,在產品經理眼裏很簡單的需求,可最後出來的技術方案很是複雜,開發工做量特別大,致使整個項目不得不從新評估。瀏覽器
有好幾回,朋友問我能不能給他作個小遊戲,很簡單的網頁小遊戲哦,像QQ農場那樣的。服務器
有時候在想有沒有一種簡單的方法,讓不懂技術的人能判斷一個頁面的前端複雜度,因而有了這篇文章。但願能讓前端碼農和產品經理能更好的互相理解,合做如絲般順滑。前端工程師
下文總結三個基本原則,用這三個原則能夠大體判斷一個頁面前端複雜度。架構
注意:組件化
本文只適用於輔助產品經理理解頁面複雜度,不能代替前端工程師評估工做量,每一個網站的業務模型、架構設計都不同,開發起來也大不相同。佈局
本文只適用於理解前端開發複雜度,不包含服務端開發。網站
先看以下兩個頁面:
左邊的頁面內容豐富、樣式多樣。內容包含頁頭、導航欄、tab標籤、文章列表,每篇文章又包含回答計數、做者、最新回答時間、標題、標籤,佈局上有各類排列方式,還有各類色彩。
右邊的頁面看起來只有簡單的3個輸入框、2個勾選框、2個按鈕,頁面內容總體看起來並不豐富。
左邊的頁面看起來比右邊的頁面複雜,但實際上開發起來右邊的頁面複雜得多。左邊的頁面能夠稱之爲「純展現型頁面」,這類頁面的顯著共同點是隻有數據的展現而不能與用戶發生交互。右邊的頁面稱之爲「富交互型頁面」,經常包含如下交互元素:
輸入框、按鈕
單選、多選、下拉選擇
展開、收起
Tab切換
分頁、滾動加載
彈窗
對純展現型頁面來講,工程師只須要處理好頁面的樣式就好,不用考慮太多其餘問題。另外,這個頁面的文章列表部分,雖然內容不少,但其實是相同結構的不斷重複,在工程師眼裏以下圖所示:
工程師只須要把這個結構的模板寫好,再填入不一樣的數據。常見的純展現型頁面能夠有圖片、表格、文字,以及這些元素的各類混合排列。
對富交互型頁面來講,工程師不只要寫好頁面樣式,更重要的是處理用戶的交互邏輯。交互邏輯比純展現邏輯複雜得多,好比輸入框獲取光標時如何響應、失去光標時如何響應、用戶輸入特殊字符如何處理、用戶鼠標點擊如何處理,還有些頁面內容是須要根據用戶的操做從服務器端查詢實時數據展現出來的。其二,看起來差很少的兩個按鈕或者兩個輸入框,包含的邏輯卻徹底不一樣,好比用戶名輸入框和手機號輸入框
用戶名:6-20字符、英文字母和數字、不能和其餘用戶重名
手機號:11個字符、只容許數字、通常以"1"開頭
儘管交互元素看起來樣子都差很少,但實際上每一個元素背後的隱含邏輯都不同,開發成本也就大不少。一個頁面中包含的交互元素越多,則頁面開發越複雜。
每一個網站都會有一些重複出現的元素,好比日期選擇、上傳圖片、彈窗、Toast提示等等,爲了最大化的複用這些相同功能的代碼,提升開發效率,大多數開發團隊會建設一個組件庫,裏面包含各類經常使用組件,業界比較著名的組件庫有 bootstrap 和 ant design。有了這些組件,工程師開發頁面就像搭積木同樣簡單,把這些組件拼湊在一塊兒,再加上適當的業務邏輯代碼,就能夠開發出一個頁面。
產品經理應該適當瞭解大家開發團隊的組件化現狀,若是基於這些組件設計頁面,那對工程師來講會減小不少工做量。若是能從產品的角度對組件庫提出改進建議,既能讓工程師們從中受益,也能更好的支持產品開發,達到共贏。相反,若是產品形態和交互行爲始終處於變化之中,那工程師也很難沉澱出一套適用的組件庫,開發效率也大打折扣。
要求兼容 IE 8 及如下瀏覽器的頁面,複雜度增長10000000000000000倍。
因爲主題是「頁面複雜度」,應該是頁面自己的屬性而與開發者無關,因此沒有列入三大原則之中。但若是迴歸到現實需求中,開發者實在是沒法繞開的一個關鍵因素。
一、 開發者綜合素質。除了技術實力以外,還有溝通能力、需求理解能力、責任心等,這些你們工做中已經有不少感觸,就再也不贅述。
二、 開發者對業務的熟悉程度。這一點尤其重要,也是容易忽視的一點。有時候會出現這樣的狀況,一樣的一個需求,小A只須要1天搞定,小B則須要三、4天,頗有多是由於小A一直是這塊業務的開發者,而小B剛剛接手這塊業務。因爲代碼自己的強邏輯性特徵,哪怕同一個開發者去讀本身三個月前寫的代碼,即便是最簡單的一段幾百行的代碼,也頗有可能不太記得其中的邏輯。對接手新業務的開發者來講,要讀懂前人的幾千行甚至是上萬行代碼絕對是很是艱鉅的任務,會須要更多的時間和精力。
最後分享一個小故事,在上家公司合做過一位產品經理,有一次咱們週末有事找他,他說他沒空,報了java培訓班,要上課去了。。。要上課去了。。。要上課去了。。。快要被搶了飯碗的感受。