科研管理系统项目总结

项目总结

技术方面

1. 前期对 el-admin 了解不够，没有在给定的时间内达到相应的框架了解程度，后端的API重新制定跟咱们的需求不太明确也是有着一定的关系，前期--预备工作--做得不充分
2. 个人方面 - 以往知识点的不足
   1. vuex程度不达标，是到项目上 进行了复习后才写出了相应的代码功能
   2. element-ui的初体验，以前只是完成阶段任务的时候简单接触过bootstrap样式库，这次等于说是第一次正式接触第三方组件库，了解了 :: 深度选择器.....
   3. promise的async/await。 虽然当时的问题是用loading解决了问题
3. 个人方面 - 新的知识面的拓宽
   1. 关于element - admin 框架前段数据获取方面的一些新方式（提前定义组件，然后通过 ‘混合模式’ 引入默认方法和重写特定的方法，在通过特定标签，动态获取参数）
   2. 前段项目知识补充
      1. 前段框架上的一些知识缺乏， 像router中的一些获取操作，以及cookie，
      2. vuex-store数据获取时机。
      3. 动态router的简单认识（router的权限管理）
   3. 项目开发工具上的准备不足， 临时搭起的vscode环境，很多东西和配置到现在还没弄明白，以至于现在屏幕上还是一堆堆的红。
4. 个人方面 - 遇到的问题
   1. 最开始的 vscode 环境的搭建， 因为要适应开发规范，一些ESLint和vueter的一些配置还是没有弄好，以至于现在vscode还是一堆堆的报警告
   2. 引用的组件的样式个性化修改，通过百度 -> 深度选择器 :: v-deep
   3. vuex 事件。提交vue生成的监听对象 需要转化成普通的 JS 对象 -> 先通过 转jason -- 再转 JS 实现
5. Mook 的使用 ---- 以往接触的项目都是API先行，一般我们界面写完进行接口测试的时候，都是可以直接测试的，但此次项目因为某些原因，没能做到这点，接口测试没有等到真实的接口，当时想要去进行mookJS，但是还是没有学会，现在不知道怎么使用。

非技术方面

1. ​ 整体方面
   1. 细胞组内交流，咱们的组内交流在频率上其实超过了其他两个细胞小组，还要保证及时性，因为这次我们PC端运用的是分模块完成需求的方式，发现问题后及时和组内相应负责人沟通联系。
   2. 同步会议， 一起把问题抛出来（能给项目按期完成 -- 提供一个很好的保证），然后根据大家的时间分配和计划，进行问题的再分配。
   3. 端到端 交流 有些时候，直接找对应端项目负责人沟通效果可能会更好。
   4. 越级沟通， 理应直接负责人间沟通解决的问题，却因为个人原因（距离，坐的比较近）私下直接交流。
   5. 工作-问题记录：因为公共组件的改变，会影响到其他人的工作，尽量将这些东西都放在一块，建立一个公共的文档，进行 问题 / 问题解决 的公开化
2. 个人方面
   1. 接触了新的框架，知识方面肯定有这广度的提升，虽然框架并没有去全部吃透（基本上只是研究了自己运用的部分，以外的部分很少去看）
   2. 提前对-框架了解和项目需求的 ==结合点==，一些没有提前进行，好比当时的 crud的相应格式，导出接口的放回形式， 都没有做到提前去了解这些东西 并和API在 码代码开始前进行确定，而是等其他部分做完，这些事情到了眼前才去和后端进行沟通，交流、定格式。 而且都是进行 私下的交流，感觉这些放在以往的项目中，进行一些1:1的接口对接，可以进行私下的进行。但这次项目中，很多接口形式上都是项目，只是返回的数据不相同，有点时候，前后端彼此两人进行了接口格式确定，但却造成了其他人的形式不太一样，后期再发生“统一格式”这种修改 ‘’已完成功能‘’ 这种完全可以避免的时间上的浪费。
   3. 彼此之间的分工 。
      1. 因为分模块分工，不可避免的造成了这样一个问题，API：“你们PC端的XXX有问题，你看一下啥问题，咱们对接一下”。我：“？哦，这部分是XXX进行负责的，我没写那部分”。这种情况不可避免，可能说是必须的，因为项目时间上限制，我们大可不必每个人都进行弄透各个部分的内容，但若是有精力的话，还是要简单了解具体实现。更多的是要项目结束后进行复盘行的学习.
      2. 彼此之间的协作，一人有问题，大家都来帮忙。彼此是一个团队，其他人出现了解决不了的问题，互帮互助是最基本的保证。像最后的甲方需求变更，找其他成员帮你分担一些工作。