過(guò)程描述
前天交給我一個(gè)開發(fā)任務(wù)：一個(gè)頁(yè)面，一天時(shí)間，我信誓旦旦說(shuō)可以做完。
昨天上午來(lái)的有些晚，來(lái)了就開始開發(fā)。
這個(gè)頁(yè)面的圖片是這樣的：
布局是這樣；顯示邏輯是剛進(jìn)來(lái)的時(shí)候有一個(gè)澆水動(dòng)畫，同時(shí)選中樹的狀態(tài)的環(huán)會(huì)有一個(gè)動(dòng)畫效果；交互邏輯只有點(diǎn)擊分享按鈕可以分享到家長(zhǎng)端app一個(gè)h5頁(yè)面；業(yè)務(wù)邏輯是右側(cè)和左側(cè)的文案根據(jù)獎(jiǎng)?wù)聰?shù)量變化。
理清了思路（其實(shí)理清思路的過(guò)程還挺長(zhǎng)，需求文檔寫的需求點(diǎn)重復(fù)而且需求點(diǎn)之間沒有結(jié)構(gòu)化和順序可言），開始動(dòng)手。
設(shè)計(jì)稿是這樣:
我是第一次接觸到這樣的設(shè)計(jì)稿，一個(gè)靜態(tài)的圖片，標(biāo)記好的尺寸，配套的圖片資源，缺了什么找ui要。其實(shí)這樣很容易有一些沒有標(biāo)出的東西需要自己去量，下載ps的過(guò)程挺漫長(zhǎng)，最終也沒裝好，放棄了。
之前頁(yè)面組件存在的問題是沒有做任何組件劃分，看組件代碼只能看到一坨html，并不能一眼看清結(jié)構(gòu)，比如這樣：
這種代碼看著特別的累，想理清那一塊代碼是界面上的哪一塊要花很多的時(shí)間。所以，我先劃分了組件，是這樣劃分的。
文件有這些：
分享按鈕在components這個(gè)目錄下，因?yàn)樗欢鄠€(gè)頁(yè)面用到了。
首先是左邊的ResultTreeInfo組件，他的特點(diǎn)是 樹的圖片，樹的狀態(tài)的圖片以及下面的文案，都是根據(jù)樹的狀態(tài)來(lái)聯(lián)動(dòng)變化的。所以我是這么封裝。
treeInfo封裝treeImg、 statusImgs、 texts這三種資源的所有情況，每一個(gè)都是數(shù)組存放。然后模板里循環(huán)渲染所有的資源。并且根據(jù)treeStatus和msgIndex顯示對(duì)應(yīng)的資源，treeStatus是樹的狀態(tài)，這個(gè)需要請(qǐng)求后端接口，根據(jù)獎(jiǎng)?wù)聰?shù)、冰凍次數(shù)等來(lái)確定（還沒寫完）。msgIndex設(shè)計(jì)為computed是因?yàn)樗歉鶕?jù)一些其他狀態(tài)的數(shù)據(jù)來(lái)聯(lián)動(dòng)修改（從服務(wù)端接口獲取的數(shù)據(jù)）。isShowTreeImg和isShowTreeMsg是選中對(duì)應(yīng)資源的邏輯。
右邊的ResultList組件，是做布局以及提供ResultListItem渲染所需要的參數(shù)。
渲染的treeInfo、medalInfo、iceInfo放在state里，因?yàn)槭窍嗤慕Y(jié)構(gòu)，所以提供了resultList這個(gè)computed屬性來(lái)簡(jiǎn)化渲染邏輯。
然后是ResultListItem組件，組件的封裝和類或者其他東西的封裝一樣，都是分離變與不變，不變的部分封裝到內(nèi)部，變的部分通過(guò)props、events、slot等暴露出去。
這里不變的是布局，變的是icon、iconText、numText以及numText里面用到的數(shù)字，所以我暴露了這四個(gè)參數(shù)。
其中icon提供了枚舉值，文本提供了占位符：
具體的渲染的時(shí)候，用的是根據(jù)參數(shù)處理之后的數(shù)據(jù)：
numInfo設(shè)計(jì)成這樣是因?yàn)?，文本中?shù)字的位置不確定，所以通過(guò)占位符 + 替換的數(shù)字 的方式來(lái)做的。
現(xiàn)狀
昨天做了一天，沒做完，沒做完的地方如下：
1，組件：分享組件的封裝。
- 顯示邏輯：進(jìn)入頁(yè)面的澆水動(dòng)畫效果
- 交互邏輯：分享組件的分享功能
- 業(yè)務(wù)邏輯： ResultTreeInfo的treeStatus和msgIndex的計(jì)算，ResultList的 treeInfo、medalInfo、iceInfo的計(jì)算。這些都是根據(jù)獎(jiǎng)?wù)聰?shù)、冰凍次數(shù)等來(lái)計(jì)算的。
- 課程結(jié)束時(shí)候的菜單欄和左側(cè)快捷入口的路由替換和懸浮效果。
總結(jié)與反思
估了一天時(shí)間，結(jié)果沒做完，差的還不少，對(duì)自己的很是不滿意。分析了一下原因，至少這有幾點(diǎn)吧。
- 看需求文檔，開始沒有理清思路，花了挺長(zhǎng)時(shí)間
- 之前做react開發(fā)基于antd組件庫(kù)，更多的是調(diào)整各種參數(shù)，js寫得多，布局寫的少，生疏了，所以布局寫的挺費(fèi)勁。
- 過(guò)程中的ps下載花了一些時(shí)間
- 調(diào)試的有些費(fèi)勁，所以我把store和router掛到了window下
- 因?yàn)闆]有理清需求，和對(duì)自己的過(guò)于自信，導(dǎo)致了估時(shí)間果斷，2天也許更適合現(xiàn)在的自己。熟悉之后會(huì)快一些。
優(yōu)化和建議
流程中沒有 tech design（技術(shù)設(shè)計(jì)）的階段，很多東西都是開發(fā)時(shí)候現(xiàn)想，這樣挺容易出問題的。我們之前公司是有一個(gè)技術(shù)設(shè)計(jì)階段，寫技術(shù)設(shè)計(jì)的文檔，里面帶了估時(shí)，這樣別人review方案可以進(jìn)行改進(jìn)，同時(shí)估時(shí)也更接近真實(shí)。
沒有一些通用的組件的封裝，比如Icon、ShareBtn這種，重復(fù)了很多次的，每次都要重新開發(fā)。
需求文檔的需求點(diǎn)如果能按照順序來(lái)會(huì)更好一些。
我自己要加強(qiáng)css的訓(xùn)練，以及tech design這個(gè)階段的重視吧。效率還是不夠高。
思考所得
頁(yè)面組件 就是
布局 + 組件， 布局的部分交給父組件， 組件負(fù)責(zé)具體每一塊的布局，然后組件內(nèi)部也是一樣的布局 + 組件，直到布局 + 元素，這是遞歸的終止，這是開發(fā)一顆組件樹的過(guò)程。布局部分如果用在了多個(gè)地方，應(yīng)該單獨(dú)抽取一個(gè)布局組件。什么時(shí)候要封裝組件，什么時(shí)候不封裝組件呢。首先一個(gè)組件的模板或jsx應(yīng)該是結(jié)構(gòu)清晰的，這是基礎(chǔ)，然后某一部分用到的次數(shù)如果大于1，就有封裝的必要。比如布局，如果只用到了一次，那么就寫在組件里，如果用到了多次，那么就應(yīng)該單獨(dú)抽取出來(lái)做一個(gè)布局組件。從一到多，就應(yīng)該封裝，就像類是對(duì)象的集合一樣，組件類也是具體的頁(yè)面區(qū)塊的集合，一到多的變化就是寫死到封裝的變化。而列表組件天生就帶了多的屬性，所以listItem幾乎是必封裝的組件，不過(guò)還要根據(jù)listItem的復(fù)雜度來(lái)決定。 一和多是一個(gè)有趣的關(guān)系。
