Author: geneblue
Blog: https://geneblue.github.io/
这并不是一份正式的项目总结，只是我们在做完自行车备件管理系统后我的一些心得。觉得有必要写一下记录自己在这个项目中犯过的错误。
这个项目是从大三上学期刚开学的时候接手的。这个备件管理系统相对研究生学长做的道路滑坡预测比较简单，老师就将这个项目交给我们四个啥都不太懂的本科生做。说实话，大家都挺积极的，至少可以明白最简单的商业项目是怎么一回事。
要做的东西不是很难，这个备件管理系统主要就是完成移动端（Android）应用和后台管理系统的开发。移动端主要是完成备件从采购、入库、使用、维护、维修和报废一系列操作，需要按照操作人员的角色设定操作权限，然后将数据传输到数据库中；后台管理系统主要是使用java和jsp开发网页版程序对数据库中的数据进行管理，差不多也就是数据库的那几种基本操作。
在项目前期，对方让我们写一个可以使用的手机端的应用，没有考虑让我们做全部的工作。我们有java和Android的一些基础，所以手机端的应用很快就赶出来了，后台就是一个简单的接收手机端数据并存储在数据库中的一个小程序，对方的技术员说使用手机端应用的人员也不多，后台数据接收不用考虑多线程并发了，简单一点就好。于是我们相信了鬼话，在第一次和对方的经理的见面沟通后，对方觉得我们做的还不行，后台管理系统还是要完善地做出来，移动端应用太单一了。让我们照着计划书实现所有的功能。好吧，于是小伙伴们加班加点地边学边做，直至现在基本把这个项目完成。这里，我就不详细介绍项目的实现过程了。无非也就是根据要求整改，整改后让对方经理看看行不，再根据新要求整改。在整个项目过程中，我自己对开发工作有了一些认识，也认识到自己的代码功底还是很low的。以下总结认识到的几点问题。
数据库的设计
不知怎么回事，我们专业在大三下才开数据库相关的课程，本身对数据库的认识也比较少，使用到的时候只能从google上找一些示例来看一看，然后就上手设计数据库了。到项目中后期的时候，才发现数据库的设计太不符合基本规范了，没办法只能将数据库大整改并将与数据库交互部分的代码重新改写。唉，在做一件事情之前花点时间了解一些基本原则真的是很有必要的。本学期开了“数据库及安全”这门课，看来是不能怠慢了。这里顺手贴个数据库设计的基本原则，方便自己查看，等学了数据库及安全这门课再深究。
整体框架设计
整体的框架设计是和另一个小伙伴的争论中确定的，结果采用这样的设计是注定要造成代码冗余的，但当时没考虑太多，怎样简单怎样顺手就怎样来了。基本的架构图如下所示：
也就是说移动端和后台web管理端都实现了与数据库交互的部分，当时的理由是各自写各自的比较省心，一直保持数据库DB一样就行。我一直觉得稍微合理一点的设计应该是：
将与数据库的交互部分单独写出来，这样在更改代码的时候也会方便快捷一点。
代码冗余
整体系统的设计就已经决定了代码冗余是必然存在的，各自实现的一套数据库交互在后期也带来了重复性的修改工作。自己埋下的苦果自己吃呗！而且在web管理端，我也没注意将相似性的代码写成父类，使用子类去完成不同的工作。现在看看写的代码，真觉得自己是路漫漫呀！
设计模式
可以说这里基本没用到什么设计模式，软考时看了看一部分设计模式，头脑中有大概的印象，现在早就抛掷脑后了。还好也算是明白了在软件设计中，什么才是重点。设计模式的缺失，让这个系统代码的可维护性和可扩展性很差，估计也就我们几人能很快上手我们的工作。
结语
在工程项目中，重要的真不是代码，而是在整个项目开始实现前的构思和设计。稳健的项目设计真的会让整体项目工程事半功倍。好像还有点什么，嗯，等以后想到了再写吧！