一、開發(fā)日常
? ? 1. 接收到新需求后一定要仔細(xì)研讀需求文檔赦拘，先有個大概構(gòu)思慌随；將功能點劃分，拆分成小塊躺同；
? ? 2. 自己沒做過的功能一定要先去學(xué)習(xí)阁猜，調(diào)研，盡可能早的暴露問題蹋艺，千萬不要等到最后實現(xiàn)到一半發(fā)現(xiàn)有無法解決的坑剃袍，那這樣往往坑的是自己；
? ? 3.盡可能多跟后端交流溝通车海，有些自己比較難處理的數(shù)據(jù)可以交給后端大佬們笛园，前端主要集中于頁面的渲染，交互侍芝，不做過多的數(shù)據(jù)處理研铆；
? ? 4. 多站在測試的思維角度去考慮自己代碼要涵蓋的場景，這樣你會發(fā)現(xiàn)自己所寫的代碼有不少的bug州叠；
? ? 5. 有些需求可能產(chǎn)品老師異想天開棵红，但是前端小伙伴可以梳理功能邏輯，提出更好的方案咧栗，使系統(tǒng)更易于維護(hù)更新逆甜，而不是完全按照文檔實現(xiàn)虱肄，最后甩鍋文檔就是這樣寫的。
? ? 6. 再小的功能也要新建一個分支交煞，再著急的Fix 也先在自己的分支修改測試再發(fā)到測試環(huán)境咏窿，千萬不要直接修改gitlab上的代碼或者直接修改測試分支代碼，這樣很容易造成不一致素征，測試小伙伴測試沒問題集嵌，一上線就有問題；
? ? 7. 自己解決的bug一定要多積累御毅，弄清楚why根欧？原理, 可以給自己的前端工作來一個小糾錯本本，積累的多了也就變成大牛了端蛆，? 下次就不會寫這樣的bug凤粗；
? ? 8. 千萬不要試圖給測試小伙伴講原理，他們聽不懂今豆，簡潔有效的溝通方式：我改嫌拣！ 不需要我改！ 把問題責(zé)任人告訴ta呆躲，或者bug指給責(zé)任人亭罪，也不要告訴開發(fā)這不是個bug，可以跟產(chǎn)品老師一起探討歼秽，讓產(chǎn)品老師決定要不要修改；
? ? 9. 沒事真的多看別人寫的代碼情组，俗話說三個臭皮匠頂個諸葛亮燥筷，看別人的代碼你會學(xué)到很多，取其精華去其糟粕院崇，看不懂的地方一定要認(rèn)認(rèn)真真的啃下來肆氓，一旦你啃明白了這塊硬骨頭你會學(xué)到更多的東西，一旦你放棄了底瓣，你學(xué)到的就只有你已經(jīng)知道的那部分谢揪；
? ? 10.? 用例評審一定要仔細(xì)聽，有些case在測試前你就發(fā)現(xiàn)是bug捐凭，悄無聲息的修復(fù)拨扶，有些case可能本身就有爭議，這個時候最好提出來茁肠，讓測試小伙伴也明白患民，省的你代碼沒擼多少，系統(tǒng)缺陷提了一堆垦梆，影響最后的KPI匹颤；
? ? 11. 不要圖安逸仅孩，勇敢的去做自己沒做過的工作，你會發(fā)現(xiàn)這樣比你天天做一樣的工作更有趣印蓖，如果你完成了會有成就感辽慕，并且在解決問題的過程中也會學(xué)到很多，那比你看多少文章赦肃，看多少本書都有意義溅蛉；總之一句話，新項目勇于去參與摆尝，新技術(shù)勇于去挑戰(zhàn)温艇！
? ? 12. 有問題盡量自己去百度，去技術(shù)群堕汞，去技術(shù)吧尋求解決方法勺爱，不要過多的打擾身邊同事，更不要大小問題都請教身邊同事讯检，不恥下問已經(jīng)過時了琐鲁，問同事太多他們會覺得你技術(shù)不行，慢慢的會失去敬畏人灼，會讓你失去很多機會围段，領(lǐng)導(dǎo)對你的印象也會不好，解決問題的能力就是你的技術(shù)投放；
? ? 13.? 工作日報一定要寫的詳細(xì)奈泪，多積累自己的專業(yè)術(shù)語和詞匯，光會擼代碼不行呀灸芳，你要學(xué)會寫工作日報涝桅，這是你工作的體現(xiàn)；大佬們寫的文章技術(shù)可以學(xué)不會烙样，但專業(yè)詞匯一定要學(xué)習(xí)積累冯遂，有百利無一害！
? ? ? ? 加油谒获！今天就到這這里蛤肌，寫的有點累，哪天接著補充
