十个编码过程中的“坑”,一篇文章帮你填平了!
数据科学家是“比任何软件工程师都更擅长统计学、又比任何统计学家都更擅长软件工程”的人。许多数据科学家都有统计学背景,但在软件工程方面经验很少。本文列出了常见的10个编码错误,希望你能认真阅读并避免它们。 1. 没有共享代码中引用的数据 数据科学既需要代码也需要数据。因此,其他人要能够获取数据才能重现结果。这听起来是很基本的要求,但很多人都忘记和代码一起共享数据。
解决方案: 使用d6tpipe(https://github.com/d6t/d6tpipe)共享数据文件和代码,或将二者上传到S3 / web /google drive等或保存到数据库,以便收件人可以检索文件(但不要将它们添加到git,见下文)。 2. 硬编码无法访问的路径 与第一个错误类似,如果你对其他人无权访问的路径进行硬编码,他们就无法运行代码并且必须查看许多地方以手动更改路径。
解决方案:使用相对路径,全局路径配置变量,或使用d6tpipe 让你的数据易于访问。 3. 混淆数据与代码 很多人会这么想:由于数据科学代码需要数据,为什么不将它转储到同一目录中?当你这么做的时候,很有可能也会把图像,报告和其他垃圾保存到一个目录下。这样就一团乱麻了。
解决方案:将文件夹归类,如数据、报告、代码等。请参阅#5,并使用#1中提到的工具来存储和共享数据。 4. 和源代码一起用Gitcommit命令处理数据 大多数人会在版本控制他们的代码(如果你不这样做,那这也是你犯的错误之一!)。在尝试共享数据时,你可能很想把数据文件添加到版本控制中。这对于非常小的文件是可以的;但是git无法针对数据进行优化,尤其是对大文件来说。
解决方案:使用#1中提到的工具来存储和共享数据。如果你真的想版本控制数据,请参阅d6tpipe, DVC(https://dvc.org/) 和Git Large File Storage(https://git-lfs.github.com/)。 5. 编写函数而不是使用DAGs 说了这么多数据,让我们谈谈实际的代码。 学习编码时学到的第一件事就是函数,因此数据科学代码主要被处理为一系列线性运行的函数。这会导致一些问题。
解决方案:数据科学代码最好写为一组相互之间具有依赖性的任务,而不是写为线性链式函数。 使用 d6tflow(https://github.com/d6t/d6tflow) 或airflow(https://airflow.apache.org/)。 6. 写for循环 与函数一样,for循环是学习编码时首先学到的。For循环容易理解,但它们很慢而且过于冗长。这通常表明了你没意识到还有矢量化替代方案。
解决方案: Numpy(http://www.numpy.org/), scipy(https://www.scipy.org/)和pandas(https://pandas.pydata.org/)为大多数你认为可能需要循环的情况提供了矢量化函数。 7. 不写单元测试 随着数据,参数或用户输入的变化,代码可能会中断,有时你甚至注意不到。这可能导致输出错误,如果有人根据输出做决策,那么糟糕的数据将导致错误的决策! 解决方案:使用assert语句检查数据质量。pandas有同等性测试,d6tstack (https://github.com/d6t/d6tstack) 检查数据摄取,d6tjoin (https://github.com/d6t/d6tjoin/blob/master/examples-prejoin.ipynb)检查数据连接。以下是数据检查示例的代码:
8. 不记录代码 (编辑:ASP站长网) |