技术与商业案例解读
徐飞
华为云资深总监，大数据专家
立即订阅
10161 人已学习
课程目录
已完结 163 讲
0/6登录后，你可以任选6讲全文学习。
开篇词 | 突破技术思维，站在商业的角度看问题
免费
001 | 西雅图IT公司之RealNetworks：一个帝国的兴衰（上）
002 | 西雅图IT公司之RealNetworks：一个帝国的兴衰（下）
003 | 以RealNetworks为例，谈谈初创公司如何应对巨头碾压
004 | 可视化分析鼻祖Tableau
005 | 从Tableau上市，看学术界和工业界人士创业
006 | 在线旅游帝国Expedia崛起的背后
007 | 房产经纪的颠覆者Redfin：在“传统”与“现代”间徘徊
008 | 房产经纪的“协作者”Zillow：一个地产数据平台
009 | 颠覆还是协作，房地产市场上Redfin和Zillow的抉择
010 | 应用交付网络大厂F5：“一招鲜”之殇
011 | 在线差旅报销鼻祖Concur：在转型中获得发展
012 | 漫谈企业转型：在市场变迁中寻找生机
013 | 克雷公司沉浮录：行走在超级计算机市场
014 | “单一化”的隐忧：从克雷公司看“一条腿走路”
015 | Halo的开发者Bungie：与微软的聚散
016 | “卖身”须谨慎：创业公司面临的抉择
017 | 亚马逊领导力准则之要有硬骨头
018 | 亚马逊领导力准则之决策正确
019 | 亚马逊领导力准则之客户至尚
020 | 亚马逊领导力准则之勤俭节约
021 | 亚马逊领导力准则之主人翁精神
022 | 亚马逊领导力准则之选贤育能
023 | 亚马逊领导力准则之最高标准
024 | 亚马逊领导力准则之创新简化
025 | 亚马逊领导力准则之崇尚行动
026 | 亚马逊领导力准则之远见卓识
027 | 亚马逊领导力准则之好奇求知与赢得信任
028 | 亚马逊领导力准则之刨根问底与达成业绩
029 | 智能音箱的战斗：亚马逊的硬件路
030 | 智能音箱的战斗：Echo攻城略地
031 | 智能音箱的战斗：语音助手Alexa
032 | 智能音箱的战斗：谷歌的杀入
033 | 智能音箱的战斗：亚马逊的战略布局
034 | 智能音箱的战斗：巨头纷纷入场
035 | 智能音箱的战斗：白马非马
036 | 如何透过一个领域去联合分析多家企业？
037 | 管中窥豹之从面试看企业文化：微软
038 | 管中窥豹之从面试看企业文化：亚马逊
039 | 管中窥豹之从面试看企业文化：谷歌
040 | 管中窥豹之从面试看企业文化：甲骨文
041 | 管中窥豹之从面试看企业文化：Facebook
042 | 透过企业用人之道看企业发展
043 | 办公软件的战斗：开篇
044 | VisiCalc：第一个电子表格软件的诞生
045 | WordStar：第一个字处理软件的故事
046 | 微软：办公软件战场的螳螂
047 | WordPerfect：字处理软件的新秀
048 | Lotus 1-2-3：莲花公司的电子表格帝国
049 | 红狮会战：微软的反击
050 | 大杀器Lotus Notes 和被收购的莲花公司
051 | 无敌寂寞的微软之为创新而创新
052 | 办公软件的新时代：微软和谷歌的战斗
053 | 异军突起的Slack
054 | 办公软件战斗的启示：内忧总是强于外患
055 | 办公软件战斗的启示：敌人的出现常常出其不意
056 | 半条命的Dota帝国Valve：半条命
057 | 半条命的Dota帝国Valve：Steam平台
058 | 半条命的Dota帝国Valve：Dota 2
059 | 半条命的Dota帝国Valve：无领导管理
060 | 半条命的Dota帝国Valve：虚拟现实
061 | Gabe Newell：Valve帝国制度的利弊
062 | 文档数据库的缔造者MongoDB（上）
063 | 文档数据库的缔造者MongoDB（下）
064 | 以MongoDB为例，看基础架构类产品创业
065 | 直面MongoDB，谈微软的NoSQL战略
066 | Hadoop三国之魏国Cloudera
067 | Hadoop三国之吴国MapR
068 | Hadoop三国之蜀国Hortonworks
069 | Hadoop及其发行商的未来
070 | 谷歌的大数据路：从“三驾马车”到一无所有
071 | 谷歌的大数据路：一场影响深远的论战
072 | 谷歌的大数据路：谷歌的“黑科技”
073 | 如何读懂类似谷歌“三驾马车”这样的技术论文？
074 | 雅虎：大数据领域的“活雷锋”
075 | IBM的大数据路之起早贪黑赶了晚集
076 | 社交公司们的大数据贡献
077 | 微软的大数据发展史：微软硅谷研究院
078 | 微软的大数据发展史：必应的Cosmos
079 | 微软的大数据发展史：Azure的大数据发展
080 | 亚马逊的大数据故事：从先驱者到插管吸血开源
081 | 亚马逊的大数据故事：创新和拿来并存的云服务
082 | 阿里巴巴的大数据故事：数据分析平台发展史
083 | 阿里巴巴的大数据故事：流计算引擎发展史
084 | 大公司的大数据战略得失：自建轮子成本高
085 | 大公司的大数据战略得失：抱团取暖难敌插管吸血者
086 | Palantir：神秘的大数据独角兽
087| Splunk：机器大数据的分析帝国
088 | Confluent：在Kafka上飞驰的数据交换者
089 | Powerset：HBase的老东家
090 | Cassandra和DataStax的故事
091 | Databricks之Spark的数据金砖王国
092 | Data Artisans：浴火重生的新一代大数据计算引擎Flink
093 | Dremio:在Drill和Arrow上的大数据公司
094 | Imply：基于Druid的大数据分析公司
095 | Kyligence：阿帕奇麒麟背后的大数据公司
096 | Snowflake:云端的弹性数据仓库
097 | TiDB：一个国产新数据库的创业故事
098 | 大数据创业公司的前景：红海创业多艰辛
099 | 如何通过企业技术积累去分析一家企业？
技术与商业案例解读
登录|注册
125 | Facebook的黑客精神
徐飞 2018-07-20
今天我们说到的 Facebook 黑客精神，并非是指 Facebook 培养了一堆黑客，有很强的黑科技，并在全世界各地研究各种安全漏洞，做出各种黑客应该不应该做的事情。在这里我们讲的黑客精神其实是 Facebook 对待软件开发的态度和方式。
Facebook 的创始人马克·扎克伯格有一句名言：“迅猛而动，突破前行”（Move Fast and Break Things）。这句话也成为了 Facebook 的座右铭。在 Facebook 的公司里，到处都贴着这句话。
这句话非常有名，它甚至深深地影响了整个 Facebook 对待软件开发的态度。那么这句话到底是什么意思，它带给 Facebook 的到底又是什么结果呢？
“迅猛而动，突破前行”的意思在扎克伯格看来，就是软件开发不要想太多，写出来的东西就发布出去，哪怕写出来的东西不太对，这里那里可能会有问题。如果出大问题的话，赶紧修好就可以了。
扎克伯格认为，让市场上见到东西的速度是很重要的。一个东西如果拖着，等久了可能就晚了，所以，他并不认同传统企业，乃至某些类似谷歌这样的互联网公司对待产品和代码的态度。
他觉得大家每个人就应该像黑客一样，在代码里乱改顺便把新功能实现了。然后可以快速地给用户用，这是一条正确的道路。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《技术与商业案例解读》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(10)
Dr. ZZZ哈哈，飞总总结得很好！我本人就是在Facebook工作，加入后，才体会到公司贯彻快糙猛很彻底。 其实本人也一直从事数据库方面的开发，原先是在Pivotal Greenplum里做Query Optimizer ORCA的。后来加入了Facebook, 虽然没有接着做这块(主要看了Presto, 感觉好像不是很看好)，但还是对大数据这块非常关注。 读这个专栏，学到很多。不知道飞总现在还在西雅图吗？有机会来湾区很想当面认识您，再谢谢您的专栏。2019-01-13 5
幻想哈哈，好文章。2018-07-21 3
biliA Philosophy of Software Design第三章也用Facebook为例讨论了类似的主题。文中定义并比较了两种编程模式：tactical战术编程着眼于尽快实现功能，而与之相反的strategic战略编程则着眼于好的设计，顺便实现功能。短期来看战术编程能更快出活，但长期来看由于技术债越积越多，开发效率将落后于战略编程。很多公司刚起步时会想着设计好不好以后再说，这里最危险的点在于，一旦有了拖延的想法，明日复明日，最后可能就积重难返了。作者提出的建议是，好的设计一开始就需要是目标之一，可以调节这方面投入的比例，但不能是零。Facebook作为反面教材在书中自然也是被大肆批判了一番。2018-11-23 2- Dr. ZZZ再和飞总说个我自己参与的大数据相关的创业项目，离开Pivotal当时是因为在Pivotal的director做了这么多年数据库意识到一个问题就是，即使后面出来的数据库性能更高，还便宜，但想要从老牌数据库公司挖客户(比如Oracle, Teradata) 还是很难，痛点就是migration。即使application code用的是jdbc或者odbc, 正真migrate起来也不是换个driver就行，更别说很多老客户用bteq这种原生client. 这个director (Florian Waas)出来就创立了Datometry，我就当时也心一横也扎进去啦。Datometry version就想做vmware in terms of database，作为一个中间键，连接在客户的application和后端新数据库之间，而且保证底层协议端完全兼容(客户端相当于只要改个数据库ip地址就行)，然后对所有请求，做runtime transfer和rewrite外加结果集的转换。我在那做了两年多，后来因为感觉发展有些缓慢，而且公司也经历了多次pivot, 外加也想尝试些新东西就离开了。那个时候我们已经有不错的POC版本，前段可以支持teradata, 后端支持psql兼容的，比如Grrenplun, redshift. 但感觉离production ready还是有距离，诚然，我觉得技术上难度挺大的。 已经离开两年了，感觉现在还是不瘟不火。很想听听飞总对这样一个公司和技术的理解。多谢。
作者回复: 数据库这个东西真的是不好做，尤其这种做中间件想法的，我是不看好。IBM sybase都想过这样的做法都挂了。
2019-01-13 1 
ByteFeng你的公众号的名字是什么，我去关注关注。还有你平常写不写技术博客，或者看不看技术博客，有没有，在大数据领域，技术博客写得不错的，推荐推荐。作者回复: 飞总聊IT
2018-07-21 1
北冥Master谷歌刚开始创业的时候，代码质量也很差。jeff进来以后完全重构2019-09-12- Geek_aea02e当一个人一无所有的时候，唯一的办法就是拼力气。但是到了一定阶段，有了深度，就不需要拼力气了。实际很理解小扎的这种想法。小扎就是穷缀学生。拿他跟谷歌两个创始人比，实在是委屈呀。2019-08-30
eposMove Fast and Break Things 这句话在企业创业起始阶段 是最大的优势2019-05-02
PandaFB 虞兮虞兮奈若何2019-02-26
逝水流年大开眼界啊 很有意思2018-12-14
收起评论