Browsed by
分类:杂项资源

SteveY对Amazon和Google平台的吐槽

SteveY对Amazon和Google平台的吐槽

Steve Yegge, Amazon的前员工,现任Google员工,其本来想在Google+上和Google的员工讨论一些关于平台的东西,结果不小心把圈子设成了Public,结果这篇文章就公开给了全世界,引起了剧烈的反应。发布后很快他就马上把这篇文章删了,不过,互联网上早备份了下来——SteveY’s Google Platforms Rant。后来,Steve在其Google+上作了一些解释,大体是说他喝多了,而且又是在凌晨,所以大脑不清,文章中的观点很主观,极端且不完整,还有Google的PR对他很好,等等,等等 。

几个星期前看到时就一直都想翻译一下这篇文章,不过因为最近事情太多,文章又很长,所以现在才翻译完成,翻译的不好,还请大家指正。

导读

在你阅读正文以前,我想说明几点,希望你注意一下:

  • Steve这个人非常喜欢写长篇大论的东西。而且比较喜欢辛辣调侃和恶搞的文风,这点大家要注意!
  • 文中先“骂”Amazon公司,再通过“骂”Amazon的创始人贝索斯Bezos并烘托出他的的悟性和雄心,最后教育了一下Google。
  • 我把文章分成了三个部分,这样方便大家阅读和讨论。第一部分只是个人情绪化的抱怨,第二部分是说Amazon的成长,第三部分是教育Google,我觉得第二部和第三部分是重点。
  • 对于我们来说,我们应该获取Steve那些关于平台(Platform)相关的那些有价值的观点。尤其是他说的Amazon如何进化成一个平台性的公司,以及阐述Google应该怎么做的那些观点。
  • 关于对Amazon的那些指责,我想说,6年,对于一个世界级的互联网公司,已经很不一样了。

正文

第一部分

我曾在Amazon工作了六年半,现在,我在Google的日子也差没不多这么长了。对于这两家公司,有一件事总是萦绕着我——这种感觉一天比一天强烈──那就是,Amazon每件事都做错了,而Google每件事都做对了。当然啦,这是很笼统的话,但却是惊人的准确,相当的疯狂吧。大概有一百甚至两百种不同的地方可以让我们去比较这两个公司,而Google可能在每一项都能胜出,如果我记的没错,除了其中3项以外。因为,我曾用电子表格把这些项都列出来了,只是法务部门不会让我给任何人看,即使人事招募部门很喜欢这个报表。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (44 人打了分,平均分: 4.89 )
Loading...
多些时间能少写些代码

多些时间能少写些代码

我在我的微博上说过这样一段话,我想在这里把我的这个观点阐述地更完整一些。

@左耳朵耗子:聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30% – 50%的时间是在忙碌着编码,调试和测试。聪明的老板也会让团队这样做。而傻逼的老板,苦逼的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix 大量的bug… 所以, 越差的团队一般会越忙,而且还忙不完。

在现在这个浮躁的时期,再加上敏捷咨询师们念的歪经,他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的,这令那些管理者们很兴奋,就像巴甫洛夫的条件反射实验中的狗看到了肉就会流口水那样兴奋。他们使用TDD,快速迭代,不断重构,持续集成直至持续部署的方法在进行软件开发。

软件开发真是这样的吗?难道不需要花时间去思考吗?对此,有些观点在Todd的《“品质在于构建过程”吗?》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点:

  • 软件的精髓在于设计,设计是一件很费大脑的事件。对于软件来说,设计没有完美的,它总是一件需要取舍需要权衡的事,比如:时间换空间,空间换时间,TCP或UDP,同步还是异步,数据冗余还不冗余等等。那怕是一个小小的observers模式是pull方式还是push方式 都需要仔细讨论。这些的东西需要时间和做前期尝试。
  • TDD快速原型和迭代可能会对软件和团队产生负面影响。在一开始,你需要花很大的精力来让你的软件从无到有(做过软件的人都知道,从零开始写代码是很痛苦的事),但是因为你没有想好,先做再说,所以,后期你会面临更多的质量问题而让你需要花更多的时间精力。当然,那些咨询师会让你用持续集成和持续部署这样的方法。但我想告诉你,这并不解决你软件设计的缺陷。举个例子——TDD、迭代、原型只关注功能性需求,其不会关注非功能性需求,比如性能问题,高可用性问题,系统维护问题(模块的耦合问题),等等。而这些问题往往都可以让你的软件设计重新来过。
  • 重构是恶梦,重构应该越少越好。当你维护一个复杂的系统时你会知道重构是一件多么恐怖的事情(参看《重构代码的7个阶段》)。如果一开始没有想好,你要面临的不单单是re-design, re-architect,还要面对时间和人力成本的增加,最难的是你还要面对的是团队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (21 人打了分,平均分: 4.38 )
Loading...
Stay Hungry, Stay Foolish !!

Stay Hungry, Stay Foolish !!

在整个社会都在关注乔帮主的时候,我想在这里和大家分享一个真实的就在我们程序员身边的故事。和我在《如果你看不见你还能编吗?》一文里介绍的那些盲人程序员一样,同样是Stay Hungry, Stay Foolish。但我个人更认为我今天想要给大家讲述的这个故事对于我们这些普通人更有意义一些。我真心的希望大家认真看完这个“从刷厕所到程序员”故事后,我们能从中感悟到点什么

因为朋友的原因,我和一个创业团队经常有些往来,通过这个团队,我认识了这个故事的主人翁——王平(@wpingsuper)。其实,很早前他在Google Reader和Buzz里follow了我,但我从没和他交流过。而他的经历我却是在上周末去看望这个创业团队的时候才听说。我问他们要了王平的电话,联系了王平,详细地了解了王平的经历,并征得他的同意,在这里给大家分享他的故事。

王平是一个贵州人,03年大学毕业,体育专业,没有任何家庭背景,只能在贵州的山区里的一个中学里当体育老师,月薪150元。可能和大多数心怀梦想的年轻人一样,他并不甘心,从03年到05年间,他有好多次到北京,他觉得在大城市里有他的梦想。于是,他在04年底,05年初,他正式来到了北京,因为大学专业的问题,他无法找像大学生一样找到不错的工作,那时的他只能在北京一家很小的餐馆当清洁工,他在餐馆里洗盘子,扫地,刷厕所,一个月400元钱。

因为他的学历是这个小餐馆里学历最高的,所以,餐馆里出了什么事都会让他对去搞,所以,财务使用的电脑有了故障也让他去修,当时的他根本对电脑完全不知道是怎么一回事,但是自从接触了电脑以后他就迷上了电脑。他和我说,他这个人就是好奇心强,好动,什么都想弄一弄,所以,时间长了,弄得多了,也能为餐饮解决一些没有懂的问题,维护财务电脑就是其中之一。日子一长,虽然还是刷厕所,但是薪水也涨到了800元一个月,就连餐馆的大厨也对他说,他不属于这里,他将来一定会有前途的。当时的他还觉得不可能,笑了笑就过了。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (72 人打了分,平均分: 4.97 )
Loading...
Test-Driven Development?别逗了

Test-Driven Development?别逗了

这篇文章来源于Peter Sergeant在Write More Test 博客上的《Test-Driven Development? Give me a break…》,在原文和Reddit 上有很大反响。这篇文章里的很多观点在《TDD并不是看上去的那么美》和《再谈敏捷和TW咨询师》里都出现过(我个人觉得我的观点比其更全面一些)。就像我转的《Scrum为什么不行》 和《Bob大叔和Jim Coplien对TDD的论战》一样,从这些贴子我们可以看到——这是一个全世界的问题,并不是只有在中国才有的问题

很多敏粉都在说我在是喷敏捷,黑敏捷,向敏捷泼脏水,我只想对这些人说——你们这样的见解很肤浅也很敏感,你们根本就没有认识到——争论,反思和不同观点的意义,你也就无法了解你们所信仰的敏捷!你们只是在肤浅和盲目地信仰和教条敏捷中的许多名词、方法和标准答案罢了

——————————————正文开始——————————————

对于程序员来说有些事有非常危险的信号(red flag)。当我听到有人开始信仰Test-Driven Development 是 One True Programming Methodology(唯一正确的编程方法论),这就是危险信号(red flag),我开始假设你是一个劣等、没有经验的程序员,或是某些敏捷咨询师。

测试只是一个工具来帮助你,而不是用来证明谁比谁更虔诚,或是我的屌比你的要大,等这种愚蠢的行为。测试是用来让程序员得到有帮助的、更快的反馈,从而找到正确的路径,如果你搞坏一些事,其还可以用来给后人一些警告。这根本就不是一个神秘的有魔力的方法其可以让你的代码变得更好……

整个Test-Driven Development的概念是麻痹和信奉,从而让其成为你的人生观。相反的:Developer-Driven Testing,它给你和你的同事一些有用的工具来解决问题,来支持你自己,而不是那种以工具或方法为中心的让你假设其应该是那样的测试。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (11 人打了分,平均分: 4.27 )
Loading...
“品质在于构建过程”吗?

“品质在于构建过程”吗?

感谢@weidagang (Todd)向酷壳投递的这篇精彩的文章。原文

今天在微博上看到几位敏捷爱好者探讨敏捷测试和质量保证问题,我忍不住也加入了讨论:

Z先生原帖:我刚才看到一个大会演讲稿,谈到敏捷测试六大指导原则:1.仅靠测试人员不可能获得高质量的软件,质量是整个研发团队的责任;2. 场景是不可穷举的,测试活动必须是风险驱动的,关注于高风险的场景;3.分层自动化测试是唯一出路;4.在正确的位置进行恰当的测试是自动化的关键;【待续】

S先生回复:品质在于构建过程。检验贯穿构建过程,提供及时反馈。

我回复:什么样的构建过程才能出Unix这样的品质呢?迭代?快速反馈?TDD?

S先生回复:据说stroustrup听到重构时的反应是,我们从七十年代就这样做了。推荐《UNIX编程环境》,了解大师的编程方式。

我回复:您偷换了概念。不能说大师用了重构,C++和UNIX的品质就是靠重构或某种构建过程得来的。厨师做菜用到了勺子,不等于菜好吃是因为勺子。

S先生回复:我没有概念。我们看到一个果,就问因是什么。其实是泛因果,无因果,一切是机缘凑巧。

我回复:“品质在于构建过程”难道不是一个明白的因果描述吗?

S先生回复:品质在于构建的人。我说话时没因果,你看到了因果。

我回复:欢迎敏捷爱好者围观!

很高兴几个回合讨论下来S先生修正了先前“品质在于构建过程”的观点。什么重构、TDD、迭代、快速反馈等等构建过程都不是Unix品质的核心要素。我不但不认同“品质在于构建过程”、“测试是最好的设计方法”这类机械式的观点,而且也不满意把软件优劣归结于“人是根本”的简单回答。我们需要探索一个既非机械式,也非简单地归结为某种理念的答案。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (22 人打了分,平均分: 4.73 )
Loading...
那些曾伴我走过编程之路的软件

那些曾伴我走过编程之路的软件

收家的时候发现了一张VC++6.0的光盘,实然引发了我的怀旧情结。于是在微博上感叹了一下,看到一些朋友的回应,还有朋友提到了Turbo C 2.0,于是更回放大了我的怀旧情绪,让我回想了很多N年前伴我走过编程之路的软件。现在看下来,有些感叹,又有些可笑。感叹的是技术发展的变迁,可笑的是当时的一些想法。(Unix/Linux是在大四和毕业的时候接触的,虽然这是我的强项,但是这下面的编程这么多年来没什么变化,所以就不提了)注:图片较多,请稍等。

还记得第一次接触编程是在高中的时候,用中华学习机学Basic程序,后来到了大学,虽然学校的课程没有教Basic语言,但是DOS下有一个叫Quick Baisc的东西让我把高中时的知识又捡了回了。

大学里学的第一门语言是Pascal,所以,用的编程软件也就是Turbo Pascal,还记编译起来巨快无比,尤其是那个只有软盘和640K的基本内存的时代。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (29 人打了分,平均分: 5.00 )
Loading...
一些文章和各种资源

一些文章和各种资源

下面是近期收录的一些文章和资源,希望对你有用。

系统方面

Mozilla's Gecko rendering engine main flow
Mozilla's Gecko rendering engine main flow
好烂啊有点差凑合看看还不错很精彩 (18 人打了分,平均分: 5.00 )
Loading...
给程序员的VIM速查卡

给程序员的VIM速查卡

前几天酷壳发布过“vim简明攻略”,不知道大家练得怎么样了。如果你练了一下,那么这里这个速查卡就会对你有帮助了。以前本站也有过一个(vim速查卡),不过其太简单了。我觉得这个很不错,很全,很直观。这个速查卡来自这里。其用颜色标注了级别:

  •   Green   = 存活级
  •   Yellow   = 感觉良好
  •   Orange   / Blue = 高级
  •   Red   = 专家级

下面的图片点击可以看大图:

给程序员的VIM速查卡
给程序员的VIM速查卡(点击看大图)

你还可以下载PDF版的和Excel版的,如果你是色盲的话,还有蓝色版PDF的。如果你不是很喜欢的话,这里还有几个:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (26 人打了分,平均分: 4.54 )
Loading...
千万不要把 bool 设计成函数参数

千万不要把 bool 设计成函数参数

我们有很多Coding Style 或 代码规范。但这一条可能会经常被我们所遗忘,就是我们经常会在函数的参数里使用bool参数,这会大大地降低代码的可读性。不信?我们先来看看下面的代码。

当你读到下面的代码,你会觉得这个代码是什么意思?

widget->repaint(false);

是不要repaint吗?还是别的什么意思?看了文档后,我们才知道这个参数是immediate, 也就是说,false代表不立即重画,true代码立即重画。

Windows API中也有这样一个函数:InvalidateRect,当你看到下面的代码,你会觉得是什么意思?

InvalidateRect(hwnd, lpRect,  false);

我们先不说InvalidateRect这个函数名取得有多糟糕,我们先说一下那个false参数?invalidate意为“让XXX无效”,false是什么意思?双重否定?是肯定的意思?如果你看到这样的代码,你会相当的费解的。于是,你要去看一下文档,或是InvalidateRect的函数定义,你会看到那个参数是 BOOL bErase,意思是,是否要重画背景。

这样的事情有很多,再看下面的代码,想把str中的”%USER%”替换成真实的用户名:

str.replace("%USER%", user, false);   // Qt 3

TNND,那个false是什么意思?不替换吗?还是别的什么意思,看了文档才知道,false代码大小写不敏感的替换。

其实,如果你使用枚举变量/常量,而不是bool变量,你会让你的代码更易读,如:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (27 人打了分,平均分: 4.30 )
Loading...
简明 Vim 练级攻略

简明 Vim 练级攻略

vim的学习曲线相当的大(参看各种文本编辑器的学习曲线),所以,如果你一开始看到的是一大堆VIM的命令分类,你一定会对这个编辑器失去兴趣的。下面的文章翻译自《Learn Vim Progressively》,我觉得这是给新手最好的VIM的升级教程了,没有列举所有的命令,只是列举了那些最有用的命令。非常不错。

——————————正文开始——————————

你想以最快的速度学习人类史上最好的文本编辑器VIM吗?你先得懂得如何在VIM幸存下来,然后一点一点地学习各种戏法。

Vim the Six Billion Dollar editor

Better, Stronger, Faster.

学习 vim 并且其会成为你最后一个使用的文本编辑器。没有比这个更好的文本编辑器了,非常地难学,但是却不可思议地好用。

我建议下面这四个步骤:

  1. 存活
  2. 感觉良好
  3. 觉得更好,更强,更快
  4. 使用VIM的超能力

当你走完这篇文章,你会成为一个vim的 superstar。

在开始学习以前,我需要给你一些警告:

  • 学习vim在开始时是痛苦的。
  • 需要时间
  • 需要不断地练习,就像你学习一个乐器一样。
  • 不要期望你能在3天内把vim练得比别的编辑器更有效率。
  • 事实上,你需要2周时间的苦练,而不是3天。
好烂啊有点差凑合看看还不错很精彩 (116 人打了分,平均分: 4.85 )
Loading...