前端小菜鳥的感慨

初入社會，我只是一個前端路上飛行的菜鳥，經過一段時間的工作之後，才知道，我踩了無數的坑。。。希望，看過我寫的文章的同胞們，不要再和我犯同樣的錯誤。（純屬個人思考）

1. 當負責項目中一個模塊的開發時，不要忘記，它只是項目中的一個模塊。

當我拿到項目經理安排好的工作計劃書時，開始對自己負責的部分的需求進行熟悉，這時的我選擇按照需求文檔進行開發了。沒錯，這正是我開始接觸項目時的表現，完全沒有意識到，它只是項目中的一個模塊，等到後來開發完成後，才發現自己負責的模塊其實與其他模塊一環扣一環，相互有著不同的影響，於是，開始了改bug的漫長之路......

後來才慢慢意識到，系統系統，環環相扣才叫一個系統，我們不能只熟悉自己負責的模塊的業務流程，應該著眼於項目的大局，熟悉整個項目的核心流程，數據的來源與去向，系統許可權控制帶來的影響等等。

2. 問問題之前首先自己思考、查閱，不要輕易問需求

不懂就問，這是好的，沒錯。但是，不懂就盲目的問，這就有問題了，如果對一項業務的流程或者頁面展現方式不夠清楚，你會選擇怎麼做？曾經，當我遇到這個問題的時候，我在簡單的思考之後選擇了去問產品需求，希望得到確切的答案。這樣做感覺上是沒錯的，但實際上，我忽略了一個問題，包羅萬象的網路。後來，我才意識到，我應該先認真分析需求，分析業務路程，思考過後，如果不懂，再上網去查一查，不到最後，不要輕易問需求。

3. 反思頁面功能如此實現的原因，盡量優化顯示

一個系統，或是一個網站，我們都應該記住：頁面才能直觀的體現一切！！！ 不管後台怎麼運作，不管數據如何流轉，與用戶交互的，永遠是頁面。所以，我們不能只照搬需求上的頁面布局，數據顯示方式，也應該思考思考，需求為何要這樣顯示，這樣顯示好處在哪裡，有沒有更好的顯示方式，只有在思考之後，不斷優化顯示，才能寫好頁面，給用戶一個好的體驗度。

4. 改bug時，注意bug的牽連性，避免蹺蹺板現象

我不知道其他人在剛進入工作的時候，有沒有遇到過這種現象，改完一個bug，發現這個bug修改後，導致另外一個bug的出現，這種bug的蹺蹺板現象，我遇到了。後來，我的處理方式是，改完這個頁面的其中一個bug， 隨即對整個頁面進行一次全面的測試，以此來避免這些現象。或者，很多人會有更好的處理方式，但對於還屬於菜鳥的我來說，這是我最簡單粗暴的處理方式 了。

5. 注意提交測試頁面前首先自己反覆測試，無誤後提交測試(前端)。

我參與的項目，都是由前端來進行功能集成，然後提交測試的。在這個過程中，要小心了，之前說過了，頁面才能直觀體現一切，所以，測試測出bug，一般情況下，都是會歸於頁面問題，前端人員就會有很多的bug了。也許不同的公司會有不同的處理方式，但我遇到的便是這樣。在經過一段時間的工作之後，我深刻意識到，在將頁面提交測試之前，一定要反覆測試頁面是否有bug,數據展現、頁面交互、樣式規範，包括伺服器端造成的頁面問題等，都需要謹慎小心的處理，等到再三確認頁面功能完全正確了，再提交測試。這樣，會大大減少bug數量，因為自己也進行了詳細的測試，出了問題能夠及時解決，不管是前端還是後端，都會減少很多bug的壓力。

以上就是我的個人感悟，不多也不深，僅僅是踩過坑之後的一些想法。覺得有問題我們可以一起討論，也可以不用在意，看過就忘了也好。一個菜鳥的感想。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！