華軟項目總結

引言

上課，上實驗，寫文檔，終於有時間寫博客了。

我以爲這學期的Android實驗上的仍是頗有意義的，課上，與個人舍友張一帆(自學Android及相關框架，有過Android比賽項目經驗)一塊兒討論了Android的架構分層設計，以及對Retrofit和RxAndroid框架的封裝。

通過在實驗中的學習，以及請教了一些在Android界算是有小有經驗的人以後，發現本身年初對Android實驗設計的有些問題：

年初計劃使用Data-Binding與Fragmentation實現單Activity架構，後來發現這樣並很差。

1. Data-Binding學習成本過高，且對原項目結構破壞性較大，對新人學習並理解Android無益。
2. 單Activity架構雖然很優秀，但實際項目中仍然是多Activity+多Fragment架構，去追求單Activity意義不大，手動管理Fragment會十分麻煩。

發現錯誤，就改吧。目前已經在實驗中引入並應用了ButterKnife、Litepal、Retrofit、RxAndroid等框架，感受技術上應該不會有太大變化。之後再一塊兒和你們分享一下我在Android方面的學習收穫。

同時，華軟虛擬化管理系統1.0版本正式完成，本週花費整三天完成了項目發佈及部署文檔的撰寫(感謝潘佳琦，爲了儘快交付，MySQL的安裝與配置文檔是他幫我寫的，寫得很是好)。

如今再回想華軟項目，仍是存在不少細節當時沒有考慮到，在此進行反思與總結。

反思

笨拙的異常處理

後臺設計得沒什麼問題：當發生錯誤時，後臺會拋出異常，全局異常處理處理掉該異常，並將錯誤信息返回給前臺。

笨拙在前臺的攔截器這裏：

起初設計的是攔截器處理掉全部異常，並給予用戶友好的提示，這樣訂閱時就不用處理error了。

當須要的時候，再去寫error方法，好比登陸時要在error裏提示用戶名或密碼錯誤的提示信息。

攔截器處理異常，爲了攔截器能準確地提示錯誤信息，因此擴展了HTTP狀態碼，對512等狀態碼擴展了新的含義。

switch (error.status) {
    case 401:
        if (this.router.url !== '/passport/login') {
            this.msg.error('用戶認證發生錯誤');
            // noinspection JSIgnoredPromiseFromCall
            this.router.navigateByUrl('/passport/login');
        }
        break;
    case 403:
        this.msg.error('訪問被拒絕, ' + error.error);
        break;
    case 404:
        this.msg.error('資源不存在, ' + error.error);
        break;
    case 502:
        this.msg.error('服務器網關錯誤，請聯繫系統管理員');
        break;
    case 504:
        this.msg.error('服務器網關請求超時，請聯繫系統管理員');
        break;
    case 512:
        this.msg.error('數據同步異常，' + error.error);
        break;
    case 513:
        this.msg.error('主機操做異常,' + error.error);
        break;
    case 514:
        this.msg.error('訪問被拒絕異常,' + error.error);
        break;
}

當時寫完這個攔截器的時候內心仍是挺爽的，心想，之後可不再用管理error了，多省事。如今再看看這個攔截器，說不上來什麼緣由，就是感受怪怪的。

由於攔截器中是一個通用的提示信息，因此就出現了有時候須要在攔截器里加提示，有時候須要在error裏提示，不想攔截器提示信息。

後來反思了一下，自定義狀態碼應該是合理的，也就是後臺返回512、513之類的，前臺能直接經過狀態碼準確地判斷當先後臺到底哪錯了。

可是這個攔截器這樣寫，就變成了，後臺一個狀態碼對應一個提示信息，至關於我這個攔截器和後臺拋出的異常綁定了，因此有時候雖然也是那個錯，可是在這個界面提示出來就顯得格格不入。

奇怪就奇怪在前臺誤解了自定義狀態碼的本質，自定義的狀態碼其實不是我後臺有什麼，前臺就要攔截什麼，新加一個狀態碼，就是爲了前臺能夠更準確地提示信息，而不是一個500的服務器錯誤。

改正：之後攔截器只處理通用的狀態碼，如:401跳轉到登陸，403提示訪問被拒絕。而一些涉及到具體業務的狀態碼，仍是應該放到onError方法中處理。

不完善的Loading

這是上次開會的時候晨澍提出來的，友好起見，當網絡請求的時候應該顯示Loading的動畫。

想起來NG-ALAIN實際上是爲咱們封裝好了的，只是沒有啓用。

其實本身實現原理也簡單，就是裝飾器模式：

對原生的HttpClient進行裝飾一下，組合一個帶Loading的YunzhiHttpClient。

之後Service請求就使用YunzhiHttpClient，發起時，將Loading置爲true，數據回來的時候，將Loading置爲false。

組件中若是想用怎麼辦呢？直接注YunzhiHttpClient，由於在同一個模塊中是單例的，因此直接使用注入的YunzhiHttpClient的Loading來控制加載動畫是否顯示。

改正：使用此方式添加Loading動畫。

字段名與數據結構分離

@Entity
public class HostGroup {

    ...

    // 和電腦多對多
    @ManyToMany
    @JsonView({NoneJsonView.class,
            HostGroupJsonView.getAllGroups.class,
            HostGroupJsonView.getGroupById.class,
            UserJsonView.getCurrentLoginUser.class
    })
    private List<Host> hostList = new ArrayList<>();

    ...
    
}

HostGroup中有字段是hostList，存儲計算機列表。

具體的場景忘了，好像是潘佳琦在寫功能的時候，我給提了點思路，忽然一想，若是這個計算機存的是個Set，那就不用這樣費事了。

假設咱們這樣改：

private Set<Host> hostSet = new HashSet<>();

後臺是簡單了，前臺表示很無辜。

List和Set，都是Json裏的[]，前臺綁定的都是Array，我無論你後臺怎麼存，可是請你改數據結構的時候不要牽連前臺。

既然List和Set在前臺看起來同樣，那爲何不改爲hosts呢？後臺數據結構隨便改，對前臺無影響。

改正：之後再有新實體，字段名與數據結構分離。

使用HTTPS

使用BASIC認證方式進行登陸，前臺將用戶名和密碼進行Base64加密傳給後臺。

HTTP請求，在網絡傳輸過程當中黑客能夠直接攔截數據，並查看header，Base64解密很容易。

既然大勢所趨，那之後要求安全的項目仍是使用HTTPS吧。

簡單學習了一下，SpringBoot配置SSL須要證書，證書能夠買也能夠本身生成。既然能本身生成，爲何還要買呢？HTTPS證書好像還挺貴呢？

無心間點開天貓的cookie，發現裏面只認識XSRF-TOKEN，其餘的都不知道。仔細想了一下，應該是天貓對安全的要求很高，不光是HTTPS保證數據傳輸的安全，更重要的是要保證發起請求的必定是客戶本人，可能有好多算法的驗證，保證用戶不受損失。

想一想我寫的，用戶的token若是被竊取了，誰訪問都行。

看來在數據安全的道路上，咱們還有不少路要走。

團隊文檔倉庫

寫華軟部署文檔的時候發現，寫一個軟件如何安裝的教程真的是太困難了，而且如何再有項目，再寫文檔，還須要再寫一遍。

能夠直接建一個軟件安裝的文檔倉庫，再寫部署文檔，直接說我須要mysql，須要nginx。

直接在adoc中使用文件包含，將網上的這個adoc文件包含到個人文檔中，就好像是本身寫的同樣，實際上是外部引進來的。

Angular架構

你們看圖，這是個人前臺設計思路。

多模塊主要是在NG-ALAIN那裏學習的，此架構設計適用於權限分配系統，由於採用loadChildren動態加載模塊，也就是說，只有當用戶訪問/student這個路由時，纔會加載學生管理Module，而不是無論有沒有這個模塊的權限，直接都交給瀏覽器去加載。

Core Module，被學生管理等實際的業務Module引用，該模塊引入外部第三方組件。

包含基礎實體，即與後臺對應的實體，拓展實體，實際項目中發現不只須要基礎實體，還須要根據組件要的數據結構本身構建實體並傳過去。

基礎組件、基礎過濾器、Service，都放在這裏，這樣在業務組件裏想用就用，很方便。

設計出來了，感受付諸實踐時應該仍是有所困難，畢竟目前用的是NG-ALAIN現成的，之後須要本身搭。

點贊Angular

最後爲Angular點個贊，通過一個項目的洗禮，發現技術選型是正確的，選擇Angular是多麼的明智。

咱們追隨的一直是國外的腳步，VAR三者，確定不用Vue，畢竟TypeScript都不支持。

因此國外的主流技術一直是Angular和React，二者都支持TypeScript，只是在設計思想上有所不一樣。

Google和Facebook都是互聯網巨頭，咱們中國的互聯網企業與之相比根據不算什麼。(去年Facebook的股票跌了6個京東)

Angular是框架，完善，直接把Angular一安裝，什麼網絡請求，什麼路由都有了，直接拿來用。

React是庫，小巧靈活，須要整合其餘庫才能開發應用，在Facebook改協議以前，React當之無愧的前端第一框架。

Facebook改了開源協議，就被Apache基金會封殺，同時國內全面棄用React，因此國內涌現了無數類React框架。

即在不修改原React項目的前提下，只修改依賴的框架，框架對外提供的api相同，便可實現無縫切換。

最優秀的類React框架要數京東的Nerv，性能很是好。京東主頁採用該框架構建。

以前看到過通過前端的性能優化博客，採用本身設計的鏈表優化性能，如今也算是明白了面試官的真意。能當上面試官的，確定都是通讀開源項目源碼或本身寫框架級別的人物，人太多，基礎的框架使用是我的學習學習官方文檔都會，怎麼篩選呢？而後面試官寫框架的技術功底就用上了。

因此，你進不去阿里，不是你不夠優秀，是你不適合寫框架。

總結

總有一天，咱們也要寫一款屬於本身的框架。