下载本文档
版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
1、Part 1清风:大家下午好!我之前在豆瓣工作,大家一般都叫我“清风”,豆瓣一般都用网名。我在 豆瓣差不多工作了五年,走的时候是豆瓣的技术总监。现在在创业,这次演讲因 为跟MSUP的人很熟,本来没有太想来,因为创业了,准备收山了。今天真的 是收山之讲,以后不能总出来讲了,因为自己也创业了。我自己的项目其实也用 phython做很多事,我用phython差不多用了快十年。豆瓣大家知道一直用 phython做的网站,所以我今天大概跟大家分享豆瓣是怎么用phython的,先泛泛说一下phython都有哪些,我们也可以用提问的方式更多的了解 phython。因为开场自我介绍很麻烦,其实豆瓣有一套内网系
2、统,每个入职的人给自 己打标签,这样的话更容易他是什么样的人。因为我最近在创业,做什么呢?做一个APP,我创业之前当作家,如果大家有时间可以上豆瓣阅读,订一个专栏 叫“寂寞社交”,吃喝玩乐在北京,我们前两天刚搞完九周年的活动,大家不知 道晚上去哪儿玩,可以通过那个组约到很多小伙伴玩。简单介绍一下phython ,我先大概了解一下,咱们这里用过phython的举 过手,都是用过的。用过 Web的举手,数据挖掘的举手,做一些运维工具的举 一下手,phython基本上用在这三个方向。我大概总结了一下, phython基本 的应用场景,一个是 Web开发,也是豆瓣用的最多的。还有就是数据分析,因 为豆
3、瓣是一家很注重数据的公司,非常注重数据,基本上自豆瓣成立的第一天起,我们收集很多数据做数据分析。 因为分布式计算和数据分析放在一起讲, 早年没有什么分布式计算, 十年前中国还没有。 基本上怎么做呢?就是写一个phython脚本算,数据库拿点数一算,差不多就是这样的情况。后来有了 hadoop ,做技术的人,我认为自我技术纯洁性的事情。就像用 phython 的公司可能不愿意用Php 类似这样的案例,包括java 也一样,豆瓣对java 有一点小排斥。我们用起来特别别扭,不是特别顺。后来出来一个东西叫 scipy ,后来我们写了 dpark ,基本上按照 scipy 的功能实现。所以豆瓣的计算是
4、这样的,拿scipy 跑基本的分布式计算,之后到 1/3可能做复杂的计算,可能用 pandas 去做。但是openstack 没有用。phython 其实是这样的,很莫名其妙,在我们用 phython 的人眼里就是这样朴素的用,很多人知道phython 可以做 Web 开发,然后phython 用的慢慢变少。前两年分布式计算数据分析特别火,虽然很多公司使用 hadoop ,phython 又火了,因为 pandas ,大家用就知道这些库很好用, phython 又火了一段时间。 这两年云计算火了, 很多人又开使用 phython 。在我看来,从曲线大家可以看到 phython 的流行度。我用这
5、么多年phython ,我觉得它一直是一个很朴素的编程语言,我觉得 phython 是用来解决问题的, 它并不花哨, 基本上你想解决的问题都可以解决。 很多人问我一个问题, 豆瓣为什么没有考虑用其他语言, 比如说用其他的语言。 我们的经验是这样的, 其实我们也不是没有想换过, 也尝试过其他的。 但是在实际应用场景中发现,我们用 phython 也没有遇到完全不能解决的问题, 所以 phython 基本上用在这 几个场景上。phython 的优点,因为大家都用过,我简单说一下,因为它比较简单,扩展免费,可以用到一些工具。而且phython 确实不是一个玩具,因为我不知道多少人把 phython
6、用在生产环境。大家可以看到业内的案例 NASA 在用,包括Google 本身,包括Dropbox ,毕竟我现在也创业了,像phython 这种语言,它起步非常快。因为所有人几乎都知道,它的性能现在好点了, 2.0 之前它的性能是比较差的, 我觉得有一句话说的非常经典, 它的性能能达到什么程度, 它刚刚好能支撑这家公司融到 A 轮,很经典的一句话。关键是要快,其他的语言性能很好,但是你没有到 A 轮就饿死了,基本上是这样的。所以 Dropbox 非常好,后期是这样的, phython 的性能也够了。如果有人跟你吹phython的性能比C好,根本不用理他,转身走就可以了。包括Quora ,因为 P
7、yPy3.0 它是一个很奇怪的产品,没有解决特别关键性的问题,那是phython 性能的硬伤。 PyPy 会在这方面做很多的优化和调整,从目前来看性能还是不错的。但是有一点确实跟Quora 没法比, Quora 把 PyPy 招进去了,我个人比较看好PyPy 。再说一下豆瓣, phython 几乎你想到的东西,我们的运维脚本、 Web 开发、计算工具等等, 几乎所有的东西都用phython 写的, 应用在豆瓣所有的场景中。这个 Languages in ,大家知道现在的世界是前端的,早晚也是前端的,前端就是太猛了。前端工程师更疯狂了,原来只能写前端,现在居然可以写后端。Languages in
8、 在豆瓣用的非常多,那是一个前端非常重要的项目。包括后来有些开发节奏也是这样的, 因为大家知道开发效率高有很大的优点, 第一个版本实际上因为开发快, 前端工程师自己搞定上线了, 但是它的性能无法评价, 太差了。没有关系, 还是那句话, 它可以很快的上线, 而且后期豆瓣做广告投放了, C+我们知道是一个库, phython 有一个天生的优点,因为我入行比较早,我们那个时代写 C 或者是 C+ 。有一个很好的点, C 性能绝对够好,但是写起来开发速度比较慢。 但是 phython 跟 C 的结合是最容易的, 比如说你可以用 C 解决一些核心的库,所以合作起来会非常方便。我们讲 phython ,很
9、多公司知道豆瓣用 phython ,这个确实没错。但是实际上我们除了 phython 之外,我对phython 是这样理解的, phython 真的只是一门编程语言。 我在豆瓣工作五年, 我觉得豆瓣最值得拿来说的是豆瓣的协作流程, 大家知道 phython 是一门动态语言, 动态语言其实有很多问题是天生的。比如说你可以做类型的检查, 可以做很多事情, 可以在编译方面做很多事情。 这个时候实际上所有做动态语言的公司, 对单元测试重视程度非常高, 今天恰好第三个话题也是豆瓣的同事来讲测试,豆瓣对测试的重视程度非常高。简单来说,豆瓣是做Code ,也有一套自己的原则。比如说随便举两个点,咱们这里有多
10、少人用过, 因为现在的开源项目,大家基本上都是在dadhoop 上面协作, 你想参与这个项目的开发, 实际上豆瓣内部就是这套流程, 你对它针对性的进行一些修改,在这个上面大家可以进行充分的沟通和交流,交流什么东西?因为是phython ,因为它是编码风格,不管是C+ ,一定要有变成规范,细到什么程度呢?函数如何命名,两个函数之间空多少行,是空格还是不空格。但是这个有工具检查,我们人为的看这些东西。再有就是测试,因为作为这个项目而言,你是靠什么证明的呢?你不能靠嘴说, 在我的电脑上运行是最好的, 你的团队有问题。 但是这个其实是有问题的,你需要证明自己的代码是正确的,只能靠测试,这样别人安装的时
11、候负担也会小 很多,因为我们有良好的集中测试环境可以做这样的事情。简单来说代码一定要经过reviewer ,因为这个是要承担的,这个代码上线 了有BUG,不是光写代码的人有责任,reviewer的人同样承担责任,下面是 phython 的 Hello word。Ruby其实是一门很强的语言,个人实话实说确实Ruby比phython强,它的可读性更强一些。从我们豆瓣这么多年的经验来看强制缩进带来的好吃是非 常大的,因为编译过不去必须要靠缩进,一定要少些括号。因为强制缩进,代码 的可读性是非常高的。而且phython的第三方质量库确实非常高。phython的 应用领域非常广泛,Ruby目前在Web
12、领域比较火,phython的包关系确实不 如 Ruby。我们可以了解一下关于PyPy的项目,包括OpenStack ,豆瓣管网没有选择, 因为它太复杂了。我在豆瓣的时候,豆瓣有一套云的服务叫内部的私有云,简单说就是让工程师开发的时候不必关心的,只需要用现场的东西。实际上一大块东西都是自己实现的。Part 2关于Speed,当时我们选择Speed没有选择Python的原因,一是Speed 性能不错,二是用起来非常简单,你用 Speed原生的库写起来也非常容易,写 数据计算的东西非常容易。而且 Speed后来也衍生出很多项目,可以做数据查 询和分析。这是Dpark项目,基本上跟Speed是类似的,
13、可以写类似这样的代 码,统计一个文本里大概有多少行的东西。简单说一下Spark 和 hadoop 是一样的东西, Spark 是做机器的调度,Mesos 下面管着一堆机器,就是这样一个东西。这个也算是豆瓣的历史了,豆瓣早年间是用 SVN 管理代码,创作代码拷贝一下, reviewer 一下。早年代码结构是这样的,所有的代码其实都在一个代码仓库里, 产品是按目录去分, 所以当时会预见几个问题。 一是构建环境很复杂,全代码都在一个里面, 很多很多基础件才能把环境构建起来, 非常复杂。 同时开发者也非常麻烦, 比如我是豆瓣FM 的工程师我还要了解音乐读书代码, 当时我们做了一个迁移, 把所有目录都分
14、别进行了仓库开发。 有一套系统做讨论。其中最重要的界面是这个界面, 刚才我提到的类似hadoop 的流程, 最重要的是这个绿条,其他都不太重要。在做reviewer 的时候最重要的一个点是你一定保证你的代码运行是正确的, 这个时候你要跑所有的单行测试, 这个相当于发出你对代码进行的一次修改, 代码并没有直接合并到仓库, 首先要进行人为的reviewer , 其次这部分代码会去跑所有的单元测试。 这个条要保证是绿色的, 所有的测试是过的,所有的人都在里面进行reviewer 。这个是豆瓣单元测试覆盖率,动态语言就是这样,刚才虽然很多人举手用Python ,但我不知道有多少人为自己的代码写单元测试
15、,我觉得动态语言如果没有单元测试的辅佐未来会非常非常麻烦。我们做开发的时候刚才提到的 reviewer 是这样的,大家可以在里面进行充分的讨论。我跟很多用 Python 的公司交流过,很多人用 Python 没问题,一直在用, 但是动态语言有一点比较讨厌, 写法多种多样, 动态语言形成方式非常灵活。 所以我们认为动态语言进行这种讨论是非常重要的。 现在看到的这个项目实际上是我们内部开发的一个系统,类似hadoop 系统,完全用的豆瓣技术站, 这个系统有一点很好玩,我觉得也是动态语言带来的一个效果。 Python 用这么多年最大的体会是开发速度非常快, 这套系统是豆瓣没有全职工程师开发的一个系统
16、, 虽然是我们的基础业务, 但这套系统是大家利用业余时间写出来的。 比较好的一点在于基本上这里提出的Flatui 没有超过一个礼拜的, 基本上一周就能搞定, 确实得益于快速开发。 在豆瓣内部我们尽量保证每一个功能模块开发具体的功能不超过一周,我们认为一般一个功能超过一周,尤其一个月还没开发出来,基本上就开发不出来了,遇到一些很关键性的问题。为什么放这么一个截图呢?今天讲Python 的奥妙我一直在想讲什么,尤其是 Web , Python 不是独立活着的,做Web 开发的时候牵扯非常多的前端代码。 我不知道其他公司怎么解决前端的事, 我简单说说豆瓣怎么做的。 在豆瓣而言不分前端工程师和后端工程
17、师, 但实际上在真正协作中你会发现, 其实很麻烦,对于前端工程师而言他不太可能真的裸写和 CSS, 你会发现光模板这一件事两人都需要改, 后端工程师需要对模板进行修改, 前端工程师也需要对模板进行修改,是交叉的。 所以豆瓣把职位统一, 所有工程师都叫产品开发工程师, 什么叫产品开发工程师?这个工程给你了, 从前端到后端都由你一个人解决, 从头到尾。 其他的工程师怎么分离这件事呢?我们认为写 Python 代码那不叫写后端, 其实那个就是写产品, 我们认为的后端其实是偏向更底层一点, 比如分装, 比如你去管理整个集群,整个运维工作我们叫后端,所以当时才有了BAE ,让产品开发工程师不用关心这件事
18、, 你只需要踏踏实实写 Python 代码就好, 最终运行在服务上。 也就是说我们的操作接口都是运维提供的, 就像运维提供商一样。 我们前端是有专家组的, 他们主要是封装一些现成的库, 由这些产品工程师去拼装和调用。到后期的时候,近两年因为架构又发生了一些变化,可以稍微做点分离,现在基本上MVC 这套东西其实都推给前端的, 整个产品开发都是由前端工程师完成。写 Python 其实就是写一大堆的 API ,前端工程师需要用,包括移动端工程师需要用,实现界面的问题,就是这样一个流程。我为什么一直在强调 reviewer 这件事呢?每项技能要求不是特别一样,非常复杂。你作为一个人而言技能很难特别全面
19、,在我看来Web 开发是非常复杂的一件事, 而且理论来讲一定程度你也不可能完全不关心后端, 毕竟是你真正在操作这些基础件, 你要很清晰的知道什么时候往库里插, 什么时候往缓存里插, 你要明晰的知道这件事。 这就带来一个问题, 你的技能未必那么全, 你需要更资深的人 reviewer 一下你使用这些基础件对不对, 你写 html 的是不是规范。大家知道,豆瓣是整体产品,咱们这里有多少是做产品开发的工程师?很少, 大部分是不是都是做后台多一点, 做数据后台的举手我看看, 偏后台多一点。一般来讲,你的产品再有趣也发现很难坚持很久,你会自己的产品有个倦怠期,我们希望工程师能够写一些好玩的东西。 比如他
20、们最近太累了, 希望写一点好玩的东西,我们就会让他参与这套系统的开发。我们开发中还有一点用的比较多,表扬系统, 这套系统是实习生写的。 开发这件事要跟公司整体文化有个对应, 我们会发现很多工程师帮别的组的忙, 比如帮你做优化调适等等, 但是一般工程师都比较内向, 不太愿意主动表达。 所以我们做了一个系统, 让他夸赞对方做的好,类似这样的东西。这个是我们用 git 的方式,因为后来豆瓣都切换到 git ,你发 现其中有一个需求,你改完了代码,因为是以 Checkou 出现的,我们希望工程 师能够切换一下,做调适或者开发。这个时候我们做了封装,你可以快速拉下所有的Checkou,然后切换过来。这些
21、很多工具都是用Python做的。Part 3包括我们自己写的代码片断的管理系统,这些都是用phython去做的,内部项目的管理系统。这是刚才提到的iPhone版,这是后来最新统计的。这种 工作方式带来一个好处,因为我在豆瓣之前在新浪工作了很多年, 很多公司的产 品开发的人,其实会只专注于某一个部门的开发,人员在内部很难流动起来。在豆瓣有一个好处,你无论去哪个组都是用 phython ,技能切换比较容易。其次 像我刚才说的,我们所有的人其实都是产品开发工程师,这时候会带来一个好处。 你可以很容易的切换到另外一个组做事,因为所有的东西都是一样的,没有哪个组是能自己做技术选型,我随便用一个东西就可以
22、上线,现在豆瓣还不可以的, 你可以很轻松的换到任何一个组工作。这些小工具都是豆瓣工程师日常开发的,都是基于phython这些东西做的。这是跟设计师同步的工具,因为我们发现我们试图教设计师用GIT这件事失败了,所以我们后来写了一个客户端,你选一下同步,他的文件就同步下来了,类 似这样一个工具。还有一些小的工具配合我们的工作用。 我们临走前做了 一次统 计,用的最多的就是Bee日和clap ,有新入职的工程师,他可以给系统增加一 些表情,先练练手。简单总结,Web在我看来是一整套的事,不是 phython的事,可以学习到很多东西,知识可以得到传承。最重要的CI持续集中环境可以被有效的利用,大概说一下豆瓣开源的库。 因为我们用 phython 很多年, 我临走前干了一件事,尽量把豆瓣的库开源, 这是我们操作GIT 库, 我们做源码统计的库。这是 phython 非常老的框架,但是这个框架非常裸,很多功能都没有,我们加一些功能放进去。我个人其实非常喜欢这个框架,如果你是做一个Web 开发,你会发现你用着不断的把东西都抛走,最终可能会变成一个
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
最新文档
- 2024年建筑项目安全保证协议
- 文书模板-《合伙销售白酒合同》
- 2024年教育培训业务合作协议
- 2024年度车辆租赁化三方协议
- 2024年协议补充条款模板
- 2024印刷服务协议模板
- 2024年度不锈钢护栏施工协议
- 2024年品牌女包销售协议模板
- 陕西省汉中市勉县2024-2025学年高一上学期11月期中英语试题(含解析无听力音频有听力原文)
- 2024年度职业装订制销售协议样本
- A0422脱密期回访记录表
- 饲料加工系统粉尘防爆安全规程
- 妇产科学课件:胎心监测
- 新苏教版科学四年级上册学生活动手册习题与讲解
- 基础护理质量标准及考核评分表
- 商务条款响应表
- 二年级上册美术教案-7. 去远航 -冀教版
- 二年级上册语文课件-10《日月潭》|人教(部编版) (共19张PPT)
- 《诗情画意》教学设计
- 中华文化与传播教材课件
- Unit3 Sports and Fitness Reading for writing健康生活讲义-高中英语人教版(2019)必修第三册
评论
0/150
提交评论