各团队问题收集
作者：互联网
已同步更新到班级Github
Q：如果团队作业出现返工次数多的问题 无用功要算作功吗 虽然我们组是按照完成进度和任务量双重评判 但是感觉还是很难协调
一个重要结论：返工次数多导致最后作业没有按时完成，它导致的直接结果肯定是团队作业的分数被扣掉。
接下来我们需要明确到底是什么问题导致了返工次数多，由后面的反馈可知，返工次数多的原因在于：
a任务需要在b任务完成后在写 比如说输入输出格式我们小组一开始按照原型写 后来接口设计出来后大幅修改 这是一开始负责人对输入输出模块不理解的原因 但是在理解后做针对这次作业来说很耗费时间
工作态度和工作能力问题
那么我们有没有办法避免这两类返工问题呢？我认为可以通过如下的方式来避免：
a任务可以先用模拟数据，这样一来，a任务可以不依赖b任务，a和b就可以并行开发了。
接口内容可能会变，但是接口规范可以事先定好（先于业务需求），接口规范定义好以后，可以最大限度防止大规模的接口设计修改，什么是接口规范？可以参考一下这篇文章
团队有个贡献分，对于比较拖后腿的同学，分数没办法，只能打低一些。
Q：Github经常抽风的问题
解决方法有三个：
- 合理上网
- 改host
- 多个时间段多试几次
PS：这里也推荐大家可以多次commit，然后一次性push，不需要每次commit都要立即push
Q：有同学的项目是前后端是分离的，可否开两个仓库方便CI/CD和release？
没问题，项目仓库的组织方式有很多种：
分多个仓库，比如：一些前后端分离的项目；微服务项目（每个微服务一个仓库）
单仓库模式。典型的如：Google，可以查看这篇文章: Why Google Stores Billions of Lines of Code in a Single Repository
子模块方式。 比如：Skywalking, 它的前端就是用子模块方式管理的。
这些组织方式没有绝对的好坏之分，团队根据自己的情况选择任何一种适合自己的方式都可以。
Q: 审核工作大家是怎么展开的呢 我们小组这次作业下设了负责人 然后在审核阶段没有将出现问题的部分审核出来 （可能是不认真）于是他提出 是否要让参与的同学都审核 因为部分工作负责人并没有参与 不能明确是否合理 可是开会现状是参与的同学只会关注自己的板块有没有问题
这个问题，可以引用群里另外一个队长回复：
审核一般都让负责那个模块的人共同去负责吧，因为很难去让所有人都能了解所有。就跟代码规范一样，让他们自己先自己提前商量一个规范。尽量每个模块有一个了解的较多的人进行负责。
Q: 我们小组是提出了做一个关键路径图，但我觉得这个解决办法太高估组长了
关键路径图是项目管理中的一个工具，团队可以尝试使用，如何用好这个图，可以参考一下这篇文章
标签：返工,收集,仓库,可以,接口,问题,团队 来源： https://www.cnblogs.com/greyzeng/p/14456314.html