华软项目总结

引言

上课，上实验，写文档，终于有时间写博客了。

我以为这学期的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，性能很是好。京东主页采用该框架构建。

以前看到过通过前端的性能优化博客，采用本身设计的链表优化性能，如今也算是明白了面试官的真意。能当上面试官的，确定都是通读开源项目源码或本身写框架级别的人物，人太多，基础的框架使用是我的学习学习官方文档都会，怎么筛选呢？而后面试官写框架的技术功底就用上了。

因此，你进不去阿里，不是你不够优秀，是你不适合写框架。

总结

总有一天，咱们也要写一款属于本身的框架。