项目时间线：
我们于3月28日，参与到《积分管理》项目的原型图的设计之中，在学校的时光一眨眼就过去了，项目的进展却不是很大，于5月18日的时候，综合各种原因，我成为了此项目的负责人，从此肩上多了一份责任，然后又经历了学校的各种事情，闭组时间，最终到了暑假第三周开头，此项目中途结束。
我负责的模块：
- 负责pc端考评模块前后端
- 后来又接手了一个半成品的活动模块，包含pc前后端和app前后端。
我的反思
来到暑假之后，学长给了我们两周时间，感觉效率比学校高很多，时隔一个多月，当重新看到这个项目的时候，很多地方都忘了，前端还是什么都看不懂，但是还是需要往前死磕，最终还是一路慢慢走了过来，我的总结就是，这个项目其实从暑假才开始写。
如今项目中途被停，反思原因如下：
1、我们团队每个人都没有经历过一次完整的项目生命周期，导致步步受挫：
- 比如原型图不会写，也没经历过，也没见过别人写，写的时候坑坑巴巴；
- 比如数据库不会设计，没有经验，无法把握项目整体的需求，也就无法根据需求精确建表，这导致我们在最近都还在讨论表的字段问题；
- 这个项目相当于是我们要解决学校的积分管理问题，我们根据学校的这个使用场景自己去构想了一些需求，可能是因为本身项目性质的不同，也可能是没有专业的产品经理，导致需求制定的并不明确，它甚至有一点创造性的元素，需要反复一直的讨论需求，本来我们就没有经验，还遇到这样不稳定的需求，就更加混乱；
- 到了写项目了， 项目组五个人，只有学长会写接口，四个人摸不到头脑，如果是我的话，我会把gosword框架讲一下，以及该如何使用，学长也确实给我们讲了，但是把“学会的知识”表述出来，让其它人能学会是一个技能，很遗憾，学长很尽力，我们却听的晕头转向。 那就只好还是我们自己去研究了，死磕了1-2个星期，才算是会写接口了，然后把团队里还没跟上的同学带一带，讲一讲，算是理解一些东西了，然后就开始了漫长的写接口之旅。
- 接口写完了之后，该写pc端页面了，这次更绝，面对crud框架，项目组五个人都是一脸懵，模仿着已有的页面，先把静态页面写好了（其实也不知道什么意思），然后尝试了一下，发现实在看不懂，用不了框架的东西，打算自己写，刚写了一点就闭组了，然后暑假来了之后，死磕了两天的时间，突然豁然开朗，能看懂前端框架里的东西了，写起来就一帆风顺了。
2、 技术栈缺口太大
- 后端的基础薄弱点在于redis，mysql以及脚手架
- 前端的薄弱点在于脚手架
最基础最主要的是脚手架，我们的pc前后端都用的是gosword框架的内容，但是uniapp却是从零写起，这就需要写全局拦截器，加token等问题，但是我从来没做过这事，也没了解过，让我在uniapp的初期很受阻，最终虽然是能接收到接口了，但是完全没有封装，写了很多的冗余代码。
3、管理经验不足
不知道什么时候该干什么，不知道什么是好的项目负责人。
4、数据库管理，接口管理不规范
- 我们在项目开发的过程中，常常会遇到要写某一个接口，不知道要去查某个表，因为表的字段不是很完善，注释也不是很明确，甚至某个字段到底是什么意思，有的时候也会分不清，这就说明了注释的重要性。
- 接口的注释不完善，调用他人接口的时候，需要耗费时间调试。
我的收获
1、 收获了前后端的知识
前端硬是在实践中入了门，但是积累的还太少，下次如果遇到更复杂的场景，这点积累不够用，还是需要更详细，全面的了解一下前端，以及一些用法和规范。
后端从gin几乎0到如今gin框架入门，但同样的是速成带来的是底蕴不足，后劲不够，还需要详细的了解一下。
2、 收获了如何部署以及配置https
- 从了解docker和nginx到最终能够把docker和nginx结合起来把项目上线
- 从了解https，到最终把小程序也部署上线
还写了两篇文章，为什么要写这样的文章呢？因为在我学习的道路上，我特别希望能多一些这样的文章：
https://blog.csdn.net/qq_29582443/article/details/118970397
https://blog.csdn.net/qq_29582443/article/details/118975798
未来的展望
1、 充实技术栈——mysql，redis，casbin
2、深度一些技术和工具——nginx，git，日志
3、搭建前后端脚手架
4、了解压力测试与代码优化
