引言

准备做个项目实战系列，选一些比较有代表性，难度适中、规模合适的项目，从不同的角度，不同的深度去解析。很多初学者都抱怨没有实战项目，而学校/机构里大量用烂的学生管理、图书管理、电子商城等项目实在没有什么新意。近期因为工作的原因，带了一批大学里的实战项目，通过这次带实战项目，有了一些心得，所以把这次的实战项目整理下来。希望能对初学者们有所帮助。

本系列中不会介绍过多技术的各种用法，更多的是通过介绍一个项目从无到有要经历过的所有工作，很多时候也不会去选择一个非常好用的技术，可能会选择一些比较笨的方法，例如：在MyBatis和MyBatisPlus中选择用MyBatis，因为我希望初学者把更多的注意力放在解决问题的思路和基本功上，而并不是放在一些工具的炫耀上。当你的基本功用吐的时候才是考虑寻找更方便的工具的时候。

核酸检测每个人都经历过，而现在核酸检测是离不来核酸检测平台的，不知道程序员们有没有去思考过这个平台是怎么实现的。

我有兴作为志愿者参与了核酸检测工作，对这个平台有一些了解，这个项目从功能上来说并不复杂，涉及到的数据库表可能连20个都不到，但是业务逻辑却环环相扣。

同时它又涉及到了多个端、多个角色。可以让初学者对多端项目的设计有一些粗浅的概念。

从需求的角度，它不是单纯的增删改查，页面之间往往是有关联关系，做起来不会那么枯燥。

不要求并发的情况下，项目可以很简单，非常适合初学者练手；

考虑并发的情况下，又非常适合来做redis、微服务等来做优化，又可以做深度优化。

可以说从很多角度来讲，这个项目都是非常好的教学数据。

所以本系列的第一个项目就采用逆向工程的思路来做《核酸检测平台》

项目实战：核酸检测平台第一章 逆向工程

本章目标

完成项目的需求分析

重点：根据可见功能反推出不可见功能

项目概述

检测项目平台是东软开发的检测平台， 在网上也能查到相关的培训视频，要了解清楚需求还是要认真看一看培训视频。

https://www.bilibili.com/video/av596102734/?vd_source=cd85f68bf727f315e1776859a5694e1f

另外还有一篇公众号文章介绍采集人员APP

https://mp.weixin.qq.com/s/USOiDdhrOy0zxK3WjAH1kQ

这个视频是比较早期的培训视频，目前其实已经升级了，能够支持二维码扫描采集检测人信息，大大提高工作效率。

通过视频可以看到项目涉及到如下几类使用平台的人群（或称之为角色）:

1. 采集人员：通过APP完成核酸检测信息采集任务
2. 转运人员：通过APP完成转运过程必要的信息采集任务
3. 检测人员：通过平台提交检测结果
4. 普通用户（百姓）：通过平台查询核酸检测结果，目前升级之后普通用户还需要通过平台生成核酸检测码，以便于核酸检测时采集信息，通过公众号等平台查询核酸检测采集点

需求分析

学软件开发的同学都知道做软件要先进行需求分析，但这个项目采用逆向工程的方式开发，部分需求从网上搜索到的资料已经有了，我们只需要把他们整理一下。其中比较重要的就是下面的流程图了。

什么是逆向工程？

这个问题百度一下就有答案，不过理解起来有点费劲，而且听起来这个词高大上，其实通俗的讲，其实就是模仿。没错，逆向工程在很多领域是极不光彩的，往往会被冠以山寨、抄袭这样的词汇，不过在软件行业，逆向工程是学习提升、需求分析的必备技能，一定要掌握。

业务流程

根据流程图我们可以看的出核酸检测整体的工作流程，作为普通百姓的我们，要证明我们是安全的至少要经过采集人员、转运人员、检测机构这几类人的手。而且动不动来几次全员核酸检测，每一次都要动用大量的人力、物力、财力，如果没有一套可靠的信息系统的话，光信息的上传下达都能把人搞疯。

而整体平台的使用者涉及到的人群还是很大的，不论是采集人员还是转运人员，即有可能是20岁的年轻人，也有可能是50+的大叔、大妈，APP的设计必须要考虑系统使用的便捷性。所以说这个平台功能可能并不复杂，但是必须要做到方便使用。不管怎么说，需求分析还是要把功能清单给列出来的，我们先来看看从资料中可以找到的可见功能吧。

功能清单：是需求分析非常简单有效的方法，有经验的工程师一看功能清单就知道系统的大致结构了。大脑中瞬间就是开发完成（naobu）出整个系统。作为初级工程师，一定要常常练习列功能清单这个方法。

可见功能

这里说的可见功能指从培训资料、文章，以及下载APP之后，能看到的界面提取出的功能点，大致包含以下内容：

采集人员

• 注册：采集人员因为涉及的面非常广，开放了注册功能，方便采集人员注册，并且有志愿者和医护人员的区分。

• 登录：

• 选择采集点

  • 大规模时选择采集点
  • 常态化扫描场所码

• 扫描箱码开箱

• 扫描试管码开管

• 扫描身份证

• 封管

• 封箱

• 修改密码：这个功能虽然流程上没有，但APP里面是有的

• 忘记密码

从网上能看到的资料只包含这些内容了，这些只是流程中的第一大块的内容，其它的功能并没有，那我们只能脑补了。

脑补整体流程

我们看到的流程、功能，只是整个平台的一小部分，而且培训视频中的流程图肯定是不完整的，只展示了和采集人员有关系的部分。这个时候如果要把问题提出来，就要会提问题，很多事情看似理所应当，但其实背后有人在背付，比如说，我们在做核酸的时候采集人员会扫描试管码，还会扫描转运箱码。问题来了：

• 试管码、箱码的条码是怎么来的？打印条码的时候和平台有没有关系，是谁负责打印的。

类似的问题还有：

• 采集点的数据很多，这些数据是怎么来的？
• 省市、区、街道、医院机构在注册的时候自动就出来，这些的数据是怎么来的？
• 检测机构和采集人员是什么关系？为什么注册的时候要绑定？
• 转运人员他们的功能是什么？
• 检测机构接收人员看似只做一个操作：接收箱码。那么检测结果的数据也是由检测机构上传的，他们是怎么上传，由谁上传的
• 检测结果是excel上传，是不是什么样的excel表格都可以？
• 检测要产生费用，费用谁出，谁收，费用怎么核算？
• 如果检测出阳性了会怎么办？各级政府工作人员怎么知道检出出了阳性？

这样的问题如果你细想去下能想到很多，这些问题如果放到敏捷开发中，就是用户故事，也可以说是平台要解决的问题。

而且有些问题我们不仅仅要考虑系统怎么做，还要结合线下的工作模式，来设计软件系统如何运行，比如说：

• 采集箱码、试管码是不是随便打印的，打印的时候这些码是不是在数据库里面已经生成了。

经过这些思考和脑补，是可以得出完整的解决方案的，这个方案应该不仅仅包含软件部分，还应该包含线下的工作流程。所以流程图如下：

注意：大家在看流程图的时候也要注意一下旁边的需求说明。

不可见功能

把脑补出的流程总结一下，可以得出如下不可见的功能：

转运人员

• 注册，转运人员同样需要很多志愿者参与，应该也需要注册功能
• 登录
• 扫描封箱后的箱码
• 确认送检

检测机构接收人员

• 登录，检测机构因为专业性较强，同时应该必须是检测机构的工作人员才可以，因些有可能不开放注册功能，而是由平台的运营方分配或有检测机构方分配。我们可以脑补为平台运营人员负责分配
• 扫描转运箱码
• 确认接收

检测机构检测结果上传人员

这类人员有可能和接收人员是一类，但考虑到打印条码、上传EXCEL检测结果等功能还是在电脑上使用更好一些，还是独立出这一类人员。

• 登录，上传检测结果应该是比较重要的功能，必然会有登录，而且帐号一定不是注册的。因为太重要了。
• 上传EXCEL检测结果，上传的EXCEL文件应该有固定的格式，不会随便传什么都能识别。因些应该还有导出/下载数据上传模板功能，同时上传EXCEL功能应该在电脑上使用的可能性更大一些。因此有可能上传EXCEL检测结果并不是接收人员使用的功能。
• 下载数据上传模板
• 检测记录查询/统计，要知道检测机构是要收费的，只不过这个费用由政府买单了，应该会有报表功能来统计检测量，方便与政府进行结算。

平台运营人员

平台不出意外的话应该是一个城市部署一套，那么必然会有一个机构平负责运营、管理整个平台，这个运营方应该是政府某部门负责，从前面几类人员的脑补中其实已经可以推测出运营人员的部分功能了。

• 登录
• 维护检测机构，维护检测机构接收人员、数据上传人员
• 维护采集点
• 阳性报警，这个功能一定会有，不用问为什么
• 数据统计，按检测机构统计检测数量，和钱有关，不用问为什么

非功能性需求

很多工程师在需求调研阶段会忽略这方面的需求，功能性的需求决定了搬代码的工作量，但一个项目值钱的工作量往往是由非功能性需求来决定的。比如说：

• 平台要能够支撑20万人同时在线使用
• 要求服务器崩溃的情况下要在30分钟内恢复，并且终端能够继续采集工作，等服务器上线后自动同步数据。

看到了吗，类似这样的需求随便一条可能就顶得上所有功能性需求开发的工作量。

所以程序员问，如果你将来有幸去做需求调研，一定要做非功能性需求调研。

调研方法嘛，其实很简单，准备一套非功能性需求调研问卷，依次去问就好了，当然在和客户沟通的过程中人家可能会问达到这些需求对应的投入量（时间、资金），你得心里要大概有个数。回头有时间的话我专门写一篇非功能性需求调研问卷的文章，有兴趣的朋友三连不迷路。

对于本项目来说，非功能性的需求我觉得可能会有下面几条：

• 界面整洁大方、不可有娱乐性设计
• 能够支撑一个城市全民核酸时的正常使用。（人口数量从百万到千万不等，差不多是一个量级了）
• 页面影响速度在1.5秒以内。（那边在采集呢，APP不能够一卡好几秒，反应必须迅速）
• 性能稳定、高可用，APP端、服务器端都不能轻易崩溃，能够连续运行12小时以上，为什么是12小时，因为核酸检测人员白天工作，你至少要保证在这白天的时间系统正常运行，如果有问题，在核酸采集休息之后来维护系统。（苦逼吗？程序员的加班就是这么来的）
• 服务器如果崩溃，采集人员APP依然能够开展工作，待服务器恢复之后自动同步
• 服务器崩溃的恢复时间不超过30分钟（时间太长，APP端攒的数据太多，一旦出问题造成大量数据丢失，这个问题非常麻烦）
• 能够支持大部分android手机正常使用
• 安全性方面，可以允许采集端有少量的垃圾数据，但检测结果要绝对安全，不能够被盗取和篡改。居民身份信息、电话信息要严格保密，不可泄漏。

好了，我能想到的可能会有的需求差不多就是这些了。这要求可以说不算低，但是没办法，涉及人员这么多的平台，稳定性、安全性一定是要求非常高的。

不过，我们做为初级练手项目的话，这里面暂时不考虑，或者考虑一小部分。

技术难点分析

如果你是一个自由职业者或老板，接到一个项目的时候，肯定要评估一下一个项目的技术难度，来决定报什么价格和工期。所以这一步应该是说比较重要的。

整个项目单从功能的角度来说，没有什么的难点，除了数据库CRUD之外，也就下面几个技术点了：

• 打印条码，这个说实话自己做的话还是比较难搞的，尤其是在B/S模式下，不过有WEB打印有一个非常好用的东西，叫做lodup。虽然收费，但是拿来做演示程序还是可以的。
• 扫码，这个点一搜索一下就知道，有不少类库能支持，其实扫码就是把码变成个字符串，逻辑也很简单。
• EXCEL导入导出，这个嘛，大名鼎鼎的POI能搞定，也可能用POI的优化框架EasyExcel。
• 手机验证码，这个需要第三方的手机验证码平台，他们都提供有API接口，也不难。

OK整体来看，不考虑并发量、稳定性的情况下，这个项目并没有太难的东西，有难的地方也有相应的第三方组件能够完成。有兴趣的同学，三连我，一起打开核酸检测平台的神秘面纱吧。