团队项目饱了么——个人总结

需求分析：https://www.cnblogs.com/Clover-yee/p/11771395.html

详细设计：https://www.cnblogs.com/Clover-yee/p/11882669.html

原型设计：https://www.cnblogs.com/Clover-yee/p/11934420.html

会议记录1：https://www.cnblogs.com/Clover-yee/p/12045955.html

会议记录2：https://www.cnblogs.com/Clover-yee/p/12045997.html

web展示：http://ylnzk.cn:8081/BLM/index.html

web前端Github：https://github.com/Ceilzcx/blm

web&app后端Github：https://github.com/Clover-yee/blmAPI

app前端Github：https://github.com/startproge/baolema

ios端：https://github.com/wamgsongg/baolm_ios

数据库：https://github.com/wamgsongg/baolm_db

 

一、项目概述

1.1 需求回顾

　　针对高校内就餐高峰时段风味餐厅人流量大导致部分学生选择订外卖的现象，“饱了么”系统致力于为高校学生提供提前校园内风味餐厅提前预定服务，缓解就餐时段的风味档口的人流压力，同时减少校外外卖预定，保证学生舌尖上的安全，同时，“饱了么”通过评分评价机制，提高商家的竞争意识，改善餐饮服务水平。

 

1.2 知识储备

　　由于项目需要实现app-mysql-web之间的信息交互和前端操作，所以需要前端设计、数据库操作、后端业务处理等基础知识，前期要求项目组成员至少需要熟悉一个方面的知识。

 

二、项目个人总结

2.1 工作概述

　　在本次团队项目中，我被分配为处理web后端业务逻辑。

 

　　2.1.1 需求分析和详细设计阶段

　　在项目前期我们小组在第一次例会上具体分析了项目需求和业务逻辑，基本确定了每个人的分工，由于之前我只接触过php，对网页后端的业务处理有一定的了解，所以小组同意我负责web后端，和前端程序员约定web开发用jsp+servlet+hibernate+mysql为主体框架，采用MVC模式，并且约定好具体的功能和前后端接口。数据库采用mysql腾讯云数据库，项目部署到阿里云服务器上，变量采用驼峰式。

　　因为对jsp和servlet不太熟悉，所以前期我也花了一定时间熟悉jsp和servlet的处理机制，因为之前的php开发经验，所以学习起来还不算困难，在编码阶段前已基本了解jsp和servlet的主要内容。

 

     2.1.2 编码阶段前期（demo检查前）

　　这段时间内我基本实现了后端操作数据库的dao层和处理基本业务逻辑的service层，并且开始编写servlet处理前后端数据交互，但是在本阶段我们组项目的最大问题开始暴露——在数据量还不算大的情况下，网页的信息显示速度就非常的慢，在排除数据库性能、网络传输和硬件性能的原因后，基本确定是由于后端采用hibernate使得在数据库查询后需要将数据库记录实例化，然而用hibernate查询和实例化虽然编码实现容易，但是在查询后的结果集持久化对象化的过程中需要大量的开销，而且hibernate映射的关联也非常的多，相当于每次查询都在进行子查询，而前端需要的信息又往往很少，导致消耗的时间大部分在dao层上，显示的速度就非常慢，用户体验非常的差。

　　在对模块功能进行测试的时候，我们发现网页的CSS渲染有时候会失效，通过分析，我们发现是因为jsp实际上在运行过程中被翻译成了servlet，有时候会受到tomcat缓存的影响，有时会出现找不到路径的情况，debug过程相当痛苦。

　　同时，采用jsp+servlet+hibernate+mysql这种框架并不能实现前后端的真正分离，配置也相当麻烦，在编码阶段中前后端程序员还是得参与进对方的编码内容，后端需要处理页面的跳转和信息的传递，前端获得的并不是请求的数据而是对象，jsp需要通过JavaBean获取信息，前后端的耦合度还是太大，有时候我和前端程序员会因为对需求的不同理解而产生分歧影响项目进度。

　　在和app后端程序员交流后，我们发现其实app后端和web后端的部分业务存在重复，可以共享部分代码，而且app后端采用springboot，速度相对较快，编码也更加容易。在demo检查完后，在总结老师的反馈结果和小组成员的一致同意下，我和web前端程序员放弃jsp+servlet+hibernate+mysql，果断采用html+ajax+springboot，由于springboot又是新知识，我花了半天的时间速成springboot后投入到新的编码阶段。

 

　　2.1.3 编码阶段后期

　　编码后期，由于我和app后端程序员共同编辑同一份代码，所以我们两个的Github版本控制相当重视，为了和app的数据传输格式保持一致，web数据也采用base64。

　　后期最大的困难是图片存取问题，后端springboot无法接收前端传过来json数据，导致图片成为我们项目进度的瓶颈，在查阅了大量的资料后，我发现需要前端ajax将数据打包为FormData，后端用HttpServletRequest接收才能正确接收json包。但是得知前端数据显示还是较慢，为了减少读数据库的读取，我们用缓存机制处理数据交互，尽量减少对数据库的读操作，提升性能。

         

 　　在讨论数据传输问题后，我们约定对一些业务判断逻辑前后端可以采用状态码来进行判断，根据状态码来决定是否进行信息反馈和数据库读取，这也是一个减少信息交互处理的方法。

　　后期我主要编写Controller层和dao层，处理前端请求，这时我和前端程序员才真正实现前后端分离，我不必关心前端如何实现，我只需要和前端程序员约定好接口处理请求便可以，这时期我们的意见也趋于统一。在验收前我们web组合完成了功能实现和优化，并进行了大规模测试。

       

 

2.2 工作小结

　　在编码前期，我工作的重点主要在实现具体的功能上，向前端传送数据。而后期我主要从事性能优化，和前端程序员和app开发人员交流实践具体的优化策略，争取提高用户体验。

 

2.3 项目反思

　　在老师验收后，我和其他一些下午班的同学交流的过程中得知，我们的“饱了么”系统其实可以采用分布式架构，数据读取过慢的情况是由于处理请求需要读取磁盘，对此可以用redis缓存数据记录，由于redis是基于内存的，如果每次是读取redis而不是mysql，速度会大大加快，可以根据局部性原理在请求不太繁忙的时间段内在后台自动将MySQL中的高访问的数据记录动态的读入redis中，这样就能解决加载缓慢的情况。

　　“饱了么”需要处理实时订单，我们处理实时是通过每5秒固定请求服务器查看是否有新订单产生，有则返回，其实这可以采用Kafka实现实时通信，Kafka是一种高吞吐量的分布式发布订阅消息系统，对于像“饱了么”这种高并发和实时性要求较高的系统，使用Kafka正合适。

 

2.4 项目总结

　　这次软件工程团队作业我的收获很大，之前网页后端处理我只会用php实现，通过这次大作业，我不仅学会了jsp、servlet、springboot、json等新技术，也学会了如何比较各种技术之间的优劣选择更适合的技术来实现自身的需求，更重要的是深刻体会到实现功能不是最紧要的，提高用户体验让用户满意才是至关重要的。

　　同时，收获最大的还是走了一遍软件工程的流程，熟悉了软件开发的具体阶段，感受到了软件工程中的一种无以明述的乐趣。在整个流程中，我学会了如何协调团队任务，如何处理团队分歧，以前做项目发现问题总是一个人闷头苦干，现在开始学着去交流促进，取长补短，而且，软件工程的最大好处是让我们发挥自己最大的优势，我们不用学的多学得杂，我们需要学得精学到实处，人尽其才，使我们的项目得到肯定。也许我们也走了不少的弯路，但终究锻炼了我们的能力。

　　能和优秀的人一起合作，这也是一种快乐。虽然自己不是最优秀的，但是靠着自己和大家的努力，我们让整个团队更加优秀。

 

三、课程建议

3.1 坚持推广

　　希望老师能在以后的《软件工程》教学中继续推广构建之法，对于软件工程这种实践要求较高的课程，至少走一遍流程是必须的，而且这可能是我们大学阶段仅有的真正实践软件工程思想的机会，通过这门课帮助更多的计算机专业的学生感受软件工程的乐趣。

 

3.2 坚持自由组队

　　针对有些小组完不成项目的现象，老师可能在犹豫以后是否要安排随机组队，我的想法是千万不能随机分配队伍。首先，随机分配可能让一些不熟悉的人组成团队，导致在设计开发阶段无人响应而组长疲于奔命，有问题没人解决，最终拖死一片；其次随机分配会使得优质资源被打乱，部分学生的能力相对突出，他们肯定不想和能力不跟自己在同一条线上的学生一起合作，而水平较差的学生可能会将希望放在核心程序员上而自己水过去，这就违背了老师推行构建之法的初衷，只有能力水平差不多的学生组成一个队伍，在合作中才会产生火花，才会各尽其才，尤其是对于一些强强联合的小组，他们也许会有一些与众不同的想法，这些想法可能会值得我们所有学生和老师学习借鉴，我想这也是一种收获，而水平参差不齐的学生组成的队伍往往无法使得能力强的学生发挥他们应有的水平，老师应该也不想看到千篇一律没有亮点的作业吧。

 

3.2 老师参与

　　我们上午班老师参与的比较多，但是我觉得还是不够，这样说可能不太合适，但还是希望老师在每个阶段结束后详细的听取每个小组的汇报，虽然老师每次都查看每个小组的博客，但是博客的内容终归不会太完备，在这次实战中我们可能走了很多自己都没发现的弯路但自己没有发现，如果在每个阶段结束后老师都能听取指导每个小组的汇报，很多问题都会尽早暴露，不会最后积重难返，对于一些情况特别严重的小组，也能尽早想出相应的解决对策。所以希望老师能将将软件工程的实战周期再延长几周，虽然老师压力可能会非常大，当然只是建议老师可以当我是胡说八道。