日志记录
Source
Edit
History

Git 合作项目评论

Catalogue
  1. 1. 相机驱动
    1. 1.1. ZH
    2. 1.2. LZQ
    3. 1.3. XJH
  2. 2. 串口驱动
    1. 2.1. LJD
    2. 2.2. LKY
  3. 3. 总评
    1. 3.1. git
    2. 3.2. 封装性
    3. 3.3.

2021 年 9 月 20 日 第一次git合作Day1

相机驱动

ZH

  1. 项目的文件结构构建不规范，平铺展开
  2. 未能实现封装操作，将初始化等操作在主函数中调用。
  3. 参数实现了设定但是没有具体输入的参数
  4. 参数设定的数据类型和目标函数类型不一致
  5. 虽然有类的定义，但是类功能的实现还是以函数的形式进行书写而非成员函数的方式

LZQ

  1. 未能实现类的封装，典型的函数型思维，定义函数实现函数
  2. 能实现基本的封装，但文件结构不规范统一，git的合作的精髓在于同一个文件我们取并行开发合作实现功能后可以合并。

XJH

  1. 手动实现git合并，不推荐。
  2. 类封装类成员变量，但未实现成员函数的封装。
  3. 针对回调函数在关闭的时候也要考虑注销回调

串口驱动

LJD

  1. 具有比较好的文件结构实现类模块的封装，但未填加单元测试文件
  2. 对于构造函数的设定不够灵活，可以考虑重载编写多种构造函数，以便在后期传入串口名称后再开启和设置参数。

LKY

  1. 缺少文件结构直接在主函数编写

总评

git

在合作编写代码的过程在，我发现大家对于git的使用还是不够熟练。一方面，体现在不会使用commit对编写的程序进行版本追踪，具体表现为没有频繁使用commit，而是等单个或多个程序所有内容实现后再一次性commit，比较推荐的做法是在针对某个模块或功能完成后立即提交commit来进行提交（如完成曝光参数设定读取、完成开关相机等）。另一方面，在分支管理上目前虽然有合作的意向，但与我的预期还有一段距离的差距，具体表现为Clion IDE针对已定义的类、成员等提供了强大的自动补全功能，但是目前各个小组没有充分利用起这一点。举1个简单的实例，我们知道new branch是在已有的分支的基础上生成的，我们往往在合作的时候，针对由组长实现或负责人实现整个模块的Cmake文件结构，类名以及公用成员变量的定义。其他人则在此基础上创建自己的分支，实现各自的功能。这样既保证了整个模块构成的统一性和公共部分的统一性，也充分发挥IDE针对历史信息强大的自动补全能力。在合作实现各个组件后，负责人需要发起合并申请而不是针对不同的分支手动进行复制粘贴，便于管理回溯。

针对这个问题我比较推荐大家重新开建新的分支实现该过程。

封装性

针对单个实现的模块比如这次我们的题目，我们希望实现一个模块，这个模块封装了该领域所有的功能，当其被添加到新的项目中，调用该模块的类即可实现整个过程。我们不希望在使用他的时候，还需要添加额外的库来首先对该类的内容进行初始化等不必要的操作，这些都应该封装到类的实现中去，用户不需要知道这个东西的运行逻辑，只需要调用这个类即可。

比较推荐的cmake文件结构

1
2
3
4
5
6
7
8
9
10
├── CMakeLists.txt
├── UnitTest	# 实现模块的运行和测试
│    ├── CMakeLists.txt
│    ├── main.cpp	
└── ModuelName			# 往往以模块命名，实现模块功能和定义
    ├── CMakeLists.txt
    ├── .......
    ├── test.cpp
    └── test.h