初入社會，我只是乙個前端路上飛行的菜鳥，經過一段時間的工作之後，才知道，我踩了無數的坑。。。希望，看過我寫的文章的同胞們，不要再和我犯同樣的錯誤。（純屬個人思考）
1. 當負責專案中乙個模組的開發時，不要忘記，它只是專案中的乙個模組。
當我拿到專案經理安排好的工作計畫書時，開始對自己負責的部分的需求進行熟悉，這時的我選擇按照需求文件進行開發了。沒錯，這正是我開始接觸專案時的表現，完全沒有意識到，它只是專案中的乙個模組，等到後來開發完成後，才發現自己負責的模組其實與其他模組一環扣一環，相互有著不同的影響，於是，開始了改bug的漫長之路......
後來才慢慢意識到，系統系統，環環相扣才叫乙個系統，我們不能只熟悉自己負責的模組的業務流程，應該著眼於專案的大局，熟悉整個專案的核心流程，資料的**與去向，系統許可權控制帶來的影響等等。
2. 問問題之前首先自己思考、查閱，不要輕易問需求
不懂就問，這是好的，沒錯。但是，不懂就盲目的問，這就有問題了，如果對一項業務的流程或者頁面展現方式不夠清楚，你會選擇怎麼做？曾經，當我遇到這個問題的時候，我在簡單的思考之後選擇了去問產品需求，希望得到確切的答案。這樣做感覺上是沒錯的，但實際上，我忽略了乙個問題，包羅永珍的網路。後來，我才意識到，我應該先認真分析需求，分析業務路程，思考過後，如果不懂，再上網去查一查，不到最後，不要輕易問需求。
3. 反思頁面功能如此實現的原因，盡量優化顯示
乙個系統，或是乙個**，我們都應該記住：頁面才能直觀的體現一切！！！ 不管後台怎麼運作，不管資料如何流轉，與使用者互動的，永遠是頁面。所以，我們不能只照搬需求上的頁面布局，資料顯示方式，也應該思考思考，需求為何要這樣顯示，這樣顯示好處在**，有沒有更好的顯示方式，只有在思考之後，不斷優化顯示，才能寫好頁面，給使用者乙個好的體驗度。
4. 改bug時，注意bug的牽連性，避免蹺蹺板現象
我不知道其他人在剛進入工作的時候，有沒有遇到過這種現象，改完乙個bug，發現這個bug修改後，導致另外乙個bug的出現，這種bug的蹺蹺板現象，我遇到了。後來，我的處理方式是，改完這個頁面的其中乙個bug， 隨即對整個頁面進行一次全面的測試，以此來避免這些現象。或者，很多人會有更好的處理方式，但對於還屬於菜鳥的我來說，這是我最簡單粗暴的處理方式 了。
5. 注意提交測試頁面前首先自己反覆測試，無誤後提交測試(前端)。
我參與的專案，都是由前端來進行功能整合，然後提交測試的。在這個過程中，要小心了，之前說過了，頁面才能直觀體現一切，所以，測試測出bug，一般情況下，都是會歸於頁面問題，前端人員就會有很多的bug了。也許不同的公司會有不同的處理方式，但我遇到的便是這樣。在經過一段時間的工作之後，我深刻意識到，在將頁面提交測試之前，一定要反覆測試頁面是否有bug,資料展現、頁面互動、樣式規範，包括伺服器端造成的頁面問題等，都需要謹慎小心的處理，等到再三確認頁面功能完全正確了，再提交測試。這樣，會大大減少bug數量，因為自己也進行了詳細的測試，出了問題能夠及時解決，不管是前端還是後端，都會減少很多bug的壓力。
以上就是我的個人感悟，不多也不深，僅僅是踩過坑之後的一些想法。覺得有問題我們可以一起討論，也可以不用在意，看過就忘了也好。乙個菜鳥的感想。
乙個商人的感悟
乙個商人的感悟 1 沒有拜讀文學，將失去心靈的平靜與生命的趣味 2 沒有研究歷史，將缺乏商人的謀略 3 對趨勢與程序的無知，將無法知道自己現身在何處 4 沒有實踐，永遠是紙上談兵 5 沒有定位，將無法突出重圍，出人頭地 6 沒有目標，必將終日悶悶不樂 7 沒有思考，語言將不具殺傷力 8 沒有質量的人...
來自乙個react SPA的總結 redux篇
本文是自己這幾天做乙個reactspa的其中之一篇總結，主要總結在實踐中，學習到的有關redux的一些思想 並沒有太多細節 方便日後自己的重溫 redux用作管理應用的data state和ui state，在react中元件間的通訊一般是parent child間，兄弟間鑑於我初出茅廬，暫時沒遇到...
乙個程式設計新手的誤區
之所以寫這篇文章，源於學生時代的大多數人的抱怨。即便是到了公司，這樣的人仍然不在少數，就自己的看法寫寫吧。學生時代最常聽到的話 老師讓 做，老師沒講過 在公司到沒有這樣了，改為 師傅沒教過 我以前都是 做，以前沒做過 不會做 不知道大家聽了這樣的話都是種什麼感覺呢？估計相當一部分仍然會理直氣壯吧。沒...