項目組第一次項目心得體會
但是我做的是不是web端，是微信小程序端。在剛做完項目組寒假作業(yè)的不久再繼續(xù)做這個微信小程序還是比較熟悉的。但是其實小程序我懂得還不夠多，在今后還需要繼續(xù)看更多的案例和API。
這次是我第一次比較完整的做了一個微信小程序項目，也是我第一次做的一個前端項目，有很多很多可以總結(jié)的經(jīng)驗。我想在此總結(jié)一番，我覺得這些都是非常可貴的東西。
我所做的整個前端項目大概可以分成這么幾個階段：
等待出原型圖的同學(xué)做好原型圖，出一張原型圖就寫一個頁面。
等待寫好每個頁面之后開始做頁面跳轉(zhuǎn)和一些頁面邏輯，比如：
點擊某個按鈕會彈出某個消息框
點擊某個按鈕會讓頁面里的一部分內(nèi)容發(fā)生變化
點擊某個按鈕會發(fā)生頁面跳轉(zhuǎn)
做交互，就是把每個盒子里的具體的數(shù)據(jù)通過網(wǎng)絡(luò)請求的方式從后端獲取到j(luò)s這里，然后再渲染到頁面上。
同時在每個階段都有不同的感受：
在第一階段就是感覺：很無聊，寫到后面甚至開始感覺惡心了。三四天寫出20個頁面，一個頁面平均50~100行wxml代碼，和150~350行l(wèi)ess代碼。一個盒子一個盒子的加，一個邊距一個邊距的調(diào)整，我在想，如果要是能夠有一個圖片識別，通過優(yōu)秀的算法識別出來圖片里盒子嵌套關(guān)系，距離顏色以及文字識別，自動生成前端代碼的程序該多好……可能是因為自己的切圖基礎(chǔ)沒太大問題，所以沒有遇到什么特別大的困難。只是微信小程序的彈窗和成功圖標顯示的組件是新的東西，我查了一會才會做。感覺微信小程序的前端好像比普通web前端更加方便，有條件渲染和循環(huán)渲染。配合js可以很方便的做到“點擊某個按鈕會讓頁面里的一部分內(nèi)容發(fā)生變化” 這種效果。
第一個階段做的差不多的時候便開始了第二個階段，第二個階段進項的過程中也在逐漸完善第一階段。在這里由于我是第一次用“摹客”這個團隊合作平臺，并不是很熟悉里面的操作，在分析跳轉(zhuǎn)的時候我在一張一張的設(shè)計圖里一個一個的對比。感覺非常的麻煩，20多頁內(nèi)容，我嘗試在草稿本上畫草稿，然后用箭頭連接起來，但是還是頁面太多了，我放棄這樣做了，后來憑著感覺走了。但是身邊的同學(xué)過來看的是后讓我打開了“原型稿--開始演示” ，我才知道原來還可以有點擊跳轉(zhuǎn)效果的圖稿?？赡芪医窈笞鲰椖坑龅铰闊┑牡胤揭喽嗪推渌瑢W(xué)交流一下吧。沒準只是一個非常小的問題，就解決了很大的麻煩。
同樣，在進行第三階段的時候也在完善第二階段。第三階段相比前兩個階段還有點意思，同時也是第一次做。這一步需要修改html代碼，把原有的假數(shù)據(jù)全部挖空成一個一個的 {{ }} 空位置，然后在js里寫數(shù)組的數(shù)據(jù)，把它傳送到空位置里的字段里，循環(huán)渲染。大部分交互還不復(fù)雜，只是總會出現(xiàn)這樣那樣的問題，網(wǎng)絡(luò)請求拿不到數(shù)據(jù)，結(jié)果發(fā)現(xiàn)經(jīng)常是后端人員寫的接口有問題。還有就是微信小程序的openid的獲取有一點復(fù)雜，需要和后端服務(wù)器連續(xù)發(fā)送不止一次請求。其實在寫的時候我終于意識到this指向問題是多么重要了，外側(cè)Page是一個對象，在Page內(nèi)寫代碼總比可避免再寫一個新的對象的。這里就必然涉及到this的指向問題。我還記得我為了獲取到data數(shù)據(jù)，還用了一些比較冗余的方法……我覺得比較復(fù)雜的可能還是消息頁面的數(shù)據(jù)交互，需要根據(jù)拿過來的數(shù)據(jù)仔細觀察，對比界面上的內(nèi)容一點點分析是怎么回事，需要分開不同的人發(fā)來的消息，還要把不同人的對話中的最后發(fā)消息的那一方發(fā)的消息拿過來渲染到消息列表的標題里，還有其他很多很多這里就不細說了，由于最后也沒多少時間了，項目也快截止了，再加上課多作業(yè)也多，精力也消耗的不少了，我也就只能做成這樣了，可能還有一些bug以及未實現(xiàn)的功能存在。但也就到這里了。
這是我第一次和很多人一起做一個比較完整的項目，我在前端的感覺總體還行，只是有點累。我覺得主要是因為沒有向后考慮那么多，導(dǎo)致我做的時候從局部到整體開始做，一開始沒有形成一個統(tǒng)一的觀念，也沒有為做交互做考慮。其實應(yīng)該一開始就搞好頁面之間的跳轉(zhuǎn)關(guān)系，在寫代碼的時候也同時為交互做考慮，這樣也許會更好吧。無論怎樣，這第一這做項目對我來說可以算是一次寶貴的經(jīng)驗了。
