第二章：以项目为导向的工作流程 Project-oriented workflow

上一章我们说了rm(list=ls()) 但是我们不推荐用它，因为他并不能重置一些东西，比如你导入的包是不会重置的。还不如重启R直接了当。
但是它也可以用在项目之间的重置上，比如你project A和project B在不同的目录。那么应该怎么办呢？

2.1 首先来说说 “setwd()”：不要再使用啦！

解决工作路径问题的常见做法是使用setwd()函数，在每个脚本的开始设置工作目录。
相信绝大多数人都是像这样：

library(ggplot2)
setwd("/Users/jenny/cuddly_broccoli/verbose_funicular/foofy/data")
df <- read.delim("raw_foofy_data.csv")
p <- ggplot(df, aes(x, y)) + geom_point()
ggsave("../figs/foofy_scatterplot.png")

Setwd()命令可以使路径起作用，但是对于除了作者之外的其他人根本不起作用。同样有可能对于作者本身在一两年后或者其他电脑上也不起作用。那么对于重新画这个图或者再次延伸修改这个图就很麻烦。

固定路径，或者绝对路径，特别是在整个代码中散布的绝对路径，会使得代码很脆弱。这样的代码在时间上或者空间上不能很好的传播。

如果在阅读本文之后，你仍然决定在脚本中使用setwd()，那么请你至少非常注意以下几点:
1. 只在文件的最开始使用setwd()，即在一个明显且可预测的位置。如果有人必须手工编辑这些，让他们更容易。
2. 总是将工作目录设置为相同的内容，即项目的顶级目录(而不是子目录)。始终构建与此相关的后续路径。像上面举的例子一样。

2.1.1 如果你喜欢使用setwd()，那么请继续用。

如果在你使用setwd() 时没有给你或者你的合作者造成麻烦，那么你就继续用，这也是我多年的实践。

但最终我承认，每当我移动文件、与同事合作进行分析、或在一台新电脑上时，这确实会给我带来痛苦。然后，作为STAT545的讲师，我开始大量运行其他人的代码。每周有多达80名学生提交多个. r和. rmd文件，其中充斥着setwd()调用，需要我手工编辑。这是压倒骆驼的最后一根稻草，使我决心把这个问题和一些解决办法清楚地表达出来。你可以从你的生活中设计出这种特别的烦恼。

2.2 困境和解决方案

问题陈述：
* 我们希望在project A中将R的工作目录设置为path/to/projectA，在项目B中将R的工作目录设置为path/to/projectB。
* 但是我们也希望像setwd(“path/to/projectA”)这样的代码不出现在我们的.R 脚本中。

技术水平最低的解决方案是，当您从项目A切换到项目b时，交互式地自己设置工作目录，同时重新启动R，执行setwd(“path/to/projectA”)，但不要将其放入脚本中。这是行得通的! 但是，大多数人会用回setwd()，并且/或者不愿意在项目之间快速循环，这已经足够让人恼火了。

我强烈建议使用支持基于项目的工作流的IDE。这消除了开发便利性和代码可移植性之间的紧张关系。

2.3 把工作相关的东西都组织到项目中去

• 文件系统准则：将与单个项目相关的所有文件放在指定文件夹中。
• 这里指的是数据、代码、图形、注释等。
• 根据项目的复杂性，可以将进一步的组织强制放到子文件夹中。
• 其他常见的文件实践将在future link: api for a project和future link: named files中详细介绍。
• 工作目录意向：在处理项目A时，请确保将工作目录设置为项目A的文件夹。
• 理想情况下，这是通过开发工作流和工具来实现的，而不是通过在代码中引入绝对路径来实现的。
• 文件路径准则：所有路径都是相对的，默认情况下，相对于项目的文件夹。

这些习惯是协同作用的:如果你把它们都一起练习，你会得到最大的回报。

这些习惯保证了项目可以在您的计算机或其他计算机上移动，并且仍然“只工作”。我认为，随着时间的推移，这是在不同的计算机或用户之间创建可靠的、礼貌的行为的唯一实用约定。这个约定对于R来说既不是新的，也不是唯一的。

这就像同意我们都在左边或右边开车一样。文明的一个标志就是以公共安全的名义，遵循一些约束你行为的习俗。

持续更新中。。。