前言
跨校区递送文件一直是多校区学校师生生活的一大问题。等班车两校区奔波耗时耗力？无法准时送达压力山大？多次往返奔波无果？最近，北京理工大学基于此推出跨校区快递服务应用——“京工飞鸿”。
了解北理工历史的人会知道，北京理工大学原名北京工学院，简称京工，1997年，北京理工大学网络中心创立“京工飞鸿”——北理工第一个校内官方BBS论坛，现已关闭。如今，京工飞鸿又重新出现在大家面前，作为中关村校区与良乡校区之间服务于师生之间最专业、最贴心、最高效的快递，历史总是这样，一棒又一棒的交接。
“京工飞鸿”是怎么做出来的？
文 | 康慨
“京工飞鸿”是北理工学生事务中心最近推出的一项两校区文件快递服务，依托研究生助管团队，为师生、部门在两校区之间传递纸质文件建立了一个平台。简单来说：我们是免费的快递。
“京工飞鸿”这个名字的历史就不赘述了，我们选这个名字一是适合，二是情怀。点子和名字是有情怀的人想到的，事儿也是一队有情怀的人做起来的。但这里不是要说情怀，联盟上有一个帖子：学生事务中心正式上线，欢迎大家讨论在学校期间办理事务的痛点难点，有兴趣可以跟那个楼主讨论情怀。
这里想说的是“京工飞鸿”那个系统的事儿，倒不是说系统做得有多好，而是想说系统是怎么做出来的，说系统怎么做出来的也不是想写一个技术文章，更想说的是通过“京工飞鸿”、“宿舍管理”、“综合管理”等若干小系统的开发，加上之前多年信息化相关的工作经历……
我更加坚定认为学校的信息化建设买是买不来的，南橘北枳，想做好只能自主开发，而且从技术层面来说，这一点都不难，困难在于想好、控制好自己的需求。
那么问题来了，怎么做？下面是我的做法。
▼
得先有一个规划
下面这图是我到学生事务中心后做的一个规划，借用了李凌的模板，把自己要做的几个小系统嵌入在学校的整体框架里面。通过8个相对独立的小系统（或网站）构筑学生事务中心的信息化体系，为学生提供的服务界面包括网站、微信企业号（飞鸿快递已经可以微信下单）、服务大厅、门禁授权（最近更换完门禁控制器即可实现根据宿舍安排自动授权）、各类自助打印。
（学生事务中心信息化建设框架）
目前看都在按原计划实施中，待明年上半年全部系统都运转起来后，预计会有非常明显的规模效应。
为什么分这么多小系统？推荐李凌的文章：从构筑大系统，到编写小应用。
整个规划不算小，但我把它分解成多个小系统之后，每个小系统就变得好操控了，都是我一个人可开发、可维护的级别。每个小系统各司其职，都使用单点登录，部署在一起，相互之间数据共享通畅，成为一个有机整体。
“京工飞鸿”是校园服务系统中的一项。此外最近又推出了“代办服务”，就是我们助管拿着学生一堆资料替其本人在两校区、各部门办理业务，最后把结果返回给申请人，比如良乡校区学生公费医疗报销，比如户籍卡借还……在这个系统里，我把网络中心提供的那些“看不见的基础服务层”能利用的都给利用上了，比如与微信企业号的接口、短信网关、一卡通接口，更不用说必须的单点登录。
而实际上，开发这样一个系统，并不比把大象装进冰箱里需要的步骤多，其中最关键的是确定、一定以及肯定地描述清楚：
我到底需要系统做什么？
▼
你到底需要系统做什么
这个问题的回答，极有可能是：我需要某某功能……；我需要看到这样那样的统计……；我需要这样那样的一个按钮，点一下，然后系统“咔~”就自动怎么怎么了……
这么说道理上也没错，但若要做好一个系统，不能光这样做需求分析，更不能谁都来提需求。我认为需求分析阶段最重要的是分析好系统内部有哪些数据，然后再考虑对这些数据的操作，并且严格控制需求的规模。
（关于需求分析的经典笑话）
对于“京工飞鸿”来说，核心数据就一个存储快递单的表，实际这个表里面的内容跟我们发顺丰时要填的内容大同小异，除此核心数据之外再定义好快递的状态字典，比如填写、揽件、出发、到达、派件、签收……以及记录好快递状态改变是谁操作的，什么时候操作的。
所谓系统的功能，不过就是对数据的增删改查，并对重要的操作做好记录。大部分信息系统本质上都是如此，学籍管理是最典型的场景。
▼
数据有无标准
统一的数据标准是多个系统能够共享数据的前提条件，幸好网络中心这方面也已经做了不少工作。如果我的系统需要获取准实时的学生信息（校园服务不需要，但宿舍系统需要），那么按照他们写好的Domain建好学生基本信息表以及证件类型、校区、学生类别等多个字典表，他们就可以很方便给我的系统做数据同步，让我系统里的学生名单和教务处、研究生院系统同步——当然数据准确与否是另一个与技术无关的话题。
标准是个好东西，更好的是前段时间学校推出的信息系统管理办法，以后不遵守这个游戏规则的系统不让上线运行。这和秦灭六国后统一度量衡、统一货币是一个道理。
▼
你确定吗
“京工飞鸿”运行起来之后，我们想到应该把它扩展成“代办服务”，这的确是个好主意！但快递是顺序的状态切换，而代办服务是有反复并最终要把资料返回给申请人的，快递正常可不需要返回什么。
（代办服务状态切换）
在平衡利弊之后，我决定把这两项业务分开，不把他们搅合在一起，以便让两种业务未来还有各自的扩展空间。
一个系统运行起来之后，突然要改变某些根本性的结构，对系统的造成的负面影响会非常大，甚于重做一套。但这种情况实际可能很常见，比如调整培养方案结构，增加模块化等新概念。“杀一个程序员不需要枪，改三次需求就可以了。”
▼
开发过程相对简单多了
按照上面思路，在确定、一定以及肯定地描述清楚好系统中的数据之后，开发就很容易了。
新建项目，配置好网络中心的各种基础服务插件，在定义Domain即数据表之后，使用脚手架就已经实现了基本的增删改查，整个过程用不了半小时。
在基本增删改查基础上，根据需求，定义好Views和对应的Controllers，把用户和权限管理交给CAS和Shiro……我真正需要做的只是去实现业务逻辑。
最后把代码push到bitbucket上，配置好的jenkins会自动下载打包发布到docker服务器上……
一个这样的系统一两周也就弄出来了。
不需要维护服务器，不需要考虑网络安全问题，这一切都是网络中心提供的基础服务，远比自己做得更好更专业。
▼
写在最后
把我和李凌讨论问题时他经常作为当开场白的那句话作为结尾
“你想要干什么？”
后记
把信息化建设的宏大概念抛在脑后，用心去感受那个微小却让人感到暖心的服务，你，听到情怀落地的声音了吗？对于大部分用户而言，他们从来不了解教育信息化是什么，只关心我要做的事情是不是更简单更高效的做成了。
康老师的原文最后有一条用户评论说：“看到 cam 里预置了失物招领模块，希望能够跟阳光服务队当前的服务结合起来，要是能做到丢卡被捡，马上企业号推送提示失物人，就是最高境界了 :-)”
愿信息化永远能给你的生活带来惊喜。
| 本文作者 |
以上内容获授权转载于
康慨老师简书账号“要多做”
原文出处请点击阅读原文
可能你对以下内容也感兴趣