一、进度概述

        1、ddnet_main 相关代码学习（预计 3-4 天）

二、详情

1、顶层结构

        关于代码顶层结构的一些思考和总结，其中下图为师兄代码的文件结构

总结：
        对于一个优秀的代码，其文件结构一定也是清晰的，最常见的就是数据的分类。回顾我自己做的几个项目，几乎都是所用文件全扔一个地方（很惭愧的来讲，我目前还没有写过类似于 path_config.py 的文件）。将数据，模型分门别类的整理在各自文件夹中，既美观好看，又好对其做相关处理（如更新）。

2、代码原理分析

        各个文件的详细说明这里就不重复了，在 README.md 中有很详细的说明。
        原理上的东西可能还需要一定时间的研究

3、感悟

1）模块化

        经过这几天的研读后，个人觉得 ddnet_main 与本科期间的小项目最大的不同在于模块化的分类。
        何为模块化？在我之前 fpga 相关项目的笔记中提到过，模块化代码使得我在编写相似项目的过程中省下了极大部分的经历，将一个项目拆分成不同的子任务，再对子任务中的不同进程进行分类，使得最后成为具有通用性质的模版代码。换句话讲，这其实也是一种意义上的函数。在 C++ 中，有一种结构叫做 “类”，编写最基本的 “类”，而后根据不同的特性化需求进行一定程度上的派生，从而形成了能处理各种不同数据的函数（这只是类比，实际上这个项目是用 python 编写的）。在编写大项目中，要着重把握这一思维，这样能大大减小重复化的代码编写。如这里的 path_config.py，路径的相关编写可以参考这个。
        这里好像突然就明白当初那个自己写的篮球计数器为啥会出现顶层 contral 文件没办法成功运行了，大概率就是因为没有路径配置，导致调用文件出现了点问题（改天回去看看）。

2）运行反馈

        在以往的代码编写经历中，我时常有着 debug de 红温的经历，一部分原因是因为代码硬实力不够，导致对着报错也得分析好一阵子才能解决；一部分原因是代码习惯不好，如双边符号只有一个；还有一部分原因就是没有编写运行反馈的习惯，导致一些原理上的错误很难找到。如下图：

        为什么说一定需要有运行反馈呢？编译器的报错只能帮你纠正语法和格式上的错误，对于运行原理，它是没有办法的。对于本科期间的小程序，你实在搞不定，可以地毯式重新过一遍代码，但这样做的前提是他体量小。当代码体量逐渐增大，这么干就显得很不明智了。而良好的运行反馈，则能帮你快速定位。
        这一点需要好好学习，这种习惯是我的弱项。

3）关于 readme

        readme 不仅仅对读代码的人来说是一个快速了解这个代码的运行逻辑，以及相关注意事项的好帮手，更是帮自己理清思路的方法。
        对我个人而言，已经有建立 readme.txt 的习惯，但是受限于 txt 只能记录文本，有些情况下十分不方便。这里发现 .md 文件是个好东西，值得学习。

---

后记

2024.8.17

        今天的主要内容是逐句分析 ddnet_main 相关代码，暂未完成，具体整理见明天的笔记。
        在阅读代码的过程中，发现自己的 Python 相关代码能力还有些弱，很多语法，用法上的东西还需要回到教材中去复习，这点不应该。
        关于 Python 代码能力，相关见 Python 专题整理，后续会重新开始更新该专题。

2024.8.18

        继续整理学习代码。
        今天的主要内容是关于代码顶层结构的一些思考和总结，更多细节上的代码后续继续整理。
        原理上的东西可能还需要一定时间的研究，现在依然存在原理上的理解问题，以及再很惭愧的是，python 能力真的很弱啊。
        而且还有挺多库需要去学的，好多都没见过。