“京工飞鸿”是学生事务中心最近推出的一项两校区文件快递服务，依托研究生助管团队，为师生、部门在两校区之间传递纸质文件建立了一个平台。简单来说：我们是免费的快递。

“京工飞鸿”这个名字的历史就不赘述了，我们选这个名字一是适合，二是情怀。点子和名字是有情怀的人想到的，事儿也是一队有情怀的人做起来的。但这里不是要说情怀，联盟上有一个帖子：学生事务中心 正式上线，欢迎大家讨论在学校期间办理事务的痛点难点 ，有兴趣可以跟那个楼主讨论情怀。

这里想说的是“京工飞鸿”那个系统的事儿，倒不是说系统做得有多好，而是想说系统是怎么做出来的，说系统怎么做出来的也不是想写一个技术文章，更想说的是通过“京工飞鸿”、“宿舍管理”、“综合管理”等若干小系统的开发，加上之前多年信息化相关的工作经历……

我更加坚定认为学校的信息化建设买是买不来的，南橘北枳，想做好只能自主开发，而且从技术层面来说，这一点都不难，困难在于想好、控制好自己的需求。

那么问题来了，怎么做？下面是我的做法。

得先有一个规划

下面这图是我到学生事务中心后做的一个规划，借用了李凌的模板，把自己要做的几个小系统嵌入在学校的整体框架里面。通过8个相对独立的小系统（或网站）构筑学生事务中心的信息化体系，为学生提供的服务界面包括网站、微信企业号（飞鸿快递已经可以微信下单）、服务大厅、门禁授权（最近更换完门禁控制器即可实现根据宿舍安排自动授权）、各类自助打印。

学生事务中心信息化建设框架

目前看都在按原计划实施中，待明年上半年全部系统都运转起来后，预计会有非常明显的规模效应。

为什么分这么多小系统？推荐李凌的文章：从构筑大系统，到编写小应用。

整个规划不算小，但我把它分解成多个小系统之后，每个小系统就变得好操控了，都是我一个人可开发、可维护的级别。每个小系统各司其职，都使用单点登录，部署在一起，相互之间数据共享通畅，成为一个有机整体。

“京工飞鸿”是校园服务系统中的一项。此外最近又推出了“代办服务”，就是我们助管拿着学的一堆资料替其本人在两校区、各部门办理业务，最后把结果返回给申请人，比如良乡校区学生公费医疗报销，比如户籍卡借还……在这个系统里，我把网络中心提供的那些“看不见的基础服务层”能利用的都给利用上了，比如与微信企业号的接口、短信网关、一卡通接口，更不用说必须的单点登录。

而实际上，开发这样一个系统，并不比把大象装进冰箱里需要的步骤多，其中最关键的是确定、一定以及肯定地描述清楚：

我到底需要系统做什么？

你到底需要系统做什么？

这个问题的回答，极有可能是：我需要某某功能……；我需要看到这样那样的统计……；我需要这样那样的一个按钮，点一下，然后系统“咔~”就自动怎么怎么了……

这么说道理上也没错，但若要做好一个系统，不能光这样做需求分析，更不能谁都来提需求。我认为需求分析阶段最重要的是分析好系统内部有哪些数据，然后再考虑对这些数据的操作，并且严格控制需求的规模。

关于需求分析的经典笑话

对于“京工飞鸿”来说，核心数据就一个存储快递单的表，实际这个表里面的内容跟我们发顺丰时要填的内容大同小异，除此核心数据之外再定义好快递的状态字典，比如填写、揽件、出发、到达、派件、签收……以及记录好快递状态改变是谁操作的，什么时候操作的。

所谓系统的功能，不过就是对数据的增删改查，并对重要的操作做好记录。大部分信息系统本质上都是如此，学籍管理是最典型的场景。

数据有无标准？

统一的数据标准是多个系统能够共享数据的前提条件，幸好网络中心这方面也已经做了不少工作。如果我的系统需要获取准实时的学生信息（校园服务不需要，但宿舍系统需要），那么按照他们写好的Domain建好学生基本信息表以及证件类型、校区、学生类别等多个字典表，他们就可以很方便给我的系统做数据同步，让我系统里的学生名单和教务处、研究生院系统同步——当然数据准确与否是另一个与技术无关的话题。

标准是个好东西，更好的是前段时间学校推出的信息系统管理办法，以后不遵守这个游戏规则的系统不让上线运行。这和秦灭六国后统一度量衡、统一货币是一个道理。

你确定吗？

“京工飞鸿”运行起来之后，我们想到应该把它扩展成“代办服务”，这的确是个好主意！但快递是顺序的状态切换，而代办服务是有反复并最终要把资料返回给申请人的，快递正常可不需要返回什么。

代办服务状态切换

在平衡利弊之后，我决定把这两项业务分开，不把他们搅合在一起，以便让两种业务未来还有各自的扩展空间。

一个系统运行起来之后，突然要改变某些根本性的结构，对系统的造成的负面影响会非常大，甚于重做一套。但这种情况实际可能很常见，比如调整培养方案结构，增加模块化等新概念。“杀一个程序员不需要枪，改三次需求就可以了”

开发过程其实相对简单多了

按照上面思路，在确定、一定以及肯定地描述清楚好系统中的数据之后，开发就很容易了。

新建项目，配置好网络中心的各种基础服务插件，在定义Domain即数据表之后，使用脚手架就已经实现了基本的增删改查，整个过程用不了半小时。

在基本增删改查基础上，根据需求，定义好Views和对应的Controllers，把用户和权限管理交给CAS和Shiro……我真正需要做的只是去实现业务逻辑。

最后把代码push到bitbucket上，配置好的jenkins会自动下载打包发布到docker服务器上……

一个这样的系统一两周也就弄出来了。

不需要维护服务器，不需要考虑网络安全问题，这一切都是网络中心提供的基础服务，远比自己做得更好更专业。

最后

把我和李凌导论问题时他经常作为当开场白的那句话作为结尾

“你想要干什么？”