工作中的跨界

來自專欄 木子是前端

讓專業的人做專業的事，一直認為這句話說的沒錯，可是並不代表，不專業就不能做專業的事。隨著互聯網行業的發展，之前可能在創業公司較為常見，不管會不會幹，可能從產品需求，設計圖，前後端，運維等等全都要自己一個人搞。但現在很多職位及工作都被細分，比如前端細分成切圖及邏輯開發，後端細分模版及業務邏輯，或資料庫開發，設計細分網頁及動效開發等。雖然大家都有相同的職位名稱，但所從事的工作卻不相同，這是否有利於自己的發展。

而我所在的公司，部門對職位工作內容細分的可能沒那麼細緻，如果一個人有能力，你完全可以自己開發前後端，跨度較大的工作內容設計，產品確實還需要專業人來出謀劃策，畢竟我自己想的確實和專業人考慮的角度的都不一樣。對於我們組的同事，前端可以寫後端代碼，後端同事寫前端代碼也很清晰。一般一個人拿到需求時，如果你能一個人完成這個需求，那一般都不會再找其他人幫你完成，只是需要在提 pr 的時候，讓前（後）端同事幫你 review 下代碼提些意見就可以了。對於我們前端組的其他同事來說，寫 python 都沒什麼問題，大部分的邏輯處理或是一個項目的搭建都是沒問題的，對於我來說，寫 python 還是有些吃力的，我不能保證這個需求要實現的後端代碼我都可以完成，一般比較複雜的修改我都會找後端同事幫我完成，正因為所處環境，大家都能力很強，所以在自己對於後端稍弱項的時候，必須發力趕上來。其實也是因為，自己能搞定的話，完全可以自己掌握需求進度，不用太受制於別人了。

最近在做一個比較系統的業務，對一個模塊進行修改，其中也涉及到了前後端的多處改動，改後台代碼硬著頭皮就上了，加了幾個 API 和部分字端刪減新增邏輯等。在做的過程中，很多後端知識和 API 返回字端的邏輯含義，我都不是很清楚，向同事問了很多。有時候挺怕打擾同事工作的，但有的問題也沒辦法必須問，但記住別問那些能查到或不自己思考的問題。同事也挺耐心的給我講了很多之所以，是因為。。。我才發現，前端不能只知道拿著 API 返回的字端在模版和前台邏輯上展示就完了，很多核心的後端邏輯，我覺得是很有必要知道的，比如不同情況下，不同參數下，返回的字端的區別？比如某個字端為 true 時，是直接查的資料庫還是根據別的字端邏輯判斷出來的 true ? 這不僅對你寫代碼展示數據有幫助，還對你熟悉業務理解能力也是有幫助的，總是覺得團隊里有些人很厲害，厲害到你說哪塊邏輯他居然都知道。

對於前端如何寫後端代碼，我覺得第一：應該先找機會寫，有機會去嘗試著寫，沒機會自己可以私下讀一讀後端的代碼，等有機會寫的時候還有個準備；第二：有機會寫代碼的話，確實要下功夫學習，你們後端用什麼語言，你就找本基礎書看看，比較基本的內容還是有必要知道的，其實不同語言的相似內容還是很多的；第三：有機會寫了，基礎知識也有了，自己可以時不時創造機會寫，先從邊邊角角寫起，逐步可以寫一塊業務邏輯，在之後寫個大類，或者自己整一套項目。我開始一點不懂，開始就先從加字端改起，從 python view 返回寫起，明白點之後，改改 api 和 models 里的邏輯了，一點點寫就會了，不懂得也需要集中時間問問同事，多和專業人交流，可比你自己搞節省時間多了，但不能不思考，其實我寫後端代碼的能力還是有限的，就更應該不斷練習了。

說了一些工作中遇到的跨界的工作內容，其實如果公司沒有強制要求，很多時候都是有機會允許你跨界的，但記住把自己本職工作做到位後，可以不斷的嘗試體會跨界給你帶來的好處，這確實是受益無窮的。

也許你能在跨界時發掘自己未待發掘的潛能。

推薦閱讀：