不讲段子的女神不是好的工程师

嘀嗒嘀嗒 2016-01-24


前言:段子讲的不好,技术也讲的一般。但是用段子讲技术,那就凑合可以看了。抽空要把文章末尾的那首《程序员版王妃》的歌词补全。


先声明题目又是江湖君恶搞的。。。


今天笑来老师不知道受什么刺激了。在他的朋友圈看到这样两条状态:


《七年就是一辈子》里,我会加上一个章节:超级段子手如何养成?


不会讲段子的创业者不是好投资人的那啥啥……


我不会讲段子。但是最近那篇《琅琊风云录之初到江湖》登到中生代公众号后,我诸多的头衔之上就又多了个来自山丘君的评价:“文采好,段子一茬一茬。” 然后就被江湖君和友强君每天追着让再写一篇技术的。


这事我们来分析一下。中生代群里面的牛人随手抓,随机点,点到个在技术上比我能侃的概率我估摸着应该在50%以上,跟扔硬币的概率差不多,这还是考虑到有一部分是非技术人员。找我写,我寻思着,不外乎因为女生会敲代码,还能写点技术,这事本身就是个段子。所以写得不好别人也是能原谅的。何况最近发现只要图配得好,阅读量还是可以上去的。还有铁粉如山丘君,就说,你写啥我都是要看的。



不过总得写点和技术相关的吧?否则没法刊登啊,人家怎么也是个技术公众号。这几天好像各个公众号都喜欢写技术选型。最近 MacTalk《技术选择之番外篇》讲了关于选择开源技术的时候要注意哪些东西。今天又看到另外一个公众号登了一篇《技术选型的一些思考》,本来这事大家都写,就不用写了嘛。不过看到这些正好想到一些亲身经历,就正好写写吧。各位当听故事,有没有收获自己体会了。




谁写程序谁做主


没去过大公司,一直混迹在 Square 和 Airbnb 这样的创业小公司,其实我觉得,小公司里技术选型里最关键的因素其实还是公司早期招进来的人是什么技术背景。硅谷很多的小公司,在成立的最初期,大都 Ruby 起家。这事一大部分是因为 Ruby 的开发周期相对较短,且在公司的负载不是太大的初期阶段性能也是足够的。但是这里面还有一个很重要的原因,就是愿意到一个刚刚起步的公司一搏的善于快速开发的极客们更多的是玩的 Ruby。你选个 Java,这个语言再好再强大,这些初创工程师不喜欢,就没用。


不仅公司如此,公司里面的小组也是。公司慢慢变大,原先什么都放在一起的一个大 Service 就会被分割成一个个小 Service,甚至微 Service(关于service,山丘君又新放出了一篇檄文)。写新的子 Service 选什么语言,这也很大程度上取决于是什么背景的工程师参与这个项目。



那么什么时候大家会尝试新的技术呢?见过的大致有三种:


一、公司突然招来个牛人。把他以前的技术也带过来了。


这个见的太多。最身边的例子,一个很有名的机器学习的算法:gradient boosting tree。光说这个名字估计 Facebook,Quora,和 Airbnb 的一些同仁们就知道我说的是哪一桩哪一件了。这个技术就是跟着它的作者走到新的公司,并且不断发扬光大。再举个例子,我们现在用 Java 的 SQL 生成语言 Jooq,很大部分也是因为另一位从 Square 跳过来的码工把这个带过来。



二、极客们就是喜欢学习新技术并尝试到项目中


大家都是程序员,这种对新技术无法言喻的追求和狂热不用多说大家也有很深的体会。有哪个程序员不是一边做着项目,一边抽出时间自学点新的火的技术?并在时机成熟的时候用起来。越小的公司这样的机会就越多。


然而对新技术的尝试有成功的,也有悲剧了的。成功的案例大都相似,悲剧的案例各有各的问题。


举个说近不近的。Spark 和 React 最近很火,各大小公司开始使用,并且在将旧代码移植到这些新技术的过程大都以成功告终。首先,这两个技术都很成熟。其次,用户社群已经很大,如果使用过程中遇到什么问题,网上去 Google 或者工具本身的技术文档就大都能解决。最后,学习和掌握 Spark 或者 React 的工程师也已经有了很大的基数。这种情况下,不论是新公司选技术,还是老公司技术转型,都不会有太大阻力。


再举一个悲剧的例子。PostgreSQL(PG) 其实是很强大的一种 SQL,它在很多技术处理上都超越了 MySQL,比如它的 Query Plan,以及对 Online Schema Change 的支持等。Square 早期正处于 PG 很火的时候,于是就有不少一些 Service 选择了使用 PG,与 MySQL 并存,这本身没有什么问题。但是呢?公司有个 MySQL 巨通的牛人,牛到可能给 MySQL 贡献过部分源代码。而与此同时公司又招不到 PG 很通的工程师。这样,每次 PG 出了问题,没有人会修,或者说没有人特别会修。但是 MySQL 呢,有个牛人坐镇 review 所有 Query 代码,连问题出现的机会都没有。在这种情形下,对 PG 的尝试只能以把所有 Service 转到 MySQL 告终。



三、公司做到一个特定的规模就会有你特定的问题,现有技术大都已经不能满足要求,于是新技术应运而生


这种牛技术通常出现在 Google 级别的大公司。比如前几天才说的 Spanner 数据库管理系统。一方面,Google 的数据量大的惊人,数以百计的数据中心的数百万台机器。另一方面,Spanner 实现了一个用 GPS 和基于原子钟的时间 API。这个 API 能将数据中心之间的时间同步精确到 10ms 以内。从而达到无锁读事务,原子 schema 修改,读历史数据无block等。


再比如蚂蚁金服的 OceanBase,有说法是分布式事务领域的核武器。 某大牛在微博曾表示:金融系统要求在主库故障的时候不能丢失任何数据(地震等天灾人祸除外),MySQL 无法做到这一点(如果不使用共享存储的话)。使用 OceanBase 做数据库,大多数的高可用问题,已然不需要应用这一层感知了。


因此,在这种情况下,技术已经不再是选型,而是创新。




音乐资源加载中...

要结尾了,按惯例是要来一段的(请自行哼唱):


夜太美,尽管再危险,总有人黑着眼眶熬著夜

搞技术,尽管再艰难,愿赔上了一切超支千年的体力

程序员 尽管再卑微 也想尝粉身碎骨的滋味

要加班 尽管再无言 我都想用电脑隔绝世界

我的程序,我要霸占你~的~美~




本站仅按申请收录文章,版权归原作者所有
如若侵权,请联系本站删除
觉得不错,分享给更多人看到
嘀嗒嘀嗒 热门文章:

亲身参与“引力波”项目之体验    阅读/点赞 : 55310/363

说说 Code Review    阅读/点赞 : 29680/314

我的编程之路    阅读/点赞 : 17059/314

迷茫和进步    阅读/点赞 : 14860/361

说说跳槽这件事    阅读/点赞 : 14005/307

从一条读者留言说起    阅读/点赞 : 13835/411

10%,和那背后的 90%    阅读/点赞 : 13518/351

我的博士生导师    阅读/点赞 : 11227/298

程序媛的碎碎念    阅读/点赞 : 9766/370

嘀嗒嘀嗒:我和微信公众号这一年    阅读/点赞 : 7328/354

嘀嗒嘀嗒 微信二维码

嘀嗒嘀嗒 微信二维码