前端系统开发月报

开发背景

1
2
3
4
对之前的系统更新升级
目前有几套不同端的系统
不同的入口,不同的前端页面,统一的接口,统一的数据库
单页面应用系统

路由设计

1
2
3
4
5
6
7
8
URL -> 先由服务端统一路由 -> 然后交给前端处理

目前设计了两种路由:
/t 开头的有导航路由,统一的操作界面,有权限
/x 开头的无导航路由,独立页面,一部分无权限

考虑到代码的复用,以及减少当前系统的代码体量
对于用到的以前系统的页面全部加载到 /x 路由下

页面的统一化设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
在样式里面沿用了以前系统的一些样式风格
另外加了一些的新的样式
保证在一个系统里面尽量做到样式的统一化
尽量减少样式的多样性
统一的基础模块:
模态框
表单元素
按钮、输入框、下拉框、复选框、单选框。。。
加载层
面包屑
分页器
表格
。。。
不同尺寸的字体、表单元素、加载层。。。
不同内容的排版设计
不同的内外边距的阀值
。。。
比较赞成蚂蚁金服的一些设计理念
辅助用户有效决策、减少用户额外操作,从而节省用户脑力和体力,让人机交互行为更自然;
在感知和认知中,视觉系统扮演着最重要的角色,通过提炼自然界中的客观规律并运用到界面设计中,从而创建更有层次产品体验。

页面结构化设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
在页面结构上采用了通用的系统结构:头部常用功能、左侧导航、右侧内容区域
右侧内容区域设计
设置了最小宽度,以及底部统一的留白
以前系统中内容区域做成了一个固定的BFC,这样的兼容性比较差,不利于系统的拓展,以及后期的界面维护,DOM结构复杂
现在采用了开放式盒模型,相当于内容区域可以任意自定义

一个公用的样式表,包含了系统的主体结构样式
对于每个场景特定的样式,则是单独书写,以 a- 开头
这样的编写风格,便于后期维护,当看到 a- 开头的时,说明这是局域性的

在层次结构上,根据不同结构,设置不同的层级
一共分了4个层级
内容为最底层
内容的提示层为第二层
弹出层、模态框为第三层
加载层、顶部操作提示为最高层

系统的前端架构设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
场景化处理,每个场景进行模块化设计,
(这是在之前用 react-native 写移动端的时候总结的一个开发思想,感觉代码的可维护性高了,逻辑更加清晰了)
现在在开发移动 web 端也经常会用到,
每个场景可以单独运行,多个系统间可以对场景进行复用,
统一的设计可以做到对场景的无缝切换

场景化处理讲究的是代码的解耦,
场景中有台词、有道具,台词一般都是根据场景定制化的,而道具可以共用,禁止制作道具的时候与场景进行强关联

前端架构上分成了三层一集合一拓展
三层:数据处理层(也叫业务层)、连接层、服务层
一集合&一拓展:全局处理函数集合、全局插件拓展
数据处理层:
由上到下,初始化数据、入口函数、交互处理、数据处理、数据请求
这样的编程可以增强代码的可读性、易维护性、而且更加容易定位错误
连接层:
这次做了一个统一的连接层,减少了以前一个业务层需要多个连接层的复杂
服务层:
数据请求的统一处理,只做和数据请求相关的事情,精简冗余代码
全局处理函数集合:
这里面不依赖于任何第三方的东西,可以做到代码的任意移植
这块的代码避免和业务强关联
之前也写过一个类似的统一的处理函数集合,不过个别函数依赖了另外模块的方法,所以这块的代码就很不灵活
全局插件拓展:
统一的插件拓展,每个拓展独立运行,增强代码复用和代码的可维护性

映射表的设计、过滤器。。。还是沿用的之前的

总结

1
2
3
4
5
6
7
8
9
10
11
12
设计一个系统需要考虑到:
代码的可维护性
代码的复用性
系统的拓展性
避免冗余代码和逻辑
在编码上面需要考虑:
代码的可读性
代码的鲁棒性
统一编码风格

代码的可维护性放在第一位,不要让后期维护你代码的同事骂你
统一的编码风格更有利于大项目的协作,并增加了代码的可读性
文章目录
  1. 1. 前端系统开发月报
    1. 1.0.1. 开发背景
    2. 1.0.2. 路由设计
    3. 1.0.3. 页面的统一化设计
    4. 1.0.4. 页面结构化设计
    5. 1.0.5. 系统的前端架构设计
    6. 1.0.6. 总结