前端對產品和工程的思考

身爲前端，不該該只會作網頁。應該時刻對產品保持深入的思考：這個產品的價值是什麼？它是如何帶來收益的？如何更好地知足需求、實現其價值？在這篇文章我將分享一些個人思考，以應用的類型來分類討論。

發佈/展現型

好比論壇、博客平臺、微博、新聞門戶、信息展現平臺（如58同城、大衆點評）。發佈者能夠是管理員、商戶、普通用戶。

業務分析

業務上，產品的目標是促進雙方溝通和互動（好比58同城鏈接買賣雙方、大衆點評鏈接消費者和消費者）。分類、搜索、推薦、SEO對於業務有很重要的做用，產品應該不遺餘力地將用戶引導到最有價值的內容上。

技術分析

服務端主要負責存儲，前端負責展現。先後端的交互相對比較簡單，主要是提交和獲取數據。
在這種應用中，最重要的頁面應該就是首頁、列表頁和詳情頁了。
對於首頁，一個很重要的特性是：不一樣用戶看到的首頁應該是不同的，首頁應該針對具體用戶展現個性化的數據。即便沒有能力用機器學習來作推薦信息流，至少也應該容許用戶選擇本身感興趣的內容、容許用戶將常常訪問的專欄放在首頁，將用戶最快地引導到最有價值的內容。
對於列表頁，應該作好內容分類、過濾、檢索。在這方面能夠學習leetcode：

嚴格來說leetcode不屬於這裏講的發佈/展現型應用，它的主要賣點在於在線評測。不過，好的UI設計理念是通用的。
另外要注意，好的UI設計應該是有本身的風格的，或緊湊務實，或簡潔大方，或特立獨行，考慮用戶羣體和應用的定位之後再作決定。

對於詳情頁，須要具體分析。作好SEO每每有很大的幫助，利用用戶發佈的內容吸引更多的用戶。另外，在主要內容的結尾展現一個」相關推薦「也是一個好主意，引導用戶瀏覽更多的內容。若是對於業務有幫助，能夠考慮加入更多的多媒體形式，好比視頻、圖片、更多的文本格式（富文本）。

這種應用複雜性相對較低，開發人員不會不少，協做成本比較低，所以作好代碼複用是一個基本要求，這有助於最大化開發效率，併爲後續迭代下降工做量。
加載性能對於這種應用也很是重要，前端應該投入更多精力。在性能優化上我會專門寫後續文章，讀者能夠先參考awesome-learning-resources中的資料。
能夠看出，在發佈/展現型應用中，前端要解決的問題主要是代碼上的問題（UI優化、性能優化、代碼複用）。

業務流程在線化

好比淘寶、美團外賣、滴滴打車、企業內部採購平臺。大部分業務流程都是交易流程、事務處理流程。

業務分析

將業務流程搬到線上，其意義包括：

1. 各參與方能夠方便地、流水線式地完成本身的業務部分，減小各參與方的溝通成本和閒等時間。
2. 將流程步驟標準化和清晰化，從而減小失誤和意外。
3. 記錄流程，以便進行追溯和統計分析。

業務流程中涉及到的信息交流應該所有在線完成（好比填寫/審批申請單）。若是業務流程有不可避免的線下操做、系統外部操做（好比收/發快遞），那麼系統也應該接入相關外部服務(好比快遞、銀行)，對這些操做提供記錄和追蹤的功能，保證系統能參與到、影響到業務流程中的每個方面。

技術分析

1. 用戶與系統之間的交互大大增長，先後端交互也大大增長。不一樣的流程有不一樣的交互方式（不過基本都是表單），後臺邏輯甚至更加複雜。業務流程多種多樣，業務邏輯紛繁複雜，而且出現BUG會有相對更加嚴重的後果。所以，質量管理在這種狀況下很是關鍵，測試應該覆蓋到各個業務場景和邏輯。發佈前構建，引入工程鏈的體系，搭建低容錯、自動化的開發流程。使用先後端監控，從而可以儘早發現問題、方便排查故障、爲性能優化提供指標。

2. 整個系統須要不少開發人員來共同完成，分別負責各自的業務流程。而且不一樣的業務流程之間可能須要共享數據、互調接口。這大大增長了開發人員的溝通協做成本。爲了下降它，能夠經過如下手段：

   1. 作好模塊化管理和先後端分層，解耦不一樣層的工做。分層的好處以下：

      1. 將瀑布式的開發流程轉變爲並行開發流程。瀑布式流程：程序員A須要等待程序員B開發完成（從而A能使用B開發的功能），程序員B須要等待程序員C開發完成。並行開發流程：各個負責人在約定好接口之後就能同時開始開發。
      2. 下降單層的複雜度。有利於開發者的關注點分離、面向接口編程。提升系統靈活性、開發效率。
      3. 解耦之後可以對各個層進行單獨的測試、性能監控、異常監控，更加有針對性。解耦之後更新維護也更加容易。
   2. 統一代碼規範和接口規範，以下降接手成本。
   3. 識別出可以被進一步抽象和標準化的邏輯，進行封裝。
   4. 採用微服務架構，有助於解耦業務邏輯、獨立演化。

3. 若是用戶量很大，還會對系統的性能提出更高的要求。根據業務特徵，進行如下優化：

   1. 優化代碼，從而可以更加高效地完成業務計算；
   2. 優化通信開銷，下降不一樣服務之間、先後端之間的通信量和通信時間；
   3. 優化應用架構，提升系統的可擴展性，增長高併發處理能力。

能夠看出，在業務流程在線化這種類型的應用中，開發者要解決的問題主要是人的問題（管理的問題）和系統效率的問題。前端不能侷限於用框架寫頁面，更要從工程師的角度來優化開發流程和系統效率。不只要關注軟件最終的運行結果，更要關注開發流程建設、團隊建設、基礎設施建設、系統架構建設。

委託系統進行某種操做

好比系統控制平臺、運營平臺、leetcode。

業務分析

這種產品的業務邏輯比較簡單。用戶使用它們的目的，主要是委託系統（主要是後端）完成某種操做/計算，這個操做的結果可以知足用戶。
好比用戶經過系統控制平臺來修改其餘系統的配置和行爲。有一些控制平臺還擁有監控的功能，後端會持續收集某個系統個各個指標，前端對這些指標進行可視化展現。
又好比用戶經過使用leetcode，讓後端運行評測，從而檢驗本身答案的正確性（leetcode的主要部分就是發佈/展現平臺+評測系統）。

技術分析

技術上的主要難點在於如何進行模塊劃分，爲其餘開發者、用戶提供簡單的抽象（思惟模型）。

一個好的抽象的例子：一個控制系統用來管理上萬臺機器（節點）的運營。系統將這些節點按照樹狀結構組織起來，就像文件系統同樣：同一個機房的節點用一個文件夾（大節點）組織起來，同一個城市的節點用一個文件夾（大節點）組織起來。而後，提供一幅世界地圖，每一個城市節點在其中標註出來。經過UI或腳本，能夠批量選擇、批量操做節點。

前端上，若是須要展現的數據（操做的結果），還須要將數據充分可視化。提升用戶高效操做（大批量）數據的能力。
後端的技術特色取決於它爲用戶完成什麼樣的操做。後端的API應該提供比較合理的抽象和封裝。

---

注意，這些產品分類不是互斥的，有可能一個產品在某個功能上像A，在另外一個功能上像B。咱們應該學會分析產品的方法，而不是套用現有案例。

你的產品是什麼樣的？這個產品的價值是什麼？它是如何更好地知足用戶需求、實現其價值的？歡迎與我分享！

相關閱讀

阿里9年，我總結的前端架構演進3大階段及團隊管理心法