最近忙完了一個大屏數(shù)據(jù)報表的項目，一路走來一路坑，不過辦法總會比問題多，簡單記錄一下。
本篇文章不會記錄具體的代碼，只會記錄一些遇到問題的時候的想法和一些解決思想。

2月28號
那天是我第一次來這邊項目組，說是要做一個大屏展示的項目。當(dāng)時只有靜態(tài)頁面，并沒有成型的項目。
于是準(zhǔn)備開發(fā)，當(dāng)時做技術(shù)選型，本來后臺打算使用spring boot 前臺使用 vue+vuex.
但是這個項目還有一個其他的項目組，于是spingboot的計劃暫時擱置。但是前臺還是決定使用vue進(jìn)行敏捷開發(fā)。
當(dāng)天就把后臺的代碼拿了過來，架構(gòu)大體是springmvc +mybatis 這一套。后臺代碼做了一些完善的封裝，只要處理邏輯就行。

3月記錄開發(fā)變遷
數(shù)據(jù)庫篇：
第一版
1.數(shù)據(jù)庫表98個，邏輯極其復(fù)雜，
2.覺得使用視圖，一個頁面對應(yīng)一個視圖，
3.一條sql查找出全部數(shù)據(jù)
問題：
前端處理數(shù)據(jù)的時候 難度是指數(shù)級上升，雖然能解析出數(shù)據(jù)，但是解析出的數(shù)據(jù)變的極其不靈活，根本不利于擴(kuò)展，而且每次指標(biāo)修改可能就要修改100行的sql

第二版
1.數(shù)據(jù)庫表98個，視圖8個，一個視圖對應(yīng)一個頁面
2.給每個指標(biāo)加上唯一ID
3.根據(jù)單頁面的模塊進(jìn)行細(xì)分，一個模塊一條sql
4.前臺處理數(shù)據(jù)的時候只要根據(jù)指定模塊處理指定數(shù)據(jù)
問題：
還是有一個復(fù)雜的業(yè)務(wù)場景，以及復(fù)雜圖表的時候sql可能要多次查詢。

java后臺篇：
第一版：
1.最開始是一個接口，根據(jù)不通參數(shù)，返回8個大屏數(shù)據(jù)
2.沒有做動態(tài)sql，一個xml里面可能有60多條sql，很多是重復(fù)的。
3.接口和sql沒有注釋，經(jīng)常找不到sql的位置。
4.查詢指標(biāo)的id直接寫到sql里面，如果不對找的時候很麻煩，不利于管理

第二版：
1.對接口進(jìn)行拆分，一個頁面對應(yīng)一個,原來一個接口變成了5個。
2.對重復(fù)sql改寫，變成動態(tài)sql。
3.對所有頁面做了解耦分離，互不干擾。
4.將查詢的指標(biāo)進(jìn)行了統(tǒng)一配置管理。

前端篇：
第一版
1.以前的時候 邏輯都寫在vue里面。
2.網(wǎng)絡(luò)請求沒有統(tǒng)一管理
3.以前后臺的關(guān)系，定義個很多不需要的數(shù)據(jù)結(jié)構(gòu)。

第二版：
1.將數(shù)據(jù)處理邏輯進(jìn)行分離，將數(shù)據(jù)處理放到單獨(dú)的js里面
2.封裝網(wǎng)絡(luò)請求組件
3.將整體的結(jié)構(gòu)進(jìn)行優(yōu)化，對不需要定義的數(shù)據(jù) 不再定義。

前端還有很多不足，可能要二期進(jìn)行繼續(xù)優(yōu)化。。。。