為什么要了解客戶端的架構知識？除了盡量避免不被工程師罵笨蛋之外，也是在設計之初就可以往長遠考慮。

市面上關于產品經理的書，基本是都是入門書。之前我一直在想，為什么沒有產品經理進階的書籍？

過了一段時間之后，我感覺有了答案：其實產品經理進階的書早就有了，只是沒有一個產品經理進階的tag。

這些書，可能是營銷的書，可能是項目管理的書， 可能是心理學的書，可能是統計的書，可能是設計的書，可能是架構的書，可能是算法的書?？偠灾?，需要廣泛的涉獵。

當然，這些書里面也有優先級，不同的人，需要根據自己的工作需要，去調整自己的閱讀的優先級。如果說的更直白一些：工作中，你最不想被誰罵笨蛋，那就看對方領域的書。

言歸正傳，這一章節會匯總一些客戶端基礎架構的知識，同時也會舉個具體的設計實例。

1. 客戶端的架構

客戶端頁面被訪問的時候，一些非固定的元素，需要去請求API。

客戶端的數據可能來自各個業務線，API請求各個業務線的接口，并組織成APP需要的格式返回給API。

對于業務線的服務端而言，它的數據也來自于基礎數據庫，也需要根據基礎數據庫的變化進行更新。

2. 舉個例子

我的專欄在客戶端頁面的展現：

最頂部：返回按鈕，標題欄，操作按鈕；頭部：logo，專欄名稱，專欄關注人數；底部：文字卡片流。

而卡片流包括：頭像，昵稱，文章圖片，文章標題，文章導語部分，文章贊同數量，文章評論數量，文章發布時間。

可能請求了兩個接口：第一個API接口，專欄基本信息的接口。第二個API接口，卡片流接口。

在文章基本信息的API接口里，需要返回標題，logo，關注人數。而API會請求對應的服務接口，這個服務接口可能是個通用接口，有更多專欄的基礎信息，比如有專欄擁有者的昵稱和頭像。而API則根據客戶端的應用場景進行處理。

在卡片流的API接口里，需要返回頭像，昵稱，文章圖片，文章標題，文章導語部分，文章贊同數量，文章評論數量，文章發布時間。同樣的，可能請求的接口中數據更多，而請求到的時間則是UNIX時間，需要處理成客戶端需要的時間格式。

同時，服務端的數據在基礎數據有更新的時候也會根據一定規則進行更新。

3. 基礎設計實例

當我們了解了基礎原理了之后，在做產品設計的時候就可以考慮的更長遠一些：比如，擴展性。簡單來說，對于客戶端而言，盡可能不要做太多邏輯處理，而是只展示API給的數據。如下圖，客戶端只負責劃定顯示區域，不做任何文字的展現，這樣對于擴展性更好。

比如：如果想在展示贊、評論，時間的展示欄，需求調整，希望增加收藏數的顯示，則這種顯示邏輯下，直接在API增加收藏數的顯示即可。而如果客戶端處理為：X贊·X評論·X天前（贊，評論，天前為客戶端寫死），則修改時間格式或者增加收藏數的顯示，就需要發版本。

4. 結語

為什么要了解客戶端的架構知識？除了盡量避免不被工程師罵笨蛋之外，也是在設計之初就可以往長遠考慮。很多時候熟悉業務的產品經理更能前瞻性的預測到功能的后續發展方向，可以提前做好前瞻性設計；可以和研發共同討論，避免實現方式過于死板，后續的一些突發的運營功能擴展需要發版解決；也可以避免研發在缺少對需要發展了解的基礎上，做出不必要的冗余設計來猜測未來的需求。

最后要說的是，懂一些基礎的技術知識，來避免被罵笨蛋其實作用比較有限。畢竟程序員罵產品經理，大多數情況句式是：“這個笨蛋又改需求”，而不是“這個笨蛋一點技術都不懂”。

作者：潘一鳴，知乎專欄：產品邏輯之美

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