我與前端有場約會🌟 ｜ 工做一週年經驗總結

你們好，我是寒草😈，一隻草系碼猿🐒。間歇性熱血🔥，持續性沙雕🌟。
若是喜歡個人文章，能夠關注➕點贊，與我一同成長吧～

「本文已參與好文召集令活動，點擊查看：後端、大前端雙賽道投稿，2萬元獎池等你挑戰！」

時間如白駒過隙，回首時已一個春夏秋冬

此文分享一個普普統統的程序員的心路歷程和一點經驗，做爲工做一年的記念做品

你們好，我是寒草，我是一名在北京已經工做一年的程序猿，我在咱們祖國的首都已經度過了一個完整的春夏秋冬，小時候沒去過什麼外地，一直憧憬着來到北上廣去奮鬥去闖蕩一番本身的天地。

可是真正的來到北京，咱們大多數人所經歷的並非那樣中二熱血的激情歲月，而也是會經歷煩惱，壓力。可是經歷會讓人成長，我在北京，我在這裏經歷，我在這裏成長，我在這裏經歷普通平凡而又不同凡響的一天又一天。我來到這裏是去年的7月23日，到今天已經完整的一年，這一年裏我：

夏日走過朝陽公園的湖畔

秋天滿眼都是藍天白雲

冬天漫步在華燈璀璨的街道

春天看到玉淵潭的櫻花落英繽紛

又於夏天經歷着一次次雷雨突襲

我做爲一個前端從業者已經走過完整的一年，有不少經驗與故事想與各位讀者分享，在此獻給你們，獻給風華正茂的大家。

因此，接下來讓咱們進入
真正的篇章

寒草呈獻

我與前端的故事，送給迷茫的你

本文做爲個人工做一週年經驗總結，做爲前端從業者，我先講講我與前端的故事。

我知道我並不算是一個傑出的前端工程師，將來會不會是我不知道，可是如今的我還差的很遠，可是僅僅做爲一個普通的前端從業者，我也已經與前端有過一段不長不短的故事了。

我記得是大一那年，咱們學校有一個免費的活動，就是能夠跟着學習產品或者前端，固然白嫖誰不喜歡，我就選擇了前端，跟着上了一段時間，那也算是我前端啓蒙了，固然在那裏我只是知道了簡單的html，css知識。

沒錯！就是隻有html和css知識，當時我和個人小夥伴一塊兒參加的，你們一塊兒用html，css寫了一個靜態頁面，當時最快樂的事情就是和別人說，你看這是咱們寫的頁面，你看這交互，順滑不順滑，你看這頁面風格，biu 不 beautiful！我想這可能就是影響我最後作了前端的初衷。交互的美由咱們親手實現是多麼美好的事情。

其實我也和不少前端聊過這件事情，也有不少前端工程師問過我爲何選擇前端，我一直會統一個人回答：

「創造美好的東西頗有成就感」

我相信也有不少人選擇前端也是這樣的緣由，由於它讓咱們體驗過成就感，雖然我相信作遊戲，作動畫給個人成就感或許會更大hhh，誰還不是一個熱愛遊戲的少年呢。

固然這個也是我會積極參與咱們commi-ui的緣由,我要繼續創造美好的東西。

可是不少東西會變的，當時工做半年有一場答辯，leader問我你爲何作前端，我回答依舊是那樣，可是接下來的問題我傻了：

「但是我們如今作的頁面都是一堆表格表單之類的，沒啥美感的時候你的目標又會是什麼呢？」

我當時沒有答上來，由於這就像是降維打擊，個人世界觀一會兒變了，你們可能不知道我在哪工做，我在某個安全行業的頭部企業，hhh，有沒有猜到的🐶。不扯皮，我繼續說，我當時就感受一會兒有點懵逼，對哈，我如今作的事情和個人初衷感受不太同樣了。這個問題，我也思考了好久呢，看上去甚至是一個影響我從業思想的問題，可是我如今大概想明白了一點：

不管是如今開始寫文章也好，仍是寫一些開源項目也好，我想給這個行業帶來更多創造性的東西，咱們參與一個行業以後咱們可能會感受它並非咱們想的那樣，可是咱們會有更多值得咱們去作的事情。

不是簡單的機械勞做
而是
我從前端開始
我在前端創造

我把真實想法留在了這裏，但願有人願意與我進行思想的碰撞。

走過半載春夏，寫做的心路旅程

我開始發文章已經半年出頭了，雖然我如今確定是仍是一個沒啥熱度的做者，可是其實寫着寫着發現，我本身真的感受到收穫不少，不管是爲了寫出更加精彩的內容而去靜心學習的經歷，仍是由於寫文章認識了不少頗有趣的朋友。

其實我寫文章的初衷多是以爲在外工做須要一些認同感，因此你們每一次點贊或者評論我都會開心，因此期待你們的點贊 👍 和關注 ➕ 哦，哈哈哈。不只如此，也是但願經過寫文章認識更多的志同道合的同伴，有一塊兒努力的朋友真的很重要。

我反正是推薦每一個從業者都去寫點東西，目的能夠不是讓更多人看到（我不是這樣哦，我仍是但願更多人看到，只是人家不來看罷了嘿嘿嘿），我在這裏說一下我以爲寫文章作記錄的好處吧，從我這半年的體驗出發哈：

• 別人的點贊真的是學習的正反饋，會學習更有積極性的
• 學會整理總結，有助於提高本身
• 能夠認識一些志同道合的夥伴
• 鍛鍊寫做能力，雖然我如今文筆也普普統統，可是確實是進步了哈哈哈
• 固然或許有的大佬真的會打造出屬於本身的技術影響力
• ...

話說我曾經表示過，我很喜歡食夢者這部漫畫做品，我以爲純粹的愛和夢想都是美好的。我也想讓個人職業生涯更加純粹一些，因此呢：

純粹的職業生涯，從分享寫做開始吧～

奔赴一年輪迴，個人經驗之談

此處僅僅表明個人我的觀點。

工做中如何交流

簡潔，明確，直白，省去沒必要要的環節，該懟就懟，該說就說。

我剛開始工做的時候，真的感受你們都是大佬，就我一個小菜雞🐔，不少東西都不敢提，不敢說，怕被笑話，怕被批評。其實這是不對的，不要服務端說啥是啥（固然若是你是服務端或是別的也能夠變成不要前端說啥是啥hhh），不要產品說啥就是啥，你們一塊兒工做，有着一致的目標，即便你是萌新，你也有發表想法的權利。

勇於表達會讓你在工做中得到更大的主動權。

忽然同時有好幾個事情要作怎麼處理

有個東西叫作緊急性重要性四象限，你們能夠了解一下，並以統一的維度確立本身的處事風格，我在此表達一下個人理解：

首先，咱們明確知道一個點，人能夠併發處理問題，而不是並行，遇到不少要解決的事，咱們仍是要一個一個作的。以後，咱們按照事情的緊急程度和重要程度進行排列，通常狀況下，緊急程度更加值得關注，咱們優先按照緊急程度由高到低去處理問題，同等緊急的事情再去根據重要性和耗時長短去考量事件的優先級。若是事情都不太緊急，再去按照重要性去安排任務。

並且，我眼裏，一旦開啓一件事情，除非發生難以我的推進的阻塞性問題，或者極其緊急的事情須要處理，就儘可能不要中途切換到別的任務。由於事件的切換是須要時間的。

如何解決參會者時間衝突問題

這個事情是我有個小夥伴曾經由於邀會問題被訓斥了，我思考思考，整理了一下個人想法。

首先，參會者是有優先級的，咱們先要去搞清楚，哪些人是必須參會的，哪些人是能夠不參加的，以後咱們再去優先安排對會議內容更關鍵的角色的時間，較不重要的參會人能夠經過其餘方式瞭解會議結論，好比會議紀要或者討論內容的相關文檔更新記錄。

若是工做遇到問題超出本身認知範疇怎麼辦

做爲萌新的咱們確定會遇到一些超出本身認知的問題，這種時候其實也是須要一個處理問題的準則。

說白了，這仍是個時間問題，我認爲，優先解決問題，若是能夠快速Google到解決方案，就直接本身解決掉，並記錄問題【最好本身有一個markdown】。若是不能，優先去問身邊的有經驗者或者技術大佬（若是他有時間並願意搭理你的話），不要把較長工做時間浪費在探索問題緣由這件事情上，我眼裏這個時間我會控制在一小時，固然若是任務少，我就死磕，任務重時間緊的時候，我看一看就直接暴露，快速找人解決。反正根據任務量，工做緊張程度，去本身衡量一個閾值。留給本身去探索解決問題時間的閾值。
可是，最後，咱們必定要記錄問題！並儘可能本週事，本週畢，不要留尾巴，把問題弄清楚，搞明白，這也是提高的過程。

需求混亂，理解困難怎麼辦

你們是否是都經歷過這樣的狀況，項目進展比較混亂，需求沒有理順就開始開發了，或者說剛剛接手一個項目，你壓根就不瞭解需求，結果上來就對需求，有不少不懂的，一臉懵逼。

反正我有過，產品壓根講不清楚需求，或者說他對一些細節尚未肯定的答案呢，這一期需求就開始了，這樣你們全部人都不去主動的推進需求明確的話，是很危險的！

當時咱們開始你們都沒有弄清楚需求就毛毛躁躁的開始了，問服務端他一臉懵逼，問測試她也一臉懵逼，問產品還幾乎是一天一個答案變着花的改來改去。

因而我當時直接拉着服務端和測試來着對了兩三天的需求，寫了不少不少的文檔和圖例，最後進入了穩定的開發環節，最後我眼裏咱們這個前期極度混亂的模塊完成度和質量也是超於預期的。

有過這樣的經歷，我有幾點經驗分享給你們，可是是一家之言，不必定正確：

• 若是對於一件事沒有人主動，不如你主動去推進

相信我，在你們都混亂的時候，你主動出擊，你們都會更加的信任你，你會更加的主動，更加的有決策力。

• 去作（最）瞭解需求的人

或許不少前端都以爲，服務端給我啥，我渲染啥，對於需求的瞭解不是那麼重要，可是其實完成任務和把一件事情作好是有區別的，當你瞭解需求，你能夠去作到更好的優化和編碼，也有助於你增長業務深度。

• 大膽說話

有想法就說出來，不瞭解就問出來。憋着不會讓你成長，怯懦會丟失機會。問了個很拙略的問題大不了被嘲笑幾句，被陰陽怪氣幾句，然而我認識的大多數人仍是很儒雅隨和的哈哈哈。

計算機基礎，到底要不要學

若是瞭解個人朋友確定知道，我最近寫的技術文基本都是和計算機基礎相關的

前端學編譯原理（一）：編譯引論
草系前端手摸手帶你實現正則引擎，點燃夏日最熱情的煙火🔥

不是由於我自視甚高仍是什麼的，我其實計算機基礎並很差，也是一邊學習一邊給你們分享，就是由於我以爲這些東西頗有必要。

咱們做爲計算機行業從業者，雖然可能你們以爲編譯原理，計算機組成原理，操做系統，計算機網絡，算法導論什麼的離咱們很遙遠，可是其實否則，其實都已經融入到咱們工做接觸的東西的方方面面了。

這裏我不展開來講，我先說我推薦先去學的，或者說是至少要去學的兩門科目。

• 算法
• 數據結構

有個說法是：

程序 = 算法 + 數據結構

算法和數據結構能夠說是咱們平常工做解決問題離不開的東西，說白了吃飯的傢伙。怎麼形容呢，我這裏的比喻恰不恰當：

咱們若是要複用某些能力，可能會把這些能力抽象出來和視圖層作解藕。那算法和數據結構就是咱們做爲計算機從業者能夠脫離出編程語言能夠複用的解決問題的能力。

整潔編碼，是工程師的職業素養

我自認爲我並非一個編碼習慣多麼多麼好的人，可是我會想盡力去把個人代碼都去作到儘量的整潔，由於咱們要知道一件事，編碼是協同工做的過程，也是人與人的交流，不是一我的悶着幹，代碼不只會被執行，也會被閱讀。

我眼裏，入行的第一件事情就是創建良好的編碼習慣，保證編碼質量是工程師應具有的職業素養，畢竟人人都不想每天讀屎山同樣的代碼，己所不欲，勿施於人，先從本身開始吧。

關於老代碼，個人慘痛經歷

其實最開始，我對編碼可讀性沒什麼感受的，可是我剛剛工做接手的項目，簡直就是屎山⛰️，你們想象一下，一個剛剛入職的程序員，其實一張白紙，其實會的東西可能很多，畢竟面經看了一大堆，文檔看了一遍又一遍，可是可能實踐經歷大部分人應該仍是很匱乏的，一個老手遇到噁心的代碼可能都要抖一抖，當這樣一個萌新看到了確定更加一臉懵逼。

因而我也經歷了一段痛苦的經歷，讀代碼讀的反胃🤢的經歷，這樣的痛苦做爲一個新生代工程師確定不能讓他重如今個人後來者身上的，因而我便開始了個人探索之路，併發誓：

個人代碼要作到的基本點是易於閱讀的，是整潔的。

很容易作到並提高巨大的點

我說了那麼多廢話，不說如何提高就仍是沒啥意義，代碼中變量和函數佔據了很大的比重，我在這裏就簡單的介紹一下如何在命名和函數上提高編碼整潔度，參考《代碼整潔之道》，本章後面還會進行書籍推薦環境🌟。

有意義的命名

• 全部的命名都要有實際意義，命名會告訴你它爲何存在，它作什麼事情，應該怎麼用。
• 避免引發誤導，變量方法名和實際意義不符
• 作有意義的區分，array1和array2這樣的名字你告訴我有啥區別
• 使用讀的出來的名稱，真的頗有效，編程是社交活動，名字要讀的出來！
• 使用能夠搜索的名稱，難以搜索的名字會讓你難以定位變量或者方法調用等
• 程序中有意義的數字或者字符串應該用常量進行替換
• 類名和對象名應爲名詞或名詞詞組，方法名應爲動詞或動詞詞組
• 每一個概念對應一個詞，你能夠創建一個術語表參考，要作到統一一致

函數

• 短小：20封頂最佳
• 函數要只作一件事
• 函數參數儘可能少
• 使用具備描述性的函數名
• 標識參數醜陋不堪，向函數傳遞布爾值作法並不推薦
• 函數名是動詞，參數是名詞，並保證順序
• 無反作用，方法不要作方法名語義外的事情

書籍推薦

優秀的編碼一般具備必定的特性，咱們想要編碼更加優雅，初期必定是須要必定的準則，而準則能夠經過專業的書籍獲取。

我曾經專門出過一篇文章，裏面講了個人編碼經歷和書籍推薦：關於整潔代碼與重構的摸爬滾打
其實就是如下幾本書：

1. 代碼整潔之道
2. 重構：改善既有代碼設計
3. 代碼大全2

這我列出的順序，就是閱讀這幾本書籍的順序。由於代碼大全2真的是比較難讀。

tip: 我那篇文章真的質量不錯，推薦你們去看一下，對這幾本書都有一些本身的解讀和介紹

關於整潔編碼，有幾句話要說

1. 當你負責一塊的代碼時，必定要保證你離開的時候比你剛接手的時候更加整潔，即：營地法則
2. 即便無人監督review，你也要認真思考編碼，這樣會成長的更加快速，尤爲是剛剛開始工做的程序員
3. 有註釋不是你能夠寫垃圾代碼的藉口
4. 開發以前，先進行重構，以讓老代碼更好的支持你將來的編碼
5. 傻瓜都能寫出計算機能夠理解的代碼。惟有能寫出人類容易理解的代碼的，纔是優秀的程序員。

...

最後送你們一句話：
人自省以明理，代碼自省以強健。

一週年了，我與前端有場約會

關於將來，無需多言。關於如今，元氣滿滿

這是個人記念文💎，通常我都會在這裏展望這展望那🌟，可是其實關於將來的事情，暫時就交給將來，我只是知道如今的我還會元氣滿滿🔥。

我可能前端的基礎還不紮實，計算機基礎也仍是停留在表面，可是我會繼續在這裏和你們分享，和你們一塊兒學習，在這裏記錄個人成長，個人故事。

寒草小兄弟，工做一週年快樂鴨🦆
繼續元氣滿滿哦

聽着歌，望着天，騎向火紅的雲

寫這篇文章的時候是 2021-07-22 ，下過一場雨，北京的夕陽格外好看，我騎着車，望着天空，聽着歌。

願你們的將來都紅彤彤的～

我是會陪伴你們一塊兒成長的寒草🍄，一個工做一週年的草系碼猿🌳
若是你們喜歡個人文章，歡迎點贊 👍 關注 ➕ ，我會更新更多精彩內容

咱們下一篇文章再見