【項目總結】大數據操做系統

【項目總結】大數據操做系統

createTime:2016-09-28 16:30:55
原文地址,歡迎star!
總結下項目的問題,收穫,不足。javascript

產品功能:能夠查看 http://www.baifendian.com/pro/subject-67.html
簡單的講,該系統提供一整套的大數據解決方案。 客戶擁有大量的數據,而後如何從這大量數據中,清洗出有價值的數據。css

系統GIF圖

若是上圖看不到,點擊這裏html

項目人員及耗時

5個前端,10個後端,1個運維, 開發調試用時3個月, 測試用時1.5個月。前端

應用技術

前端技術:React全家桶 + webpack + gulp + ES6 + babel + less (react0.14)
代碼版本控制使用:SVN
後端技術:Java + 大數據相關 【略】java

項目架構

大數據操做系統,由多個模塊組成,每一個模塊能夠理解成一個Project, 能夠單獨運行,不依賴其餘模塊。 而後由web桌面集成在一塊兒。node

項目目錄結構

總體的目錄結構

- BFD-UI  公共組件庫
    - CommonComponent  公共樣式,Ajax處理,正則,針對產品定製組件部分
    - DataFactoryModel  項目應用的工做流框架
    - ConfigCenter 項目
    - DataFactory   項目
    - FilaManage   項目
    - SecurityCenter  項目
    - node_modules

單個項目目錄結構

- common  項目間公共代碼
- container  項目佈局
- modules    一級模塊目錄
  - ide   一級模塊
    - components    頁面
    - css         樣式
    - enum      枚舉
    - model     Ajax相關操做
    - util 工具
    - index.js   react-router 路由
  ...
  - workflow    一級模塊

問題

項目中考慮的問題和遇到問題的解決思路react

1、 團隊協做之間如何減小衝突?

相對剛開始,先後端還搞在一塊兒,前端開發還須要搭建後端環境,而後後端改配置,前端竟然跑不起來了,要抱着電腦去請教後端,這個坑啊。模塊化開發好很好,只須要關注本身的模塊。webpack

先後端分離, 項目採用模塊化,每一個人負責幾個模塊,模塊內包含該模塊的全部內容,除了公共的部分,保證直接刪掉該代碼,並去掉路由,直接能夠去掉該模塊,添加模塊等同。
這樣模塊解耦,方便應對需求變更,權限控制git

2、 如何管理組件?

這一塊還好,沒有遇到啥大問題。程序員

組件須要分爲:公共基礎組件,公共定製組件,具體業務組件

公共基礎組件建議採用第三方組件庫,本項目使用公司的組件庫,公司組件庫剛開始研發,過程當中各類BUG,版本迭代間,高版本用於與低版本用法不同,不少坑爹的問題。

公共定製組件:在公共基礎組件的基礎上,封裝成各個項目中,能夠快速使用的方式,方便項目間統一維護,快速方便使用。 好比(表格數據處理,翻頁處理,全選邏輯。。。)

具體業務組件:具體頁面模塊,但具體頁面中,也有共用的部分。 最多見的就是編輯頁面和建立頁面能夠共用。

3、如何管理總體樣式?

覆蓋組件樣式是一個坑,由於公司組件也在研發中,做爲第一個吃螃蟹的團隊,就。。。。
組件庫的樣式,剛開始使用模塊化+嵌套的方式, 後面組件庫豐富了,發現有一些命名重複啦,重複啦。而後大改版,使用BEM命名方式。若是隻修改命名方式也就還好,最主要仍是修改了DOM結構,而後之間的覆蓋樣式都廢了。
切記,切記,切記,使用穩定的組件庫

組件庫地址:https://github.com/baifendian/bfd-ui
已經提供第一個穩定版本,贊一個,一路過來不容易。

引用第三方的reset.css,好比(normalize.css),處理瀏覽器之間的小差別

公共基礎組件已經有自帶的樣式,須要覆蓋,換成UI設置的風格,覆蓋公共組件的樣式都放在一個文件中。好比 bfd-ui.less , 也能夠放多個文件,而後放在同一個文件夾中。

總體佈局的樣式,單獨抽離成 layout.less 文件

樣式命名須要統一規範,不然容易形成樣式名衝突。可使用 BEM的命名方式,雖然命名長了點,可是爲了命名衝突,也值了。

less 的變量也能夠單獨抽取出來,放在一個 文件中。 方便後期統一修改。好比:global.less

//其餘使用變量的地方引入
@import "global.less";

注意less 、 sass 的 import 和 css 自帶的區別。

4、Ajax請求跨域問題?錯誤處理問題?session過時問題?

剛開始coding,Ajax尚未封裝,你們寫到業務邏輯裏面,這樣代碼很亂,一個JS中,有頁面,業務邏輯,混在一塊兒。
還好及時提出瞭解決方案, 抽離Ajax這一層,先封裝Ajax操做,而後每一個模塊各自抽離出Ajax操做,模塊中調用,就是一個方法的調用。

跨域: : 關閉瀏覽器安全策略
開發的時候,先後端是分離的,所以前端訪問後端接口的時候是跨域的。考慮到最終上線的時候,是部署在一塊兒。 所以,上線後是沒有跨域問題的。 所以可使用關閉瀏覽器安全策略來解決跨域問題。

Ajax接口地址: 可配置
開發的時候,可能要鏈接後端人員機子的IP地址,訪問接口,調試完成可能要訪問開發環境地址,上線須要訪問上線部署的地址。 常常須要變更。 所以 接口的 基本路徑 作成 配置。而後直須要改動配置,就替換了整個項目接口的訪問地址。

Session過時,錯誤處理? 提供默認處理,並擴展接口自定義
項目開發,必須給Ajax封裝一層,寫統一的錯誤處理,錯誤提示,Loading效果,超時提示,Session過時等通用操做。

Ajax請求到一半,跳轉頁面,須要在 componentWillUnmount 中斷Ajax請求。不然會報 組件已經卸載,不能使用 this.setState操做的錯誤。

5、團隊協做開發,如何讓別人看懂代碼?

每一個程序員都有本身的代碼風格,可是,可是,可是團隊開發就須要共同遵照一個代碼規範。
這一塊React生命週期,你們都按照順序寫,還行。其餘方面因爲趕時間,基本是 一個 格式化功能搞定。

JS代碼規範只能口頭上說說,由於實際上會不會執行,還得要比較大的Review力度。所以可使用 eslint 來進行驗證,在提交前要驗證下。【驗證的比較粗糙】

還有一些則須要團隊之間遵照,好比使用React, 編寫生命週期的時候,請按照順序來。

constructor
componentDidMount
componentWillReceiveProps
shouldComponentUpdate
componentWillUnmount
...
其餘自定義方法
...
render

建立React組件,統一使用 ES6。加 autobind 方法

6、React組件之間如何通信?

模塊功能複雜的狀況下,最好先理清總體流程,操做事件,而後在coding。
寫IDE模塊的時候,剛開始認爲這個很簡單,而後直接啪啪啪開始coding了,後面發現都是坑,很是多的細節問題。各類事件,各類交互。致使後面Review作了很大改動,切記切記,理清需求,不要看起來簡單。

小模塊內部,使用 prop或者 context 傳遞方法進行通信, 模塊之間使用 事件派發。

7、減小修改公共組件和公共樣式,對項目的總體影響

這一塊,公共樣式,和佈局方面作還行,可是公共組件方面有很大的問題,有時候更新組件忘記通知你們,致使跑起來報錯。還有必須注意的是,進入測試階段就不要更新整個組件庫了,有BUG本身打補丁修復。由於更新組件引入新的BUG,被測試一直說。

公共樣式在整個項目中,各個頁面都用到,所以修改公共樣式須要慎重。儘可能不要使用一些奇淫技巧,寫一些穩妥的。

8、正則驗證

後臺類型的管理系統,須要有不少的表單,有不少表單就有不少表單驗證。
能夠抽離出正則表達式統一放在一個文件中,其餘各個地方都使用該文件裏面的正則,文件中沒有,則添加上。
在項目中,除了抽離正則,還封裝了有驗證功能的表單組件,而後直接配置正則,和錯誤信息(也能夠動態生成錯誤信息),便可使用。

9、SVN提交規範

這一塊在該項目中,作的還不錯。

測試階段,儘量減小修改BUG而引起新的BUG。所以必須寫清楚每次提交代碼的做用。

研發階段還好一點,作好一個就能夠提交一個,而且稍微註明下 上傳什麼模塊代碼就好了。
測試階段,修改BUG,就必須遵照SVN提交規範

  1. 修改好 一個BUG,提交一次。 【一個BUG,一次提交】
  2. 註明修改的BUG編號,出現緣由,解決方案 【重要

10、權限控制

這一塊分爲兩種,按鈕控制,模塊控制
在項目剛加載的時候,同步請求,權限數據,而後判斷 data-code是否有權限,沒有的話, 則 不 render 到頁面上

按鈕的權限控制,在最初的預想是,渲染到DOM後,在remove DOM 節點,後面發現這個想法是不可行的。

React 的 componentDidMount 回調裏面, 不能夠remove DOM節點,不然報錯。

最終封裝了一個組件,替換頁面上全部須要控制按鈕 , 圖標按鈕,超連接,下拉框選項,右鍵菜單。

renderType 屬性執行渲染成什麼類型組件(按鈕,下拉。。。)
data-code 核心: 按鈕標識,和後端匹配上

<AuthButton style={{marginLeft: 2,marginRight:20}}
                     data-code="1021002" renderType="icon" type="plus-square"
                     onClick={this.addScript.bind(this)}>新增</AuthButton>

模塊控制,則控制導航菜單便可。 過濾掉沒有權限導航選項,而後把有權限的渲染出來。
每一個模塊的代碼,是按需加載的, 也就是剛進入項目頁面的時候,沒有加載 模塊的JS代碼,這樣減小了進入系統的時間很長。

遇到的技術難題

一、關閉腳本選項卡的時候,錯位了。

【關掉第二個選項卡,可接口是關閉第三個選項卡】
主要問題是:對 React 的 key 和 render原理 的相關知識支持瞭解不夠。

tabs 的內容是 存放在 數組中,循環渲染出來的,新增一個 tab,會往數組中添加一個tab,
而後react就會 從新 render,渲染出 tabs 組件。

修改前使用 index 作爲key

<TabList>
          {this.renderTool()}
          {this.state.tabs.map((tab,index) => {
            return (
              <Tab key={index} activeKey={index}>
                {this.renderTabTitle(tab)}
              </Tab>)
          })}
    </TabList>

修改前使用一個惟一標識做爲key,就搞定了。

<Tab key={tab.uuid} activeKey={tab.uuid}>

一句話就是:想要更新組件內容,請保證當前組件的key與上一狀態組件的key不一樣。
具體能夠看《ReactJS 組件的key做用》


收穫與不足

1、收穫

  1. 負責從0到1的項目架構設計,技術選型。
  2. 項目中越到各類問題,而後解決各類問題。項目中遇到的問題,在架構設計前能考慮到一部分,可是還有不少須要遇到在解決。
  3. 熟練掌握 React的開發模式

2、不足

  1. 技術選型, 低估了組件庫升級可能帶來的影響。
  2. 在coding前,評估時間 和 實際開發時間存在一點差距。
  3. webpack優化方面,有看過相關文檔,不過沒有具體實踐在項目中。【後期忙着封版】

代考量

雖然沒有使用redux進行state管理,可是總體開發過程當中,沒有體會到狀態難管理。

  1. 可能由於模塊化開發以後,各個Ajax抽離。
  2. 可能由於各個頁面關聯性不大
相關文章
相關標籤/搜索