十个编码过程中的“坑”，一篇文章帮你填平了！(2)

为了急着做分析，你可能囫囵吞枣地弄出结果，然后把结果交给客户或老板;一个星期后，他们找到你说“能改一下这里吗”或“能更新一下这个吗”。这时你看看代码，完全不记得当初为什么这么写了。现在想象一下，其他人还必须运行你的代码……

defsome_complicated_function(data): 
        datadata = data[data['column']!='wrong'] 
        datadata = data.groupby('date').apply(lambdax: complicated_stuff(x)) 
        datadata = data[data['value']<0.9] 
        return data 

解决方案：在提供分析之后，也要花费额外的时间来记录编码时做了什么。你会庆幸自己这么做了的，其他人更会感谢你!这样你会看起来更专业。

9. 将数据保存为csv或pickle格式

回到数据，毕竟我们在谈数据科学。就像函数和for循环一样，CSV和pickle文件很常用，但它们实际上并不是很好。CSV不包含架构，因此每个人都必须再次解析数字和日期。Pickles解决了这个问题但只能在python中使用并且不会被压缩。两者都不是存储大型数据集的好格式。

defprocess_data(data, parameter): 
    data = do_stuff(data) 
    data.to_pickle('data.pkl') 
  
data =pd.read_csv('data.csv') 
process_data(data) 
df_train = pd.read_pickle(df_train) 

解决方案：

对数据模式使用 parquet(https://github.com/dask/fastparquet)或其他二进制数据格式，这两者是压缩数据的理想格式。d6tflow自动将任务的数据输出保存为parquet，这样就不用再操心格式问题了。

10. 使用jupyternotebooks笔记本

这一点也许颇具争议：jupyternotebooks和CSV一样普遍。很多人都使用它们。但这并不意味它们就是很好的工具。jupyternotebooks助长了上面提到的软件工程中的坏习惯，特别是：

• 你很想将所有文件转储到一个目录中
• 编写自上而下运行的代码，而不是DAGs
• 没有将代码模块化
• 难以纠错
• 代码和输出混在一个文件中
• 没有很好地进行版本控制
• 上手很容易，但扩展很难。

解决方案：

使用pycharm (https://www.jetbrains.com/pycharm/)和/或spyder(https://www.spyder-ide.org/)。

（编辑：ASP站长网）