经验分享：软件开发程序员转型Data Scientist

重磅干货，第一时间送达

大数据文摘出品

来源：codebuildrepeat

编译：徐玲、lin、夏雅薇

万事开头难，从一个软件开发程序员转型为数据科学家，第一年该怎么做？

一位博主就记录了自己从全栈工程师转行数据科学家第一年的心路历程，包括好的方面和不好的方面，希望能帮助到同样处境的人。

我觉得自己非常幸运雇主给了我一个机会，让我从一个全栈软件开发人员转型变成数据科学家，和内部数据团队一起工作。

入职一年，我很享受这份工作给我带来的全新挑战，完全不同于以前做开发。我想写这篇文章，首先是为了回顾过去一年所做的事情：我经历的改变，我做得好的地方，我可以改进的地方。第二，通过记录我曾经遇到过的问题和挑战，我希望能帮助到和我处境相似的人。

在开始之前，我先介绍一下我的背景：我之前不是做软件开发的，我拥有计算机科学的硕士学位和博士学位。因此，我不算冷启动，我有工具、模型和分析方法方面的相关经验。我从事开发工作将近8年。自从我的论文发表以后，我经历了很多变动。

本文将分为两部分。进展顺利的部分和进展不佳的部分。对于那些只对结果感兴趣的人，也可以拉到底直接看最后的结论。

进展顺利的方面

Python 和 R

刚开始，我不确定在项目中该使用Python或R。所以一开始我对这两种语言均作了研究学习，并在项目中结合使用了这两种语言。

R经常让我想起Matlab，两者在用来编写和执行代码的界面非常像（我尝试了R Studio和Visual Studio的R插件），同时写代码和处理数据的方法也很像。

但我只在硕士论文中用了R，还在博士学位论文中用了一些。除此之外，R和其他编程语言相比（这些年来，我在软件开发中经常使用C＃）就没什么共性了。R这个工具极度以数据为中心，与数据进行交互的方法也很不一样。

在R里有：列表，矩阵，向量，数组和数据帧。每个都有不同的使用场景，你需要学会什么时候使用。R与C＃的语法很不一样，所以刚开始学R我遇到了不小的困难。我并不是说R不好，只是我使用Matlab10年，并且作为开发我的脑子已经习惯了某种思维方式，所以比较难转变。所以我刚开始的时候觉得R很难上手。

作为一名有8年C＃开发经验的程序员，我觉得Python比R更容易起步。很可能是因为我的大脑已经习惯了C#的思维方式。python比R更接近于C＃，所以我学Python比R快很多。

在使用这两个语言时，我没觉得两者有明显区别，尤其是对于可用的库，两者在我想做的工作的实现方面有差不多的处理能力，我也会得到相同的结果。但在摸索过程中，我对两个工具分别都有些困惑。

总的来说，编程编久了， Python对于我的程序员思维更友好。

所以我很快放弃了学习R，转而专注Python。这有助于我更快地进步，不必再花时间阅读新语法，事情变得简单许多，我一直觉得简单才是王道。这对我应对角色的许多其他变化也是有帮助的，因此，这样做可以最大程度地减少更改。

关于使用哪种以及何时使用，我敢肯大家定对此有很多意见，但是对我来说，从开发人员过渡到数据科学家后，我发现Python变得更容易掌握和使用，尤其是在我担任新职位后想快速发展并取得成果的初期。

所以与R相比，使用Python让我更快进入状态，在输出方面，我没有发现两者有任何明显区别。所以我把这个归类为进展顺利，因为我很早做出了决定，且至今没有遇到任何情况让我觉得自己选错了Python，相反我节省了不少时间，所以我能更快地开始工作。

文档记录

记录一切，我定义的一切是从模型超参数到从何处以及如何获得训练数据，到在整个项目中做出选择的理由。另外，以有序的逻辑方式编写文档，实现这一目标的一个秘诀是， 哪怕你只是写给自己看（例如，在我的情况下，我是唯一的数据科学家），你应该想象有人会读这份文档。

此外，记录时要对自己有一定的约束，不要拖拉，不要走捷径。不然等你开始写的时候，你可能已经忘记一些需要注意的细节。因此一定要及时写下来。在完成文档之前，我觉得工作就还没做完。我从一开始就遵循这种方法，我觉得至关重要。

我发现一件事是，即使在一个中型企业，等到一个项目的研究成果在公司开始推广已经是一段时间以后了，利益相关方因为有其他事要忙，所以不会立刻作出回应。

有时候在我完成一个项目几个月后，有人跑来问我问题，我一时想不起来，但如果我翻看我之前做的文档记录就能马上提供详尽答案。例如，有一次我与另一位经理聊起几个月前做的一个项目，我向他展示了我已经完成的工作，他问我训练集的大小是多少，以及我用来获取数据的日期区间。我并记不得那些数据，但我记得自己已经写下过，而且我也记得写在了哪里。所以我能马上把文档拿给他们看。

我发现自己遇到的另一种情况是当业务优先级发生变化，你可能会需要停下手头还没完成的项目去做另一个项目。当你再回到之前开始的项目时，完整的文档可以让你从之前停下的地方继续进行下去。

不顺利的一面

数据存储

回顾前一年，进展不顺利的一个原因是我处理数据的方式（对于数据科学家而言这非常关键）。

当我没有使用数据库的经验时，我基本上复用了在博士期间使用数据的方式。使用平面文件（特别是CSV）来存储数据。我把从生产环境中提取的初始数据，清洗后的中间过程数据，分析后的数据和结果都存在了CSV里。我工作流程中的每一步骤都需要通过Python脚本读取上一步创建的文件，并创建新的文件。

这种把内容存储在硬盘上，并通过Python脚本与数据交互的原始办法，很快就出现了一些问题：

• 有时很难在大量文件中找到我要找的那个文件。即使我记录了文件的内容和位置，但有时还是很难找到我想要的确切文件，因为文件实在太多了。

• 我似乎总是在忙着用Python把从文件中读取数据或者将数据写入文件。我写了很多文件访问的命令，但其实是在做重复劳动，写这些代码对我要做的工作并没什么帮助。

• 想快速地将数据总结一下似乎都有点费力：读取数据，汇总统计，输出统计，查看统计结果。

• 有些文件很大，用起来很困难（在notepad中打开10GB以上的文件很麻烦）。

第一年，我花了很长时间才意识到SQL是我的解药。

在从事数据科学家工作之前我使用过SQL，但是我一开始没有意识到它对我的价值。当我意识到SQL就是我的解决方案后，我花了很多时间来学习更多有关SQL的知识，因为我在做程序员的时候稍微学了一点SQL。

具体来说，我学习了如何查询数据（特别是我以前没接触过的高级语句）以及搭建和维护数据库的基础知识。我甚至通过了两个Microsoft SQL的考试。我现在主张尽可能用SQL。我把所有项目的数据都存在了SQL数据库中，尽量在SQL中做数据查询和操作。

我的原则是：能在SQL中完成的处理，就在SQL中做。SQL处理不了的任务再用Python（例如，模型训练和执行）这里延伸出一个问题：你需要学会使用Python库，例如 SQLAlchemy，从 SQL读取数据到Python里。

现在我的后SQL生活变得容易很多：

• 所有项目数据存储在一个容易找到的地方。

• 没有重复代码用于读写文件。

• 我能快速查询数据并从数据中轻松得到统计结果。

• 我能够很容易地查看大量数据，特别是前几行的数据。

• 额外的好处是现在很容易把不同的数据联系起来，因为数据都已经在关系数据库中了，现在安全性也提高了：把数据存在本地磁盘上有潜在的风险。数据都在服务器里，安全很多。

因此，我强烈推荐学好SQL并用起来。

如何展示成果？

还有一个进展不顺利的地方是我做的一些展示。从开发人员到数据科学家的一个变化是，我做演示的场合变多。展示的内容各种各样，有面向技术人员的demo演示，有面向业务相关人员的项目报告，再到与公司内部其他部门讨论项目工作，甚至向公司外部的第三方合作方展示工作。

对于这些人我觉得我没有做好的一点是我没有根据受众来调整自己的展示方法。有些展示我做得还不错，比如对开发人员的技术演示我觉得我做得还不错。因为我跟技术人员拥有差不多的背景所以说技术的内容彼此也听得懂，交流起来会更容易一些。其他类型的演示更难一些，不幸地是很多时候我在展示的时候才意识听众对我讲的内容不是很在意。

我的受众分为四类，从展示的难易程度来分如下：从最简单的（最左边）开始，到最难的（最右边）：开发人员，业务方，其他部门以及外部人员。

我还可以将最左边的那些受众标记为最技术性的，将右边的那些受众标记为更“销售型”的，当从左向右移动时，两者之间会有一个过渡。我发现针对左边受众的展示是最容易准备的——他们对我正在使用的技术或所从事的业务领域有深刻的了解。

针对外部人员的演示是最难的，因为他们往往相关知识最少。过去，我与这些听众进行交流的时候会直接进入到技术细节，就像我和左边听众交流时一样，但是结果很不好，因为他们不一定具有任何数据科学或机器学习的背景，所以我谈论许多概念对他们没有多大意义，他们不知道我在说什么。对这些受众来说，如果我花点时间介绍一下我正在做的工作以及更多的背景知识，效果会更好。甚至对某些受众来说，向他们介绍机器学习的概念，为什么我们要使用它以及它的好处。有时候，对我来说，不过多讨论技术细节反而是好事，给他们一些大概的框架概念就好。

在反思了这一点之后，我现在在准备演示材料时，会更多地考虑我的目标受众。具体来说，我会考虑听众可能知道或不知道的内容，以及需要向他们呈现的内容，以帮助我准备需要讨论的内容和专业程度。这样他们就可以更好地理解我正在谈论什么=，并从演示中得到一些收获。为此，在准备演示文稿时我为自己准备了一些有用的问题，如下：

• 听众对于数据科学领域了解多少？

• 听众对于我试图解决的问题了解多少？

• 听众知道我在使用的技术吗？

• 听众对于我采用的技术细节或者结果感兴趣吗？

计划

与做程序员时相比，做数据数据家的工作计划更有挑战。作为开发人员，工作相对比较直接，所以也更好估算和排期。你通常知道你要实现的目标以及如何实现。当我还是一名开发人员的时候，我使用敏捷开发工具。

因此，工作内容可以先评估、计划，然后排好优先级就开始做。在敏捷的方法论指导下，如果工作没什么意义，或者你不清楚如何做，你就不会把它排进工作计划。因为无法评估，因为未知，你要等到所有不明确的地方明确后才开展工作。

数据科学的工作并不像这样简单，对于给定的问题你不会总是提前知道什么会起作用。也不会总是知道哪种类型的模型最准确。类似这样的情况与刚才提出的观点出现矛盾，当你是开发人员时，只有问题明确后，你才会把他们放入你的工作列表中。作为数据科学家，未知是你工作的一部分，因为你的工作就是要回答这些问题。或者你正在处理的问题可能会随着项目进展而改变。因此，有时候你提前做的几周计划可能很快要重新考虑。

在计划方面，我喜欢将开发工作视为线性的——你知道自己在做什么以及如何做。数据科学工作我觉得是分叉树，可能需要试不同的道路，可能会碰到死胡同。

数据科学家做短期工作计划还是可行的，比如你正在训练和测试的模型之类的——接下来一两周的工作，但是，长期计划很难做。你不可能总是提前知道什么会起作用，什么不会。所以我们才要进行实验和测试，这是数据科学家工作的核心价值。

最后，花点时间去做不一定会有成果的工作，即使不起作用，也没什么大不了的。

回答正确的问题

在过去一年中（这让我栽过很多跟头），我发现数据科学工作的关键部分是回答问题，但更重要的是回答正确的问题。

正如我所说，我栽过几次跟头，当时我正在回答一个问题，但并没有回答业务方实际想要回答的问题，之所以发生这种情况，是因为业务方使用的业务语言跟我用的的技术语言有差异，有时候我们用一样的词但要表达的意思却不同。

针对这问题我的解决方法是在做项目的实际工作（现在称为“项目前”工作）之前先做准备性工作，在这个阶段，我会从业务方那里收集初始需求和信息。做一些初步分析，然后给业务方展示。

运用敏捷的工作思路，我希望在每个sprint实现一个可交付的成功，并向业务方展示该成果。这样，我与业务方建立了一个有效的循环反馈机制，向他们展示一些东西并询问他们的意见，这可以建立一个有效对话，从而更清晰地定义真正要解决的问题。这个方法在项目各个阶段都有效，不仅仅是初始阶段。当你向业务方展示你的工作结果时，可能会激发他们不同的想法以及他们之前没有考虑过的思路。从而你能找到他们真正的痛点。

所以过去一年来我发展的一项关键技能是与业务方的互动交流，深入挖掘他们真正想要的东西。

总结

Python比R更容易学习，因为对于程序员来说python与其他编程语言更接近。

• 边执行边做文档

• 学习如何使用关系数据库，比如SQL，用数据库来查询，操纵和存储数据。

• 你需要准备很多展示，不仅是向项目业务方的报告，还要向公司其他同事报告，甚至是公司外面的人。

• 你需要提高演讲能力以满足不同受众（技术或非技术）的需求。

工作计划不是一帆风顺的，因为你无法预知什么起作用什么无效，要有心理准备有时候花了时间不一定取得预想的结果。

花时间找你真正要解决的问题，不要不加思考就埋头开始做，与业务方建立反馈闭环是很有必要的。