豆瓣技术总监：Python Web开发领域经验总结

问题导读

1.phython的优点有哪些？
2.豆瓣为什么一直使用phython？

3.通过本文你对phython又有哪些新的认识？






Part 1
我之前在豆瓣工作，大家一般都叫我“清风”，豆瓣一般都用网名。我在豆瓣差不多工作了五年，走的时候是豆瓣的技术总监。现在在创业，这次演讲因为跟MSUP的人很熟，本来没有太想来，因为创业了，准备收山了。今天真的是收山之讲，以后不能总出来讲了，因为自己也创业了。我自己的项目其实也用phython做很多事，我用phython差不多用了快十年。豆瓣大家知道一直用phython做的网站，所以我今天大概跟大家分享豆瓣是怎么用phython的，先泛泛说一下phython都有哪些，我们也可以用提问的方式更多的了解phython。

因为开场自我介绍很麻烦，其实豆瓣有一套内网系统，每个入职的人给自己打标签，这样的话更容易他是什么样的人。因为我最近在创业，做什么呢？做一个APP，我创业之前当作家，如果大家有时间可以上豆瓣阅读，订一个专栏叫“寂寞社交”，吃喝玩乐在北京，我们前两天刚搞完九周年的活动，大家不知道晚上去哪儿玩，可以通过那个组约到很多小伙伴玩。

简单介绍一下phython，我先大概了解一下，咱们这里用过phython的举过手，都是用过的。用过Web的举手，数据挖掘的举手，做一些运维工具的举一下手，phython基本上用在这三个方向。
我大概总结了一下，phython基本的应用场景，
一个是Web开发，也是豆瓣用的最多的。
还有就是数据分析，因为豆瓣是一家很注重数据的公司，非常注重数据，基本上自豆瓣成立的第一天起，我们收集很多数据做数据分析。因为分布式计算和数据分析放在一起讲，早年没有什么分布式计算，十年前中国还没有。基本上怎么做呢？就是写一个phython脚本算，数据库拿点数一算，差不多就是这样的情况。

后来有了hadoop，做技术的人，我认为自我技术纯洁性的事情。就像用phython的公司可能不愿意用Php类似这样的案例，包括java也一样，豆瓣对java有一点小排斥。我们用起来特别别扭，不是特别顺。

后来出来一个东西叫scipy，后来我们写了dpark，基本上按照scipy的功能实现。所以豆瓣的计算是这样的，拿scipy跑基本的分布式计算，之后到1/3可能做复杂的计算，可能用pandas去做。但是openstack没有用。

phython其实是这样的，很莫名其妙，在我们用phython的人眼里就是这样朴素的用，很多人知道phython可以做Web开发，然后phython用的慢慢变少。前两年分布式计算数据分析特别火，虽然很多公司使用hadoop，phython又火了，因为pandas，大家用就知道这些库很好用，phython又火了一段时间。这两年云计算火了，很多人又开使用phython。

在我看来，从曲线大家可以看到phython的流行度。我用这么多年phython，我觉得它一直是一个很朴素的编程语言，我觉得phython是用来解决问题的，它并不花哨，基本上你想解决的问题都可以解决。很多人问我一个问题，豆瓣为什么没有考虑用其他语言，比如说用其他的语言。我们的经验是这样的，其实我们也不是没有想换过，也尝试过其他的。但是在实际应用场景中发现，我们用phython也没有遇到完全不能解决的问题，所以phython基本上用在这几个场景上。

phython的优点，因为大家都用过，我简单说一下，因为它比较简单，扩展免费，可以用到一些工具。而且phython确实不是一个玩具，因为我不知道多少人把phython用在生产环境。大家可以看到业内的案例NASA在用，包括Google本身，包括Dropbox，毕竟我现在也创业了，像phython这种语言，它起步非常快。因为所有人几乎都知道，它的性能现在好点了，2.0之前它的性能是比较差的，我觉得有一句话说的非常经典，它的性能能达到什么程度，它刚刚好能支撑这家公司融到A轮，很经典的一句话。关键是要快，其他的语言性能很好，但是你没有到A轮就饿死了，基本上是这样的。

所以Dropbox非常好，后期是这样的，phython的性能也够了。如果有人跟你吹phython的性能比C好，根本不用理他，转身走就可以了。包括Quora，因为PyPy3.0它是一个很奇怪的产品，没有解决特别关键性的问题，那是phython性能的硬伤。PyPy会在这方面做很多的优化和调整，从目前来看性能还是不错的。但是有一点确实跟Quora没法比，Quora把PyPy招进去了，我个人比较看好PyPy。

再说一下豆瓣，phython几乎你想到的东西，我们的运维脚本、Web开发、计算工具等等，几乎所有的东西都用phython写的，应用在豆瓣所有的场景中。这个Languages in，大家知道现在的世界是前端的，早晚也是前端的，前端就是太猛了。前端工程师更疯狂了，原来只能写前端，现在居然可以写后端。Languages in在豆瓣用的非常多，那是一个前端非常重要的项目。包括后来有些开发节奏也是这样的，因为大家知道开发效率高有很大的优点，第一个版本实际上因为开发快，前端工程师自己搞定上线了，但是它的性能无法评价，太差了。没有关系，还是那句话，它可以很快的上线，而且后期豆瓣做广告投放了，C++我们知道是一个库，phython有一个天生的优点，因为我入行比较早，我们那个时代写C或者是C++。有一个很好的点，C性能绝对够好，但是写起来开发速度比较慢。但是phython跟C的结合是最容易的，比如说你可以用C解决一些核心的库，所以合作起来会非常方便。

我们讲phython，很多公司知道豆瓣用phython，这个确实没错。但是实际上我们除了phython之外，我对phython是这样理解的，phython真的只是一门编程语言。我在豆瓣工作五年，我觉得豆瓣最值得拿来说的是豆瓣的协作流程，大家知道phython是一门动态语言，动态语言其实有很多问题是天生的。比如说你可以做类型的检查，可以做很多事情，可以在编译方面做很多事情。这个时候实际上所有做动态语言的公司，对单元测试重视程度非常高，今天恰好第三个话题也是豆瓣的同事来讲测试，豆瓣对测试的重视程度非常高。

简单来说，豆瓣是做Code，也有一套自己的原则。比如说随便举两个点，咱们这里有多少人用过，因为现在的开源项目，大家基本上都是在dadhoop上面协作，你想参与这个项目的开发，实际上豆瓣内部就是这套流程，你对它针对性的进行一些修改，在这个上面大家可以进行充分的沟通和交流，交流什么东西？因为是phython，因为它是编码风格，不管是C++，一定要有变成规范，细到什么程度呢？函数如何命名，两个函数之间空多少行，是空格还是不空格。但是这个有工具检查，我们人为的看这些东西。

再有就是测试，因为作为这个项目而言，你是靠什么证明的呢？你不能靠嘴说，在我的电脑上运行是最好的，你的团队有问题。但是这个其实是有问题的，你需要证明自己的代码是正确的，只能靠测试，这样别人安装的时候负担也会小很多，因为我们有良好的集中测试环境可以做这样的事情。简单来说代码一定要经过reviewer，因为这个是要承担的，这个代码上线了有BUG，不是光写代码的人有责任，reviewer的人同样承担责任，下面是phython的Hello  word。  

Ruby其实是一门很强的语言，个人实话实说确实Ruby比phython强，它的可读性更强一些。从我们豆瓣这么多年的经验来看强制缩进带来的好吃是非常大的，因为编译过不去必须要靠缩进，一定要少些括号。因为强制缩进，代码的可读性是非常高的。而且phython的第三方质量库确实非常高。phython的应用领域非常广泛，Ruby目前在Web领域比较火，phython的包关系确实不如Ruby。

我们可以了解一下关于PyPy的项目，包括OpenStack，豆瓣管网没有选择，因为它太复杂了。我在豆瓣的时候，豆瓣有一套云的服务叫内部的私有云，简单说就是让工程师开发的时候不必关心的，只需要用现场的东西。实际上一大块东西都是自己实现的。

Part 2  
关于Speed，当时我们选择Speed没有选择Python的原因，一是Speed性能不错，二是用起来非常简单，你用Speed原生的库写起来也非常容易，写数据计算的东西非常容易。而且Speed后来也衍生出很多项目，可以做数据查询和分析。这是Dpark项目，基本上跟Speed是类似的，可以写类似这样的代码，统计一个文本里大概有多少行的东西。

简单说一下Spark和hadoop是一样的东西，Spark是做机器的调度，Mesos下面管着一堆机器，就是这样一个东西。

这个也算是豆瓣的历史了，豆瓣早年间是用SVN管理代码，创作代码拷贝一下，reviewer一下。早年代码结构是这样的，所有的代码其实都在一个代码仓库里，产品是按目录去分，所以当时会预见几个问题。一是构建环境很复杂，全代码都在一个里面，很多很多基础件才能把环境构建起来，非常复杂。同时开发者也非常麻烦，比如我是豆瓣FM的工程师我还要了解音乐读书代码，当时我们做了一个迁移，把所有目录都分别进行了仓库开发。有一套系统做讨论。

其中最重要的界面是这个界面，刚才我提到的类似hadoop的流程，最重要的是这个绿条，其他都不太重要。在做reviewer的时候最重要的一个点是你一定保证你的代码运行是正确的，这个时候你要跑所有的单行测试，这个相当于发出你对代码进行的一次修改，代码并没有直接合并到仓库，首先要进行人为的reviewer，其次这部分代码会去跑所有的单元测试。这个条要保证是绿色的，所有的测试是过的，所有的人都在里面进行reviewer。
这个是豆瓣单元测试覆盖率，动态语言就是这样，刚才虽然很多人举手用Python，但我不知道有多少人为自己的代码写单元测试，我觉得动态语言如果没有单元测试的辅佐未来会非常非常麻烦。

我们做开发的时候刚才提到的reviewer是这样的，大家可以在里面进行充分的讨论。我跟很多用Python的公司交流过，很多人用Python没问题，一直在用，但是动态语言有一点比较讨厌，写法多种多样，动态语言形成方式非常灵活。所以我们认为动态语言进行这种讨论是非常重要的。现在看到的这个项目实际上是我们内部开发的一个系统，类似hadoop系统，完全用的豆瓣技术站，这个系统有一点很好玩，我觉得也是动态语言带来的一个效果。Python用这么多年最大的体会是开发速度非常快，这套系统是豆瓣没有全职工程师开发的一个系统，虽然是我们的基础业务，但这套系统是大家利用业余时间写出来的。比较好的一点在于基本上这里提出的Flatui没有超过一个礼拜的，基本上一周就能搞定，确实得益于快速开发。在豆瓣内部我们尽量保证每一个功能模块开发具体的功能不超过一周，我们认为一般一个功能超过一周，尤其一个月还没开发出来，基本上就开发不出来了，遇到一些很关键性的问题。

今天讲Python的奥妙我一直在想讲什么，尤其是Web，Python不是独立活着的，做Web开发的时候牵扯非常多的前端代码。我不知道其他公司怎么解决前端的事，我简单说说豆瓣怎么做的。在豆瓣而言不分前端工程师和后端工程师，但实际上在真正协作中你会发现，其实很麻烦，对于前端工程师而言他不太可能真的裸写和CSS，你会发现光模板这一件事两人都需要改，后端工程师需要对模板进行修改，前端工程师也需要对模板进行修改，是交叉的。所以豆瓣把职位统一，所有工程师都叫产品开发工程师，什么叫产品开发工程师？这个工程给你了，从前端到后端都由你一个人解决，从头到尾。其他的工程师怎么分离这件事呢？我们认为写Python代码那不叫写后端，其实那个就是写产品，我们认为的后端其实是偏向更底层一点，比如分装，比如你去管理整个集群，整个运维工作我们叫后端，所以当时才有了BAE，让产品开发工程师不用关心这件事，你只需要踏踏实实写Python代码就好，最终运行在服务上。也就是说我们的操作接口都是运维提供的，就像运维提供商一样。我们前端是有专家组的，他们主要是封装一些现成的库，由这些产品工程师去拼装和调用。

到后期的时候，近两年因为架构又发生了一些变化，可以稍微做点分离，现在基本上MVC这套东西其实都推给前端的，整个产品开发都是由前端工程师完成。写Python其实就是写一大堆的API，前端工程师需要用，包括移动端工程师需要用，实现界面的问题，就是这样一个流程。

我为什么一直在强调reviewer这件事呢？每项技能要求不是特别一样，非常复杂。你作为一个人而言技能很难特别全面，在我看来Web开发是非常复杂的一件事，而且理论来讲一定程度你也不可能完全不关心后端，毕竟是你真正在操作这些基础件，你要很清晰的知道什么时候往库里插，什么时候往缓存里插，你要明晰的知道这件事。这就带来一个问题，你的技能未必那么全，你需要更资深的人reviewer一下你使用这些基础件对不对，你写html的是不是规范。

大家知道，豆瓣是整体产品，咱们这里有多少是做产品开发的工程师？很少，大部分是不是都是做后台多一点，做数据后台的举手我看看，偏后台多一点。一般来讲，你的产品再有趣也发现很难坚持很久，你会自己的产品有个倦怠期，我们希望工程师能够写一些好玩的东西。比如他们最近太累了，希望写一点好玩的东西，我们就会让他参与这套系统的开发。我们开发中还有一点用的比较多，表扬系统，这套系统是实习生写的。开发这件事要跟公司整体文化有个对应，我们会发现很多工程师帮别的组的忙，比如帮你做优化调适等等，但是一般工程师都比较内向，不太愿意主动表达。所以我们做了一个系统，让他夸赞对方做的好，类似这样的东西。这个是我们用git的方式，因为后来豆瓣都切换到git，你发现其中有一个需求，你改完了代码，因为是以Checkou出现的，我们希望工程师能够切换一下，做调适或者开发。这个时候我们做了封装，你可以快速拉下所有的Checkou，然后切换过来。这些很多工具都是用Python做的。

Part 3  
包括我们自己写的代码片断的管理系统，这些都是用phython去做的，内部项目的管理系统。这是刚才提到的iPhone版，这是后来最新统计的。这种工作方式带来一个好处，因为我在豆瓣之前在新浪工作了很多年，很多公司的产品开发的人，其实会只专注于某一个部门的开发，人员在内部很难流动起来。在豆瓣有一个好处，你无论去哪个组都是用phython，技能切换比较容易。其次像我刚才说的，我们所有的人其实都是产品开发工程师，这时候会带来一个好处。你可以很容易的切换到另外一个组做事，因为所有的东西都是一样的，没有哪个组是能自己做技术选型，我随便用一个东西就可以上线，现在豆瓣还不可以的，你可以很轻松的换到任何一个组工作。

这些小工具都是豆瓣工程师日常开发的，都是基于phython这些东西做的。这是跟设计师同步的工具，因为我们发现我们试图教设计师用GIT这件事失败了，所以我们后来写了一个客户端，你选一下同步，他的文件就同步下来了，类似这样一个工具。还有一些小的工具配合我们的工作用。我们临走前做了一次统计，用的最多的就是Bee日和clap，有新入职的工程师，他可以给系统增加一些表情，先练练手。

简单总结，Web在我看来是一整套的事，不是phython的事，可以学习到很多东西，知识可以得到传承。最重要的CI持续集中环境可以被有效的利用，大概说一下豆瓣开源的库。因为我们用phython很多年，我临走前干了一件事，尽量把豆瓣的库开源，这是我们操作GIT库，我们做源码统计的库。
这是phython非常老的框架，但是这个框架非常裸，很多功能都没有，我们加一些功能放进去。我个人其实非常喜欢这个框架，如果你是做一个Web开发，你会发现你用着不断的把东西都抛走，最终可能会变成一个URL的东西。最大的硬伤它默认的视图是函数的，没法继承，没法构建出很复杂的视图。这是我们操作数据库的库，也已经开源了。操作数据库是这样的，你可以把库裸联，其实从DBA的角度而言，它有自己的原则，很多公司的DBA我跟他们聊过天，他们非常苦，DBA后来上线才发现你得把这个改了，你没有时间，再也没有改过这个代码。豆瓣是这样做这个事的，我们所有数据库操作没有任何工程师可以直联数据库，他们封装的库表达了自己的情绪。比如说一些原则写在纸上没有人遵守，贴在电脑上他也不会遵守，我们这里会做一些限制，发现语句没有条件直接抛异常，类似这样一些细则。同时对重选做一些隔离，让你不必关心库和表在哪里，我们执行，拿到你想要的数据。
我们还开放内部小型文件分享的服务，这是实时沟通的。豆瓣其实很喜欢能够快速开发的语言，这是我们的渲染库。这个差不多都是豆瓣会用到的很多开源技术，像我们所说的Web开发是一整套技术，很难完全讲phython，phython是虚的，我们会用到C，这个是做代码渲染的，Nodejs用的也很多，Coffeeｓｃｒｉｐｔ是用的比较多的编程语言，它的灵活性太强，所以它的性能是很不错的。 我们的LOGO，因为这个PPT当时是用来讲豆瓣工程师文化的，后来除了在豆瓣写代码以外，给我的任务就是培养工程师文化。我当时一直很头疼什么叫工程师文化，后来只好开始印体恤了，围绕我们系统LOGO做一个体恤出来。所有的工程师是免费领一件，非工程师就得花钱了。当时的定价是一比特币一件，当时差不多是六十块钱人民币左右，后来没有想到比特币就那样了，我今天的分享就这么多，把豆瓣的东西都给大家分享了，大家有什么问题可以提问，谢谢大家。

学习了，总结出来。

不错，看完了