在简单的分析中，我通常将代码分成几个部分：代码说明，加载包，自定义函数，数据读取和加工，正式分析。这样的项目，一般代码不会超过1000行。但是在做一些比较复杂的项目时，会涉及到多个变量和多个用于实现不同功能的脚本，比如脚本1需要用到变量A、B、C、D，而脚本2需要用到C、D、E，实际情况所涉及的变量可能有上百个。这种情况下，什么样的结构比较清晰合理呢？
具体而言，其中的一些可选的结构如下：
- 像简单的项目那样，先统一读取和加工数据，再进行分析。这样的好处是结构简单，但是效率较低。比如如果只需要用到其中的某个功能，可能只需要用到一小部分变量，那么大部分提前读取加工的数据变量其实是白费功夫。
- 将常用的变量读取和加工放在一个共同的称为“数据读取”的脚本中，而不常用的变量则放在各自对应的代码脚本中，运行特定分析功能的时候，通过
source加载“数据分析”这个脚本，然后再运行其他代码。这样的好处是效率较高，但是如果后面继续添加新功能，可能就要考虑是不是把一部分数据变量的读取加工“提取”到“数据分析”脚本中。
更棘手的是，如果是几个人合作写代码的话，问题就更复杂。比如某个团队成员更改了一个变量名或者列名，其他团队成员就得跟着修改自己脚本中的对应标识符名称。当然，有一个简单的解决方案，也是目前我在用的：大家各自负责一个功能代码脚本，协作方面则是跟需要对接的脚本负责人提出具体要求，比如“我需要一个数据框，这个数据框需要包含样地位置、温度、降雨这些数据，并且你要告诉我对应的列名都是哪些”，在拿到这个数据框后，先按照自己的习惯重命名变量标识符和列名，然后再接入自己的代码。不过这样做的话，对于读者而言就不那么友好，可能会有同样一个数据在不同代码中标识符名称不同的情况。
因此，总结一下，问题是：个人在做涉及多个脚本、多个变量的项目时，什么样的代码结构比较好？团队合作中，上一个问题的答案是否也适用？可有相关的书籍或文档推荐，类似于行业规范推荐之类的？
P.S. 当然当然，我们也可以认为，和自然语言类似的，读代码就像读文章，几个文章的信息整合起来是否容易、一本书的各个章节之间互动如何，跟作者有关，而读者也需要付出努力去理解，这其中有很大的弹性。
