小组成员: 202031101668 许正韬; 202031101554 鲁小东

TEEE（Task Easy Edit Exploration） 学生作业管理系统

        项目仓库地址：Sign in · GitLab

        技术架构：

        

        项目逻辑架构设计:

        

 总结：

        通过这次web项目的开发， 我们小组学习、了解了B/S模式应用的组成结构，熟悉了Web项目的运行流程。因为这这次是我们第一次做小组合作开发项目，我们深刻体会到了到了小组成员之间交流、合作编码会遇到的问题，藉由此意识到了模块化编程的意义。同时，我们也认识到了 需求文档、设计文档 在项目开发活动中的重要指导意义，体会到了 先设计，再开发 这一设计理念的优越性。

期望：

        项目总体设计方面：希望以后的设计过程中，能先考虑总体架构，再自顶向下的考虑各部分的细节。在总体设计上多花时间思考，到后期只需要对下层子模块逐一精化，而不会出现因总体设计缺陷，导致功能无法继续添加， 需重构大量架构上的设计。团队管理方面：因为团队成员缺乏有效沟通，导致负责不同部分的人开发进度不同，以后要尽量更合理的安排成员工作 

---

 

回顾梳理一下整个项目的生命各阶段中的决策: 

         立项阶段：

         A) 明确需求: 任务要求中明确了项目类型为 作业管理系统，即核心功能应包括用户控制模块（区分教师学生身份以提供对应的功能） 、教师布置作业，批改作业、学生完成并提交作业。

         B) 初期的技术选型：

        语言方面：考虑到是做Web服务端应用，所以在C++和Java中选择了封装程度以及市面上框架支持更完善的Java语言。在Java和go中考虑到语言学习成本以及为了降低项目进度的无法完成的可能性，选择了Java。

        后端架构：在Spring全家桶框架和纯手写Servlet、filter和listener中选择了后者。基于以下几点考量：

        1、Spring MVC虽然号称轻量级框架， 但是以目前的需求分析上来看，我认为使用框架对于实现核心功能的实现来说过于浪费的、臃肿的（事实上我当时并不了解具体封装的功能内容， 仅仅是因为见到过许多Spring项目功能的复杂而得出的结论）

        2、出于学习的角度考量，我认为尽可能的自己尝试使用基础工具来搭建项目，相比于直接使用完整的框架，更能清晰的学习、理解Web项目的运作流程。

        3、染上了对重复造轮子这种愚蠢的事情情有独钟的病 o(￣ヘ￣o＃)

        前端：原生JS + HTML5。使用的是非常传统的css+div布局，也是考虑到学习成本的原因，因为很久很久以前接触过这种布局设计实现方式，相比于学习新的前端框架(别说Vue了， 连JQuery都给我列为新框架了...)，我认为这样成本会低一些（后续的事实证明了这种想法蠢死了并不正确）

        持久化层：数据库选择了MySQL， 老古董Sql Server自然是不要的，因为当时数据库课程学的是关系型数据库，选择MySQL可以顺带作为复习，一举两得了属于是。当时听说过 NoSQL， 但没有具体去了解，认知仅停留在其并非关系型数据库这一层面上，害怕搞不定，所以放弃使用了（noSql这个缩写真的很容易让人误以为是“没有数据库”.......我第一眼看到的时候给狠狠吓住了, 还以为是什么高科技，让服务商直接略去了数据持久化储存的环节......）。

       初步动手阶段：

        此时发生了本项目开发中我们小组做过的 最大的 最错误的事情（我全责）：严重的忽视需求文档、设计文档的重要性，这是我去年做过的最蠢的事情之一。

       拿到了需求，分配了各个成员的任务后，我立刻开始了动手编码。我们虽然经历了需求讨论阶段，根据此完成了一份需求文档，但是这份文档在被当做第一份作业提交上去之后，立刻在我们这里失去了作用，因为后面看都没看他一眼。在前期，因为只涉及到登录、跳转页面等功能， 我们很快完成了原型（看到自己做出来的页面设计我都在考虑要不要转行去抢美术生的饭碗，简直艺术大师），效果甚是满意。

        但是做着做着，突然不知道该怎么做下一步了。登录跳转了，然后呢？怎么布置作业？要不要给学生分班？要不要分专业？老师怎么知道哪个作业是哪个学生教的？学生怎么得到反馈？

       完成设计文档，重构项目结构：

        由于对整个系统的业务流程的把握并不清晰，导致系统的功能一直是修修补补的状态。牵一发动全身，一个系统功能的修改很可能会导致数据库关系的重构。同时组内交流不及时也是一个问题，在某一个功能的实现上面， 如果同时由多个人来完成，则处理逻辑上很可能出现很多杂乱无章的、混乱的地方。对此我们紧急修改了一下分工模式，前后端分离， 数据库和后端设计分离，同时在群内发布了一个在线文档， 用于整理前后端、后端与数据库交互的数据字典以及接口声明

   完事之后稍微好了不少， 但是屎山已经堆起来了，面对了一个两难的境地。全部重构？要那样搞估计得累的没心态了。放弃维护？反正是一次性的项目嘛，能跑就行？本着摆烂的心态选了后者----这是第二个严重的战略失误。导致的后果是，新功能，直接加不上了。

后续我们打算添加一个作业截止时间限制的功能，结果，由于表结构过于臃肿， 项目结构混乱，导致我看着我的代码，已经不知道如何下手是好了。

面对几乎不得不重构的代码，到了这个阶段， 我们小组心态上已经有不少消极的变化了。

我把重构项目结构这一任务分配了一整周的时间，前面五天，仔仔细细的考虑了项目整体设计，绘制了UML，表的ER图也几乎回炉重造,  周末的时间， 忍痛删掉了逻辑不通但是写的时候蛮累的的狗屎代码、改掉了命名规范风格不一致的变量和字段，终于解决了这个大问题。

整理完之后发现，前面写的代码，20%是冗余的，20%的是恶心未来的自己用的

         后续添加更多功能:

          项目的核心功能完成，业务逻辑也能跑通了，心情舒畅。多出来不少时间， 就想试着搞一搞其他的东西。听说Vue很好用，饿了么的Element-UI库也不太难，就想着能不能试着做一下。我在项目中新增了一个页面文件夹，用来写管理端的前后端，以做到不干涉已完成的核心功能的目录。

        由于网上的Vue项目大多会使用NodeJS支持， 但是我不太希望引进可能对原本项目造成破坏的变动，遂决定采用最原始的借助cdn在html中引入vue.js的开发方式 。奈何此等操作过于非主流，这样的笨方式网上资料甚少，遇上问题就抓瞎。

        但是用了框架后的开发效率让我真的大吃一惊。仅仅使用了不到一周，就完成了管理端的前后端开发（当然主要归功于项目结构修改后可扩展性增强了），并且样子还蛮好看。

        这时回想起当初使头铁，使用原生JS+HTML，每天盯着像素点设计按钮的长度，用一个一个DIV来拼接想要的区域，研究不同网站的配色......不知道的还以为我学的是UI设计。慢慢地开始明白为什么使用轮子会这么受大家欢迎了。Web应用不是美术作品。页面设计的确很重要，项目结构的确很重要，但是最重要的，一定是用户的使用体验，是系统处理业务的能力。将有限的精力用于舍本逐末，结果难免不如人意。           

总结 

 第一、多想，多设计，想清楚再动手

 第二、站在巨人的肩膀上，能更快并且更好的达到你的目的

 第三、及时的团队交流，及时的止损，不要放任臃肿的甚至错误的代码存在，这只会让后面的路寸步难行！