2022年web前端學(xué)習(xí)經(jīng)驗總結(jié)

1、第PAGE9頁共NUMPAGES9頁2022年web前端學(xué)習(xí)經(jīng)驗總結(jié)項目項目流程1需求評審時了解代碼業(yè)務(wù)，及時提出項目中的技術(shù)問題，以及邏輯問題，對于pm的需求不理解的地方不能憑空猜想，需求文檔一定要看仔細(xì)。_項目排期時間合理，不能盲目自信，不知道多長時間能開發(fā)完成就是不知道，對功能分析到位，初次排期要詳細(xì)，每個功能的實現(xiàn)，與代碼邏輯一定能走通，開發(fā)功能較多，后端較多的情況應(yīng)合理安排開發(fā)時間，按照優(yōu)先級排列開發(fā)。排期時間內(nèi)沒有完成項目應(yīng)該向上級匯報并想辦法解決。3.功能分析，功能迭代比較多，或者功能比較復(fù)雜的，對其功能進(jìn)行功能分析，多種情況思考，保證功能正常運行。4.開始期間保證前后端進(jìn)度一致

2、，減少開發(fā)時間，提高工作效率。5.代碼自測，自測沒有問題了才可以進(jìn)行提測。6.提測期間反復(fù)出現(xiàn)的bug要注意，應(yīng)重新思考代碼流程。6.代碼上線及時合并分支。_項目跟進(jìn)，每周詢問項目進(jìn)度，安排相應(yīng)工作任務(wù)。_項目闖車可委托其他人幫完成，或者項目延期開發(fā)。git相關(guān)_多期項目需求同步開發(fā)，不同時間上線，創(chuàng)建不同的分支開發(fā)，避免上線代碼問題。_項目上線及時合并dev，master的代碼。前后端交互1.做項目之前應(yīng)先與后端統(tǒng)一數(shù)據(jù)格式，統(tǒng)一接口格式。2.不要盲目定位前后端錯誤，應(yīng)該是有問題一起解決，在前端杜絕字段導(dǎo)致的代碼問題，保證代碼安全性項目代碼1.保證代碼可讀性，命名語義化，寫代碼注釋2.作為一

3、個用戶的角度去想這個項目，寫出對用戶更有好的功能。3.面對比較難的需求的時候，最需要的是一個清晰的大腦，將項目思路縷清，從數(shù)據(jù)是如何傳入，頁面如何渲染數(shù)據(jù)，如何將修改過的數(shù)據(jù)傳回后端。保證思路連貫，然后再去想如何實現(xiàn)等細(xì)節(jié)問題，做項目的時候最重要的是用戶的體驗，如何能讓用戶有更好的體驗?首先應(yīng)該保證項目自己用著舒服。再對頁面進(jìn)行美化，不斷的修改。4.將項目中遇到的記不住，或者每次用都需要查的東西記到本子上，背下來，這些知識點會多次遇到，使用時可減少不必要的查找時間。項目進(jìn)展暫時順利。項目交接1.交接時問清楚，了解開發(fā)業(yè)務(wù)(現(xiàn)在是什么人在使用?如何使用?后期會有什么人提什么樣的需求?)，項目中有

4、什么需要注意的地方，減少開發(fā)時間。技術(shù)技術(shù)學(xué)習(xí)1.學(xué)習(xí)不要貪多，嘗試把事情做的細(xì)致一點_多動手，將項目中的問題抽出來寫一個小demo3.切忌死記硬背。4.學(xué)習(xí)新東西的時候要把握好度，要學(xué)到什么程度，別鉆到里面出不來5.學(xué)的東西雜是因為什么東西都是一知半解，沒有深入研究。6.有的問題是因為基礎(chǔ)了解的不夠多所以才不懂的，有的問題可以通過查找解決。先解決可以通過查找解決的問題，等基礎(chǔ)充實后再解決其他問題。技術(shù)思考1.學(xué)會思考問題，觀察問題，分析問題，并對問題進(jìn)行記錄，定位，查找，解決。然后再進(jìn)行思考問題為什么會解決，為什么不能解決。2.寫代碼時要明白它的需求是什么樣的，需要有什么樣的功能，如何實現(xiàn)這

5、些功能，這些功能實現(xiàn)之后會對其他功能有什么影響，是否會對代碼的穩(wěn)定性造成影響技術(shù)回顧1.階段性回顧自己所學(xué)的東西，思考自己最近的收獲與這段時間的不足2.整理自己的技能樹，整理自己學(xué)過的東西以及學(xué)習(xí)的程度，根據(jù)自己學(xué)習(xí)的程度安排自己自己后續(xù)的學(xué)習(xí)計劃vue項目1.數(shù)據(jù)控制視圖2.框架的學(xué)習(xí)，先學(xué)會使用，然后慢慢深入了解它的一些原理。了解原理很重要，學(xué)明白這一個框架在學(xué)其他框架就很好上手，也可以很快了解。3.設(shè)計評審將獲取數(shù)據(jù)，存儲數(shù)據(jù)，渲染數(shù)據(jù)，修改數(shù)據(jù)，傳出數(shù)據(jù)。數(shù)據(jù)的整個流向弄清楚，再考慮功能上面的細(xì)節(jié)。jquery1.代碼進(jìn)口與出口。個人習(xí)慣1.細(xì)心，不細(xì)心能導(dǎo)致很多問題2.工作團隊中的合

6、作，自己在團隊中能起到什么作用，我對團隊有什么樣的幫助。3.寫周報日報規(guī)劃好自己每周每天的工作量及任務(wù)，養(yǎng)成記錄思考的習(xí)慣。2022年web前端學(xué)習(xí)經(jīng)驗總結(jié)（二）對一份優(yōu)秀的交互文檔來說，都要具備什么樣的基本框架與基礎(chǔ)要素呢？如果你沒有一個明確的答案，那么本文將為你提供詳實的解答。前言：整理文檔的過程中看到_年總結(jié)的一篇文章，這篇文章主要總結(jié)了在Web端后臺產(chǎn)品設(shè)計時輸出交互文檔應(yīng)該考慮的_個方面，雖然現(xiàn)在看來結(jié)構(gòu)簡單，考慮的覆蓋面也不全，但是在結(jié)構(gòu)上還是值得借鑒。不想看長篇大論的可以跳到文末看結(jié)構(gòu)框架。在交互設(shè)計上，規(guī)范的控件庫是“術(shù)”，達(dá)于術(shù)者，達(dá)下乘也，規(guī)范的控件庫是交互設(shè)計的技巧、是可

7、以復(fù)用的技術(shù)；而統(tǒng)一的交互文檔指導(dǎo)方案是“法”，可以復(fù)以指導(dǎo)術(shù)之提高，達(dá)于法者，達(dá)中乘也；最后形成一套交互設(shè)計、用戶體驗、信息架構(gòu)的知識庫是“道”，達(dá)于道者，達(dá)上乘也。從“術(shù)法道”而言，隨著業(yè)務(wù)需求的增加，即使有了規(guī)范的控件庫可以進(jìn)行復(fù)用，但在不同的場景下會有不同的交互規(guī)范。但交互文檔的結(jié)構(gòu)是可以提煉總結(jié)的，交互設(shè)計師可以時常對交互文檔結(jié)構(gòu)進(jìn)行歸納總結(jié)，以便在今后的工作中針對不同的適用場景根據(jù)結(jié)構(gòu)快速給出方案，將更多的時間用在業(yè)務(wù)邏輯和流程梳理上。本篇文章，以_后臺管理系統(tǒng)為例，結(jié)合自己的經(jīng)驗來聊一聊我總結(jié)的交互方案。包含以下9部分，有：限制條件、狀態(tài)、頁面切換、信息校驗、系統(tǒng)提示、界面、瀏覽

8、器兼容、用戶角色、數(shù)據(jù)埋點等。在輸出交互說明文檔的過程中需要考慮以上部分，當(dāng)然并不是一定要包含以上，要視具體的產(chǎn)品需求、功能模塊與規(guī)格大小來確定。Part1：限制條件1.1是與否是與否，非0即1，允許或不允許，比如：內(nèi)容的復(fù)制粘貼，分私密信息和非私密信息，私密信息不支持復(fù)制粘貼，常見的為密碼，非私密信息則支持用戶復(fù)制粘貼。1.2范圍值指數(shù)值的取值范圍。如：列表頁展示多少數(shù)據(jù)記錄等。通常在后臺管理系統(tǒng)，數(shù)據(jù)列表統(tǒng)一是展示10條數(shù)據(jù)，可以翻頁查看更多，或者自行選擇每頁展示的數(shù)據(jù)量，有“10、20、50、100”供選擇。而物料商城的商品列表展示，適配不同分辨率瀏覽器，讓用戶使用主流的筆記本、電腦在瀏

9、覽器可視區(qū)域瀏覽商品時不出現(xiàn)視覺誤導(dǎo)(假如每頁最多顯示商品數(shù)_個，若每行顯示_個商品的話，存在多頁的情況下，商品行數(shù)為4行過_個，有_個商品空缺位，這樣看起來會誤認(rèn)為數(shù)據(jù)加載有問題)。我們最終確定的商品展示方案是：每頁列表最多展示_個商品，適配不同瀏覽器分辨率，自動調(diào)整為每行顯示4、5或_個商品，分辨率越大，每行展示商品數(shù)遞增。1.3極限值指數(shù)據(jù)的顯示極限。如：文字最多顯示多少字，顯示不下怎么辦；數(shù)字輸入框是否有上下限等。分別舉兩個例子：舉例一，在_后臺管理系統(tǒng)表格中，單元格超過寬度即用“”結(jié)尾，鼠標(biāo)懸浮顯示全文。而在設(shè)計列表、卡片、面板、彈窗等承載內(nèi)容的載體時，都要考慮到內(nèi)容的承載極限，比如

10、在物料商城卡片和購物車卡片，商品的說明內(nèi)容有多有少，而內(nèi)容區(qū)寬度是固定的，所以需要進(jìn)行視覺展示上行數(shù)的顯示。圖1.(左)商城商品卡片說明內(nèi)容限定(右)購物車卡片說明內(nèi)容限定舉例二，在物料商城中，每個商品都有庫存數(shù)，那么前端購買最大商品數(shù)對應(yīng)的就是該商品的庫存數(shù)，按常識，商品最小購買量為1。在交互設(shè)計上，根據(jù)商品購買數(shù)的極限值，當(dāng)購買數(shù)為庫存數(shù)的時候，“+”按鈕置灰，表示用戶無法再增加，購買數(shù)為1的時候，“-”按鈕置灰，表示用戶無法再減少。同時，若用戶輸入大于庫存的數(shù)字，都將被處理為最大庫存數(shù)，同理，輸入小于1的數(shù)字，都將被處理為1。在輸入數(shù)字類型的限制上，只允許用戶輸入整數(shù)。圖2.商品加入購物

11、車數(shù)量極限值限定(左：極小值、右：極大值)Part2：狀態(tài)2.1默認(rèn)狀態(tài)默認(rèn)狀態(tài)顯示的列表、文案、選項等。舉一個例子，_后臺管理系統(tǒng)中很多模塊是純列表展示，要考慮默認(rèn)展示的列表數(shù)據(jù)量是否影響加載速度，加載速度長意味著增加了用戶的等待時間成本，在這種情況下，可以采取“初次打開不加載，提示用戶點擊搜索按鈕后加載”的方案，避免等待時間過長。圖3.列表輸入查詢條件示意2.2正常狀態(tài)用戶正常使用時，會遇到的狀態(tài)。比如：商品上架/下架，數(shù)據(jù)存在動態(tài)更新情況。以_后臺管理系統(tǒng)物料商城為例，商品背后有復(fù)雜的盤點庫存管理邏輯，商品盤點缺貨的話應(yīng)及時下架。那么存在一種場景，某商品在加入購物車之前是正常在架狀態(tài)的，

12、加入購物車之后該商品已被下架了，若將下架的商品從購物車從移走隱藏，這種粗暴處理的結(jié)果就是用戶會產(chǎn)生疑惑，“我的商品怎么從購物車丟失了？是不是剛剛我沒有加入購物車呢？”。根據(jù)易用性原則“有效的反饋信息”，我們可以將下架的商品標(biāo)記為失效商品，與上架的商品作區(qū)分供用戶快速識別。圖4.商品加入購物車不同狀態(tài)示例(左：上架、右：下架)2.3特殊狀態(tài)特殊狀態(tài)往往在一些特殊場景下才出現(xiàn)的狀態(tài)，這種狀態(tài)有兩類：一是無數(shù)據(jù)情況(空白頁)，二是數(shù)據(jù)異常情況，拆分?jǐn)?shù)據(jù)異常的情況，又可能包含：數(shù)據(jù)加載失敗、網(wǎng)絡(luò)錯誤、系統(tǒng)更新等狀態(tài)。以_后臺管理系統(tǒng)的物料商城為例，數(shù)據(jù)為空的情況有：在商城某分類商品列表無上架商品、我的購物訂單列表為空、我的購物車為空這_種。圖5.物料商城數(shù)據(jù)為空占位圖示意對于特殊狀態(tài)，在同屬相同功能模塊下，可以用一套樣式風(fēng)格和文案風(fēng)格一致的占位圖進(jìn)行占位處