到目前为止，我们主要关注的是生产环境里的系统是什么样。当然对于如何保证生产系统稳定和高效则有很多种方法。有时候，直接部署Python写的模型就足够了，但生产系统和探索分析部分的分离是肯定存在的。

　　你将会面对的艰巨挑战之一，就是如何协调数据科学家与程序员的合作。“数据科学家”依然是一个新的角色，但他们所做的工作与典型的程序员有着明显差异。由此导致的误解和沟通障碍就不可避免了。

　　数据科学家的工作通常是探索性的。数据科学项目一般始于一个模糊的目标、哪些数据可用的一些想法、以及可能的算法。但非常常见的情况是，数据科学家必须尝试多种想法，并从数据里获取洞察。数据科学家会写很多的代码，但是大部分都是用于测试想法，直播，并不会被用于最终的解决方案。

图6：图片来自Mikio Braun的演讲页

　　与数据科学家相反，程序员通常非常关注于编程。他们的目标是开发一个系统，实现所要求的功能。程序员有时会做一些探索性的工作，比如构建原型、验证概念或是测试性能基准。但他们的工作的主要目标还是写代码。

　　他们间的不同还明显地体现在代码的变化上。程序员通常会坚持一个非常明确定义的代码开发流程。一般包括创建自己工作流的分支，在开发完成后做评测检查，然后把自己的分支合并进主分支。大家可以并行开发，但必须在协商后才能把他们的分支合并进主分支。然后这个过程再重复进行。这整个过程都是确保主分支会以一个有序的方式演进。

图7：图片来自Mikio Braun的演讲页

　　数据科学家也会写很多的代码。但正如我之前所说的，这些代码通常是为了验证想法。所以数据科学家可能是会写出一个版本1，但它并没有实现需求。然后又针对一个新的想法写了版本2，随后是2.1和2.2，直到发现还是不能实现需求而停止。再对更新的想法去写版本3和3.1。也许在这个时候，数据科学家意识到，如果采用2.1版里的某些方法并结合3.1版里的某些方法，就能获得一个更好的解决方案。这就带来了版本3.3和3.4，并可能由此形成了最终解决方案。

图8：图片来自Mikio Braun的演讲页

　　一个有意思的事情是，数据科学家实际上可能希望保留所有这些没成功的版本。因为之后的某个时间，也许它们又会被拿来测试新的想法。也许有些部分可以被放入一个“工具箱”里，逐步形成数据科学家自己的私人机器学习库。程序员更希望去删除“无用的代码”（因为他们知道如何快速地找回这些代码），而数据科学家则喜欢保留代码以防万一。

　　上述的两大不同意味着，在现实中，直接让程序员和数据科学家共同工作可能会出问题。标准的软件工程流程对数据科学家的探索性工作模式并不合适，因为他们的目标是不同的。引入代码评测检查和有序的分支管理、评测、合并分支的工作流对数据科学家而言并不合适，还会减慢他们的工作。同样的，把探索性的模式引入生产系统开发也不会成功。

　　为此，如何才能构建一个合作模式来保证两边都能高产出的工作？可能第一直觉就是让他们相互分离地工作。例如，完全分开代码库，并让数据科学家独立工作，产出需求文档，再由程序员团队实现。这种方法也行得通，但流程通常会非常得慢，且容易出错。因为重新开发实现一遍就可能会引入错误，尤其是在程序员并不熟悉数据分析算法的情况下。同时能否进行外部迭代来改进系统的表现也依赖于程序员是否有足够的能力来实现数据科学家的需求。

图9：图片来自Mikio Braun的演讲页

　　幸运的是，很多数据科学家实际上是希望能成为好的程序员，或是反过来。所以我们已经开始试验一些更直接和更能帮助加快流程的合作模式。

　　例如，数据科学家和程序员的代码库依然是分离的，但部分生产系统会提供清晰定义的接口来方便数据科学家把他们的方法嵌入进系统。与这些生产系统的接口进行沟通的代码必须严格地依据软件开发实践流程，但这是数据科学家的工作。用这种方式，数据科学团队可以在自己的代码快速地迭代，同时也就是完成了对生产系统的迭代。

图10：图片来自Mikio Braun的演讲页