面试之陈述最具挑战的项目、难点及解决方式

最具挑战的项目

虽然这些年做过很多很多项目,有公司的也有自己做的一些小项目。但让我印象最深的,也是让我快速成长的一个项目就是一个青少年近视防控的一个项目。

行业:这个项目是属于眼科医疗行业,人工智能、物联网、大数据方向,涵盖B端和C端的一个项目。

简介:利用物联网、人脸识别与云技术实现的集智能体检、眼健康教育、监测预警、综合干预、跟踪管理于一体的长效近视防控平台,专为“儿童青少年视力监测计划”而生。医院-学校-家长-政府一体化,打通多种眼科医疗设备,服务于多家眼科医院,最终实现体检-数据分析-智能诊断-政府报告等核心功能。刚开始只是垂直于眼科,后期改版为了智能体检方向。

产品端:整个产品线包括了PC端、微信小程序端、移动PAD端、桌面应用端。其中PC端又包含了不同的用户角色,有面向医院、面向政府疾控中心(大数据报告)、面向学校(体检报告)等。微信小程序端是面向学生和家长使用的,PAD和桌面端是面向体检工作人员使用的。PAD和桌面端又通过物联网技术与设备(如验光仪、生物测量设备、眼底相机、扫码枪、串口服务器)进行通信。

架构:系统架构的话,后端采用JAVA微服务架构,前端PC采用Vue+elementUi配合webpack工程化开发,微信小程序使用原生开发。PAD端使用的也是Vue+elementUi刚开始是直接用浏览器,后期使用的Uniapp重构。桌面端采用了Electron打包开发。

前端框架刚开始是准备使用angular的。但当时Vue很火,很多公司都在用,就选了Vue。我也是在18年下半年的时候接触的Vue,也算是直接就能上手。

整个产品从立项,到调研,去眼科医院以及参与学校的体检进行需求考察与评审,再到最终开发、调试、现场实测、再到迭代、UI设计优化都有全程参与。大概参与时间一年多,到离开的时候,第一版已经卖给了山西的爱尔眼科医院整个山西十几家医院吧,还有临汾的眼科医院。在谈的也有几家医院,包括外省的医院。当然后期还有一些功能和需求没有实现,需要慢慢完善和迭代,但是核心功能已经完成。后期又添加了很多新的体检科目,不仅是眼科。

整个小组除了技术经理是前端出身之外,前端刚开始就我一个人,因为刚开始做这个项目的时候没想到后面有那么多需求。做到后面又加了2个。后端有3个人。

个人职责:

所有的前端架构搭建,满足多端需求。像PC端面向不同的用户角色,使用的一套项目架构,因为UI风格是一致的,功能点有重合有不重合的,还有一些个别的定制服务(比如某个医院想添加付费的验光配镜服务,但另一家不需要)。所以我们最后给不同用户角色用的不是一个系统,他们互相没有关系,但一些数据是共享的。比如给某个医院我们打包成一套系统,给另一个医院又是另一套。给疾控中心的又是另一套。他们各自购置各自的服务器。学校和医院是在一个系统的。只是不同的用户角色。医院也可以开启权限,将数据共享给政府,这是后端做的事了。

我参与开发的功能,基本上都有参与,列举几个:

  1. 小程序端的家长登陆,信息录入,人脸识别登陆。体检报告生成,每次体检的数据对比可视化。家长提醒服务,发送公众号消息提醒家长孩子眼睛问题,什么时候该体检了。还有配镜的推荐。核心功能是体检报告。针对不同的数据给出合理建议。
  2. PC端:面向学校的班级人员信息录入。包括单个录入和批量excel导入和导出。学生个人报告和班级报告生成。体检结果给出建议。
  3. PC端:面向医院,有不同学校的数据检索功能、数据手动录入、数据可视化、班级整体体检报告生成。
  4. Pad端:标准对数视力表视力录入(工作人员),验光仪物联网自动录入,姓名、手机、身份证检索;数据实时更新(web-soket)。连接扫码枪和验光仪。

优化、性能

优化方面,就是一些Vue相关的优化。主要是首屏白屏和加载慢的问题。

用户体验

这个在实测中发现问题不断优化。当时做过的优化有很多,比如:

  • 在体检时候,左右眼视力最初是做的下拉选项,后面操作时候,效率跟不上,经过商议改为了直接将所有的视力数字从3.几到5.几一次性用按钮方式排列,直接点击就能录入。
  • 在操作时为提高效率,将按钮放到最适合的位置。

个人成长

  • 首先是技术方面的经验得到了提高。比如前端架构、Vue框架,比如物联网的经验、串口服务器与设备接入。
  • 提高了发现问题和解决问题的能力。有实测,有调研,有使用反馈。解决问题有独立思考、有团队协作、有会议探讨。
  • 拓展了项目及产品研发的整体的把控能力。比如如何将调研转变为需求,如何将需求落地,不同的需求要用什么功能实现,由于成本和效率问题,有没有必要满足这个需求或者哪些需求是重要的,优先级最高的。

项目中的难点及解决方式

1、为什么要用条形码

因为在体检过程中,学生开始体检时需要在系统中检索到他,然后录入后数据才能与之关联。功能和现在的核酸检测差不多。

刚开始用的是直接输入模糊搜索,可以输入姓名、或者身份证、手机号,但是有很多问题,比如重名,手机号重复或者没有,而身份证又太长,总之就是搜索还需要打字,而且模糊查询查出来的有多个人,需要2次操作,效率太低。所以当时考虑使用条形码或者二维码。(现在核酸检测用的身份证扫描,但是学生年纪小没有身份证,也记不住号码),最后选择条形码搭配扫码枪进行检索。还有个问题就是,条形码必须打印出来放到学生手中,因为如果是扫描手机上的条形码的话,学生又不让带手机。

所以最终的解决方案就是使用学生ID生成条形码,将其批量打印出来,下发给对应的学生。

2、多页面条形码打印问题

首先,学校的班级很多,学生很多,所以需要打印的条形码很多,刚开始是后台生成条形码图片,然后返回前台,然后前台通过排版为HTML,再打印,后台生成很慢,返回前台再打印效率很低。而且需要等待所有条形码图片都加载完成才能通过window.print()去打印。而且小的图片效果不好,容易失真不清晰。大的图片生成又慢。

后来了解到前台也有条形码生成工具JsBarcode,可以生成svg格式的图片,矢量图比较清晰,但在使用后发现,条形码生成效率虽然提高了,但是由于是打印的A4纸,排版后的页面太多,有一百多页,导致window.print()执行后会特别卡,需要很久才能显示预览的界面。而且打印出来底部的条形码和名字有的被一分为二到第二页上面了,而且打印的每页右侧空白过大,条形码也变形了。

为解决变形和空白的问题,多次查阅才发现是页面宽高产生的问题,用的是A4纸,所以经过不断调试宽高,让每个条形码和名字以合适的宽高均匀排版到打印的纸上,一行排几个,一列几个。

另外为解决页数过多的卡顿问题,可以将条形码尺寸改的小一点,让一页尽可能多的排列,让页数变少,但是这样的话页数还是很多,而且条形码的尺寸小不方便扫描。

经过思考,想的办法是,能不能把数据分成多份去打印,但当时用的是window.open()的方法打开新的空白页,但不论是使用window.open()还是模拟a标签点击事件打开多个新标签都会被浏览器拦截。多次尝试下,最终解决办法是:在一个标签解决多次打印问题,将数据分为多份,将第一份数据排版之后,赋值给body进行打印,监听打印事件onafterprint,等到一份打印完成,再次将页面body赋值为新的数据,再次执行window.print()(这里需要设一个setTimeout延迟,否则无法弹出打印预览窗口)进行打印。

3、某生物测量仪器的数据实时上传问题

在处理物联网问题时,遇到最大的问题就是不同品牌的设备数据导出的方式不同,而且数据传输的协议也不同。比如有些是通过蓝牙实时传输,有些可以通过wifi实时传输,大部分是有一个RS232串口的串口。通过串口连接到串口服务器,在将数据实时传输到服务器接口。然后根据不同牌子厂家提供的数据协议、密码等进行解码。这其中遇到几个很难解码的数据格式,甚至于乱码根本解不了。

最后通过长期与厂家和经销商技术员沟通,才知道他的数据连接线需要定制,而他没有提供配套的连接线。最后联系做数据线的供应商才解决这个问题。

这其中有一台设备,没有数据线导出口,他的数据是在电脑软件上实时生成一个xml文件到硬盘中。这就需要写一个脚本,监控文件变动,实时解析xml文件然后将数据传回后台。

最初公司后端他们用java写的脚本,但是编译后软件比较大。当初我正好是在研究Go语言,因为Go语言编译打包后的可执行包很小,所以我直接用Go写了一个脚本。当时也算是小小练手,但最终测试没问题后,被领导采纳了。

4、PAD端uniapp打包

刚开始时候,在PAD端直接使用浏览器,但浏览器还需要输入域名,且需要手动去全屏界面,且无法与安卓的蓝牙进行交互,监控不到蓝牙设备。后来选型使用uniapp,因为uniapp也是用的Vue。但是当初在使用uniapp的时候,还不成熟,遇到过很多问题,文档写的也不太好,有很多问题。所以解决这些问题也用了不少时间。

5、可视化报告快速生成平台

当初公司在做供应链运营的项目,有很多的功能点需要数据可视化分析报告。而且这些报告需要不同的模板,有的需要实时数据,且需要导出PDF、以及线上页面。而且在未来公司开发相关系统也会有这样的需求。为了节省时间,提高开发效率,我向领导提出开发一个数据可视化页面快速开发平台。通过组件拖拽及简单配置,配合导入的数据或接口可快速生成可视化报表页面,可进行导出 PDF、Word 及 Html,也可生成链接嵌入到其他系统,提高公司业务的可视化报表快速开发效率。这里用到的技术是Vue+echarts。

前期的组件封装和模块开发问题不是很大,难点就是公共组件很多,需要封装很多,比如配置项,不同的图表有很多重复的配置项,所用的输入表单太多,如果一个图表就要写一堆表单,太费力。

所以解决方法是封装很多公共的组件,将输入框、下拉框、单选多选等进行二次封装。而界面上的图层也是不同的图表封装不同的组件,如果有相同的配置提取出来,给出默认值。然后在展示的时候使用动态组件形式。

另外拖拽功能、图层叠加、图层缩放、视图界面缩放也花费了不少时间。这里我全部都是用原生写的。使用了很多鼠标事件。也做了节流操作。

最终存到数据库的数据是一个大的json对象,其中包含了报表的信息和图层数据。

最大的问题就是,初期测试,图层过多的话,内存会吃不消。在配置和拖拽操作时会有一点轻微的卡顿。在不断的测试和与同时沟通过程中,发现内存占用过多的就是一些配置项数据等。因为之前是只要创建一个图层,图层相关的数据就一直在内存中,当时是考虑激活的时候配置栏能够响应快一些。

这块解决办法是全部能使用懒加载的操作就使用懒加载。在图层点击激活的时候再加载相关的数据和组件,如果加载较慢就添加loading。在切换图层之后,将不需要的数据进行及时销毁(只保留当前状态,其余如默认值、图层配置项全部置为null)(原先是切换图层之后,由于图层所在组件并没有销毁,所以组件内的数据包括静态的和响应式的全部都在)。

加载中...
加载中...