隨着本身正式學前端已經剛剛一年了,一直對本身沒有個正式的交代,在這個階段裏感受本身學到了不少東西,可是同時又有許許多多的不足,今日,寫下這篇文章,爲了審視本身的不足,以及鞭策本身前進。前端
恰好,今天也是實習入職3個月了,正遇上部門的績效考覈,總結老大對個人評價以及本身對本身的評價。react
從4月15日入職到今天,已經三個月了,進創宇也算是運氣好吧,面試的時候,問到個人恰好是我比較瞭解的和擅長的,加上我本身也是一直在學校裏探索先後端分離的模式,因而在這條路上了解的稍微多一些, 所以就順利的入職了。es6
一開始,本身對react技術棧一點兒都不熟悉,只是用react
寫過todolist而已,可是入職次日,就讓我接手一個項目,剛開始熟悉項目的時候,真的是把我壓得喘不過氣來,由於項目裏使用的技術太多了。。es6, react, redux, react-router, hapi.js, eslint
等等,還有其餘的一些庫,好比lodash和immutable等等,然而我只用react寫過todolist, es6也只是瞭解let const
,那幾天,真的是有種特別難受的感受。特別是eslint,配環境的時候,直接全是紅的,那一瞬間,心裏跌入谷底。面試
過了幾天,感受實在是不行了,就和mentor交流了一下,原來他覺得我進來就是能夠直接上手項目的,他不太瞭解個人真實狀況,因此就讓我直接上手項目了,溝通了一下,仍是給我半個月的時間讓我熟悉公司技術棧。redux
完成最開始的一個資源日曆後,就開始維護各類項目的新的需求和bug了,到目前爲之,我也主要是在維護項目。可是隨着本身這段時間的成長,逐漸發現了本身身上的一些壞毛病,特別明顯的幾個就是工做效率不高,遇到問題愛問, 一旦本身想不出來方法,就想着找別人了。後端
我本身總結了下爲何個人工做效率不高,緣由有下面幾個:api
第一個,不太容易集中精神,一旦完成了一個需求後就對本身放鬆了。這真的很差,由於它是這麼一個過程,就是從"非溫馨區" 跨入到 "溫馨區"的過程,一旦跨到溫馨區,我就喜歡上了這種感受,這致使個人效率不高。解決這個問題的方法就是,不斷讓本身進入本身的非溫馨區,不要呆在溫馨區裏。react-router
第二個,遇到問題受堵,由於本身主要是維護項目,因此常常會作兩件事: 1. 看文檔, 2. 定位代碼。然而,每每項目中有的文檔說明的不是很明確,並且接手的項目語言可能以前我都沒有寫過demo,這個時候,我常常死磕,怎麼死磕呢,一直去嘗試文檔裏的不太明確或者說是不完整的命令去嘗試,而結果通常都是錯的。第二,就是因爲項目比較複雜,並且有的模塊抽的比較厲害,致使耦合度比較高,本身的實力不能立刻看懂。而本身在遇到這兩種狀況的時候, 本身容易急躁,不能靜下心來,這也就致使本身的效率底下,經常困在一個問題裏不少時間。前後端分離
我相信,本身找到了問題的根本所在,我給本身的解決辦法就是靜下心來,仔細思考,沒有其餘辦法,就是靜下心來思考,腦殼不要一根筋,不要認爲平時本身的思惟就必定是正確的,這一點十分重要,由於一旦認爲本身是對的,那麼就走不出來了。就會去找到底哪兒出錯了,然而本身自己就是錯的。辦法:追尋問題的本質,不要急躁,靜下心來,這個時候也伺機學習一把,學習一下新的技術。學習
第三個,其實我前面已經提到了,就是本身遇到問題一解決不了,就想着去問別人。然而,這依然會下降我本身的工做效率,同時,也會下降別人的工做效率。我給本身準備了下面幾個步驟當我遇到問題的時候:
目前的我,也只有這麼幾個簡單的步驟。未來,我會將它細化。
有的時候,在完成一個需求後,連本身對本身的bug信心都不是很大,由於沒有通過充分的測試。本身在本地隨便測一測,而後放到測試服隨便點一點,而後就上線了,哦嚯,結果,一上線,才發現有問題。
mentor對我說過,要對本身的代碼負責,review的時候只能review代碼的質量,不能測出bug和缺陷。然而本身對本身的寫出的代碼信心都不大,那還敢上線?因此啊,在完成某個需求後,本身必定要充分的測試,尤爲是那種耦合度比較高的模塊,由於這個時候,你纔會發現,真的是改了一行代碼,不少地方都被動了。
最後,提醒本身,遇到bug或者發現缺陷,必定要本身迎面去解決,而不是本身怕麻煩,怕事而偷偷的去避免掉它,這是很不男人的作法。
忽然想起知乎上的一個段子: 一我的頂10我的是種什麼樣的體驗,我一我的寫的bug能抵上10我的的bug。哈哈哈哈哈哈哈。
本身還有一個缺點,就是懼怕難的需求。爲何這麼說呢?本身會的語言也就那麼幾個,可是每一個維護項目所使用的技術都有區別,或大或小, 本身不太熟悉,也估不了時間。可是客戶那邊又要求什麼何時必須上線之類的。
本身必定要克服掉這點,這是本身的一個很是致命的缺點,它阻礙了我進步,我明明能夠乘作這個需求的機會,好好的瞭解或者熟悉一下這門語言的特性或者說是這類的需求技術上的難點和坑。說白了,本身喜歡"溫馨區", 不喜歡"非溫馨區"。告訴本身,跳出"溫馨區", 這很重要,它令人進步。