在互聯(lián)網(wǎng)圈里，有這樣的一群凡爾賽人，他們勤勤懇懇、認認真真的工作，提高自己技能，把本職工作都做的很好，最后低調(diào)的揮一揮手，調(diào)侃笑一笑就過去了，我們一起來看看吧～

01

產(chǎn)品經(jīng)理篇

產(chǎn)品經(jīng)理，和研發(fā)人員溝通真的很難嗎？需求按期上線很難嗎？為什么我每次和研發(fā)人員溝通都很順利呢？這個需求背景是這樣的，我們要實現(xiàn)一個秒殺系統(tǒng)，12月12日00:00分開始搶，商品限量100個，售完即止，在活動開始前把熱銷商品緩存起來，不要讓用戶請求直接訪問后端數(shù)據(jù)庫，用戶請求進來后先進入消息隊列排隊等著，不超過限值就可以被訂單模塊和支付模塊消費處理，清清楚楚，明明白白。在需求拆分成開發(fā)任務時，對于產(chǎn)品頁面描述清楚每個點涉及的元素，前置動作、后置動作，將每一個點都拆分到原子化，研發(fā)人員按照需求工期評估、進行開發(fā)實現(xiàn)，更改需求狀態(tài)，測試人員按照開發(fā)任務的需求進行驗收，對于整個需求從開發(fā)到上線的每個點都了如指掌，我的需求當然能按期上線了。我每天也想加班啊，可是需求都溝通清楚了，研發(fā)能按期開發(fā)完成上線，加班也沒事做。

02

開發(fā)篇

開發(fā)人員，代碼高性能低延遲Bug少真的很難嗎？在需求評審時清楚了解業(yè)務流程的邏輯和功能模塊，在技術架構設計時關注技術架構&調(diào)用關系&技術規(guī)范（使用最流行的分布式架構），在函數(shù)接口實現(xiàn)時關注功能&頁面&模塊之間交互，在運維方面使用Redis緩存緩存熱點數(shù)據(jù)，使用集群模式進行部署，將服務部署在多臺機器上，通過Nginx負載均衡器將不同的用戶請求分發(fā)到不同的后端服務器，在數(shù)據(jù)庫層面使用主庫讀、從庫寫，主從復制模式保障數(shù)據(jù)庫集群高可用。無論是來多大的流量，系統(tǒng)都能低延遲處理任務。我只是想安安靜靜的做一個CRUD（增刪改查）程序員，我也不想月收入5萬還活得像5千，可我懂技術架構、算法設計、數(shù)據(jù)庫、云計算彈性伸縮、互聯(lián)網(wǎng)架構趨勢、前后端交互邏輯、網(wǎng)絡知識、通信知識，核心業(yè)務都交給我負責了，硬生生的活成了全棧工程師，關鍵是我也不怎么加班、發(fā)量還很好，我要繼續(xù)扎根碼龍世界，好好Coding。

03

測試篇

測試人員，產(chǎn)品沒有Bug真的很難嗎？在每次需求評審之前認認真真看產(chǎn)品設計文檔，思考記錄相關問題，在需求評審時從技術角度、前端使用邏輯、后端接口邏輯進行考慮，提出疑問，需求評審完了之后按靜態(tài)測試、動態(tài)測試方法，從邊界值等設計測試用例，準備性能測試方案，在功能提測時進行功能和性能測試，雙面保證，我測試過的功能模塊當然沒有問題了。我也希望自己測試的產(chǎn)品能有些bug啊，可是在寫測試用例、執(zhí)行測試時都覆蓋全了，有bug也很難了。

04

運營篇

運營，DAU翻三倍真的很難嗎？了解用戶特性（年齡、性別、地區(qū)、消費能力、消費偏好），將用戶進行不同的畫像，再結合電商商品特點，寫對應的營銷文案，策劃活動，根據(jù)用戶訪問情況進行埋點，再結合數(shù)據(jù)情況分析出當下方案的不足之處，輸出策略改進，慢慢的DAU就起來了。老板開會總讓我講一些運營心得、增長策略，我覺得很簡單啊，任何一個人只要上點心都可以做好，有什么可講的。

事實上，僅憑一個人的一面之詞是很難了解他生活的真實狀態(tài)、工作的真實模樣，很多你看起來以為很簡單很容易做成的事情，都是別人默默做了很多努力，只有非常努力才能看起來毫不費力。我們互聯(lián)網(wǎng)圈內(nèi)人都是低調(diào)的，從不在深夜凌晨、周末發(fā)朋友圈微博抖音秀自己加班努力工作，只是在有一些成績時調(diào)侃式的秀一波，過一下嘴癮，事后仍舊繼續(xù)乘風破浪，縱情向前，這樣的互聯(lián)網(wǎng)凡爾賽人你喜歡嗎？