閱讀須知
本文不談及老技術（畢竟沒有經歷那個年代，emmm），只談一些個人體會，如果會有部分內容與你想法不同，以你為準，
大學期間對于前端的學習
對于我雙非本科小菜雞來說，最開始入門的語言是 C 語言，之后大二大三就以 Java 語言為主，后面了解了一下其它學校同學學習的課程，好像大部分也是以 Java 為主，不過有的學校會教學一些 Web 前端的課程，這個是挺好的，
我是僅僅大二學了一本 《Web基礎入門指南》書籍（可能書名也不叫這個名字），內容也是比較基礎，學習一些 html 標簽，css 語法也學的很少，
課程快要結束的時候，老師給我們提及了 ajax 以及異步請求相關的概念，逐漸的有了前后端的概念，最后的作業就是完成一個課程設計，也是比較經典的管理系統，要有資料庫連接等等，我們當時做的就是比較經典的「圖書管理系統」了，
大學期間做的專案
大二學習前端的知識不是很多，后面來到了大三，學習了 JavaEE 以及軟體工程的課程，當時這兩門學科老師進行了聯合，要求我們分組完成一個大的課程設計，這個也是作為期末考試的重點比例分數，可以說如果這個專案分數不高的話，兩門都得掛了，
不過平常與大佬接觸蠻多，所以就和大佬們組了隊，其中就有一位小學就學習過編程的同學，對于大學才剛接觸編程的我來說經驗還是有許多差距，
當時軟體工程老師給我們提及了，前端框架可以考慮使用 Vue 或者 React 框架，那時候我最開始接觸這兩個詞，然后組內大佬就開始研究這個框架了，讓我佩服學習能力真的好強，一周內就開始撰寫頁面了，
而后端當時提及的就是 SSM，如果不太熟悉的小組也可以使用 SSH，我們當時就采用了 SSM 框架，并且采用前后端分離的模式開發，
后端也是一位大佬，當時就引入了 Swagger UI
在這里參考官方的介紹：
Swagger UI allows anyone — be it your development team or your end consumers — to visualize and interact with the API’s resources without having any of the implementation logic in place. It’s automatically generated from your OpenAPI (formerly known as Swagger) Specification, with the visual documentation making it easy for back end implementation and client side consumption.
來自谷歌翻譯： Swagger UI 允許任何人——無論是你的開發團隊還是你的最終消費者——在沒有任何實作邏輯的情況下可視化 API 資源并與之互動， 它是根據您的 OpenAPI（以前稱為 Swagger）規范自動生成的，帶有可視化檔案，便于后端實作和客戶端使用，
當時做的效果就是如官方圖片一樣，提供了一種可視化的效果，這樣前端同學就不用這么花費很多溝通上的成本，直接看圖一目了然，
這個當時也是對我的認知有了一些變化，就覺得大佬們真強，對于這個技術廣度感到了不足，給大佬們點贊！
最后我們組確確實實拿到了班級第一名，但是程序中前后端的兩位大佬也出現過溝通問題，也吵過，就差打起來了…
之后，有這段做專案的經歷加上自己也系統學習了前端相關的知識，春招找到了一份實習，接下來就來說說實習作業的真物體驗如何，
一次實習作業的真物體驗
學校時期與大佬們接觸，自己對于技術方面也更加熱愛了，同時接觸的領域也更廣了，比如開始自己去學習 Vue 和 React 框架，
但是帶著學校的思維第一次進入了一家公司實習，當時想的是應該前后端也會按照學校那會的方式來做，而實際情況缺差別有點大，
實習那會，有一批的實習生，我應該算是前端的一個主力了，當時討論的時候就說后端寫好介面檔案，可以考慮使用 Swagger UI（因為上文提及過，我大學期間就有使用過，這個還挺好用的）
不過當我提及 Swagger UI 時，貌似就一位后端同學知道，其它同學好像沒怎么了解，
因為了解的不夠充足，這個 Swagger UI 就放棄考慮了，最開始是沒有一個規范的介面檔案的，告訴我的介面也是比較「簡單」，至于這個介面能不能用我還要自己去請求一下，然后測驗一下？
當時花費了很多的溝通成本，后來由帶我們的組長給后端同學開了一次會議，開始整改規范上的問題，要求寫好一份完整的介面檔案，之后我就輕松許多了，不需要我做的時候還得和介面負責人溝通許久，
不過，后來又出現了問題，雖然檔案的內容是比較詳細了，但是因為介面會比較多，所以每個人可能就會分配一下，負責某個模塊的幾個介面，就在這里出了點小問題，
比如前端取值的話，有些介面是通過 res.data.xxx 就可以獲取 xxx 屬性的值了，原本我以為大家都會用這種規范上來做，但是之后寫其它頁面的時候我發現 res.data 取不到值了，充滿疑惑的我又開始了除錯，在控制臺列印了一下，原來我得需要 res.data.data.xxx 才能獲取那個值，看完之后我哭了呀，
于是乎，我又得找后端同學商量一下了…
作為一起加入的實習同學，出現問題也是很正常，遇到問題去解決問題就好了，
要是脾氣暴躁的前端 er，估計會和后端開懟了，甚至打起來了（開個玩笑哈，一般不會有這種情況的哈，打贏了坐牢，打輸了住院…）
前端與后端的對接
之前有一位小伙伴問我前端與后端對接需要掌握哪些技術堆疊，該怎么對接等等，
首先，是技術堆疊方面，其實對于前端來說，了解一下「RESTful API」就好了，一般后端同學回傳的介面型別和這個設計差不多，可能公司要求會有點差別，
https://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html
在現在主流前后端分離開發模式下，前端同學就負責撰寫界面實作，后端同學提供 API 介面，這樣減少一些溝通成本，
在過去前后端打架的時代，我覺得你寫的介面不行，而你又覺得我寫的頁面太簡單了，覺得我技術一般，然后就打起來了…
咳咳，題外話題外話，至少我是沒有經歷過那個時代，真打沒打起來我還沒實際見過，但是網上見過，見過真實的產品和開發人員對噴的情況，
而至于怎么對接的話，作為前端來說的話，如果后端同學按照公司規范提供介面檔案或者一些可視化的介面，這樣是非常好的，自己也會輕松很多，省去一些溝通的成本，
但實際情況往往與理想狀態還是有點差距，有時候后端同學回傳的介面可能會有一些問題，這也很正常，誰還不經歷個 bug 呢，作為前端的我們來說，不要抱怨，和平交流，
因為這個功能是這位后端同學給你提供介面，說不定之后的一些功能你們還需要合作，因此建立良好的合作關系還是很重要的，
結尾
本篇文章就到此結束啦，的文章可不僅僅只有知識類分享哈，喜歡我的文章可以點點關注，下次我們還能遇見，許久沒有求點贊了，這次能要一個「點贊」嗎，各位大佬們，球球了~
我是「一百個Chocolate」，一位獅子座的程式員，帶著熱情面對生活，好好生活，好好學習，
2021 年還有一個季度，我們一起加油！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/310515.html
標籤：其他
下一篇：程式猿之國慶有空嗎？