Browsed by
分类:技术管理

什么是工程师文化?

什么是工程师文化?

engineer 四年前,我在QCon上演讲了一个《建一支强大的小团队》(整理后的PPT分享于这里)提到了工程师文化,今天,我想在这里再写一篇关于工程师文化的文章,一方面是因为我又有了一些想法和体会,另一方面,因为我也正走在创业的道路,毫无疑问,要建一个有浓重的工程师文化的团队或公司,所以有必要把自己的相关想法形有成白底黑字的“字据”,以供打自己的脸——“要是未来没有做到,这篇文章就打我未来的脸” || “这篇文章太幼稚了,未来的我会打我现在的脸”,当然,如果要打脸,我希望是前者。

Again,这篇文章不是招人的贴子,因为我觉得,招聘第一重要的事,不是发招聘广告或是找猎头挖人,而是先得让自己变成一个能配得上真正工程师的公司,然后再谈吸引人的事

为什么要工程师文化

看看最近二十年来社会的发展,计算机和互联网已经渗透到了这个社会的每一个角落,各式各样的计算机技术成为了整个世界发展的强大引擎,各式各样的创新,无论是业务创新还是技术创新,都是依托于技术的快速演进,技术成了解放生产力提高社会运作的效率的中坚力量。以美帝为首的技术创新公司着着实实的改变着这个世界和人类的生活和生产习惯。

今天,每个从事计算机行业的技术人员都应该感到幸运,因为,我们不但选对了行业,也出生在了正确的时代,可以感受到前所未有的刺激和变化,相比起我们的父辈,我们的人生,能经历这样的时代,实在是一种幸运。所以,选对了职业并出生在了正确的年代的我们,此时只需要思考的一个问题,那就是,我是否呆在了正确的地方用正确的方式做事?

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (49 人打了分,平均分: 4.69 )
Loading...
关于高可用的系统

关于高可用的系统

HighAvailability-BK在《这多年来我一直在钻研的技术》这篇文章中,我讲述了一下,我这么多年来一直在关注的技术领域,其中我多次提到了工业级的软件,我还以为有很多人会问我怎么定义工业级?以及一个高可用性的软件系统应该要怎么干出来?这样我也可以顺理成章的写下这篇文章,但是没有人问,那么,我只好厚颜无耻的自己写下这篇文章了。哈哈。

另外,我在一些讨论高可用系统的地方看到大家只讨论各个公司的技术方案,其实,高可用的系统并不简单的是技术方案,一个高可用的系统其实还包括很多别的东西,所以,我觉得大家对高可用的系统了解的还不全面,为了让大家的认识更全面,所以,我写下这篇文章

理解高可用系统

首先,我们需要理解什么是高可用,英文叫High Availability(Wikipedia词条),基本上来说,就是要让我们的计算环境(包括软硬件)做到full-time的可用性。在设计上一般来说,需要做好如下的设计:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (34 人打了分,平均分: 4.94 )
Loading...
让我们来谈谈分工

让我们来谈谈分工

Division of Labour昨天,我看到一个新闻——雅虎取消了QA团队,工程师必须自己负责代码质量,并使用持续集成代替QA。 同时,也听到网友说,“听微软做数据库运维的工程师介绍,他们也是把运维工程师和测试工程师取消了,由开发全部完成。每个人都是全栈工程师”。于是,我顺势引用了几年前写过一篇文章《我们需要专职的QA吗?》,并且又鼓吹了一下全栈。当然,一如既往的得到了一些的争议和嘲弄;-)。

有人认为取消QA基本上是公司没钱的象征,这个观点根本不值一驳,属于井底之蛙。有人认为,社会分工是大前提,并批评我说怎么不说把所有的事全干的,把我推向了另外一个极端。另外,你千万不要以为有了分工,QA的工作就保得住了。

就像《乔布斯传》中乔布斯质疑财务制度的时候说的,有时候,很多人都不问为什么,觉得存在的东西都是理所应当的东西。让我们失去了独立思考的机会。分工也是一样。

所以,为了说完整分工这个逻辑。请大家耐住性子,让我就先来谈谈“分工的优缺点”吧。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (89 人打了分,平均分: 4.54 )
Loading...
开发团队的效率

开发团队的效率

我之前写过一篇叫《加班与效率》的文章,从概念上说了一些我对“效率”的认识,但是那篇文章趋于概念化,对于一些没有经历过这样的环境的同学来说,可能会觉得太抽象了。很早以前就想写一篇更具体一点的,可执行的文章与《加班与效率》这篇文章相辉映,并再把我两年前在杭州QCon上的那个鼓吹工程师文化”的《建一支强大的小团队》(新浪微盘)的观点再加强一下。

但是我遇到了一些思维方式上的麻烦——我讲的总是从我的经历背景出发,没有从其它人的经历背景来讲。这就好像,我在酷壳里说了很多东西(比如:专职的QACode Review很重要编程年龄创业的Rework的……),有好些人觉得是不可能甚至太理想,其实我说的那些东西都是实实在在存在的,也是我所经历过的。于是,不同的经历,不同的环境,不同的眼界,造成了——有些人不理解我说的,而我也不能理解他们所说的。

所以,过去的这段时间我一有机会就找一些人交流并观察一些身边的事情,并去试着跟从和理解那些我不能理解的东西。现在觉得差不多了,所以,写下了这篇文章。(但越是去理解对方,我就越坚持我的观点,所以这篇文章可能还是会出现鸡同鸭讲的情形,无所谓了)

本文不讨论任何业务上的效率问题,只讨论软件开发或是软件工程中的效率问题。虽然产品和业务上的效率问题是根本,但是因为本文不是拉仇恨的,我也不想混在一起谈,所以请原谅我在这里先说开发团队的,以后重新开篇文章专门谈产品和业务的。

我下面会罗列几个非常典型的开发方式——软件开发中的“锁”接力棒式软件开发保姆式软件开发WatchDog软件开发故障驱动式软件开发

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (95 人打了分,平均分: 4.79 )
Loading...
从Code Review 谈如何做技术

从Code Review 谈如何做技术

(这篇文章缘由我的微博,我想多说一些,有些杂乱,想到哪写到哪)

这两天,在微博上表达了一下Code Review的重要性。因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录。当然,这并不能说没有记录他们就没有做Code Review,于是,我就问了一下以前在业务团队做过的同事有没有Code Review,他告诉我不但没有Code Review,而且他认为Code Review没用,因为:

1)工期压得太紧,时间连coding都不够,以上线为目的,

2)需求老变,代码的生命周期太短。所以,写好的代码没有任何意义,烂就烂吧,反正与绩效无关。

我心里非常不认同这样的观点,我觉得我是程序员,我是工程师,就像医生一样,不是把病人医好就好了,还要对病人的长期健康负责。对于常见病,要很快地医好病人很简单,下猛药,大量使用抗生素,好得飞快。但大家都知道,这明显是“饮鸩止渴”、“竭泽而渔”的做法。医生需要有责任心和医德,我也觉得程序员工程师也要有相应的责任心和相应的修养。东西交给我我必需要负责,我觉得这种负责和修养不是”做出来“就了事了,而是要到“做漂亮”这个级别,这就是“山寨”和“工业”的差别。而只以“做出来”为目的标准,我只能以为,这样的做法只不过是“按部就班”的堆砌代码罢了,和劳动密集型的“装配生产线”和“砌砖头”没有什么差别,在这种环境里呆着还不如离开。

老实说,因为去年我在业务团队的时候,我的团队也没有做Code Review,原因是多样的。其中一个重要原因是,我刚来阿里,所以,需要做的是在适应阿里的文化,任何公司都有自己的风格和特点,任何公司的做法都有他的理由和成因,对于我这样的一个初来者,首要的是要适应和观察,不要对团队做太多的改动,跟从、理解和信任是融入的关键。(注:在建北京团队和不要专职的测试人员上我都受到了一些阻力),所以跟着团队走没有玩Code Review。干了一年后,觉得我妥协了很多我以前所坚持的东西,觉得自己的标准在降低,想一想后背拔凉拔凉的,所以我决定坚持,而且还要坚持高标准。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (124 人打了分,平均分: 4.85 )
Loading...
加班与效率

加班与效率

微博上看到了这么一个贴子,就像以前在《腾讯,竞争力 和 用户体验》中批评过腾讯说自己的核心竞争力是员工加班一样,我顺着Winter的回复也批评了一下这个微博——

靠加班超越对手?!劳动密集型么?我要是对手的话,我就来趁机挖人了,直接摁死你……//@寒冬winter: 当一个管理者的智慧无法衡量一支团队的产出的时候,他就会把“工时”当做最后的救命稻草,死死抱住——这是他唯一听得懂的东西了。”

然后,@玄了个澄的在微博里at我说,他在微信里看了@Fenng 关于加班的言论,希望我评论一下。我看了一下大辉的文章,虽然写得有点散乱,但是我和他的一些观点还是很类似的,我主要在这里加强一下我的看法。

关于加班

认为加班是公司的核心竞争力,或是超越对手的手段,是一种相当 Ridiculous 的想法。这说明管理者们已经想不到自己公司的核心价值了

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (71 人打了分,平均分: 4.85 )
Loading...
Alan Cox:大教堂、市集与市议会

Alan Cox:大教堂、市集与市议会

(感谢网友 @我的上铺叫路遥 投稿)

在网上搜到的Cox大叔于1998年在开源社区写的一篇文章,当时很轰动,明眼人一看就知道是针对ESR那篇《大教堂与市集》,从中可见Alan在项目管理风格上乃至个人性格上都与ESR、Linus等人不同之处。顺便说一句,Alan现在出于“家庭原因”已经离开了Linux项目,他曾经评价Linus是a good developer but a terrible engineer,甚至在Google+上直接说Linus就是一a*sh**e。不管如何,两位曾经十余年里并肩战斗惺惺相惜的大牛就此分道扬镳还是惹人唏嘘。

言归正传,以下为slashdot收录的英文原文:Cathedrals, Bazaars and the Town Council

以下是一些我对市集模式的想法,我认为这值得分享,这种模式会教你如何完全毁掉一个自由软件项目。我还举了一个我称之为“市议会”(Town Council)效应的实例(虽然那些市议员们可不这么认为,注:此处指Linux项目开发者)。

关于软件开发人员,你必须去了解一些情况。首先要了解的是真正优秀的程序员相对来说并不普遍,不仅如此,在很多其它专业领域里“真正的程序员”和一些捣乱的家伙之间的区别要比“伟大”和“普通”之间的区别要大得多,研究表明生产效率上最好的同其余的比重是30:1。

其次,你需要了解的是一大堆妄想型码农(wannabe programmer)总是善于发表意见。其中很多人患上了一种叫做“流行性热词”(buzzword)疾病,或者对他们“非黑即白”(one true path)的思考方式有着特殊的偏执,网上很多讨论都是廉价的。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (16 人打了分,平均分: 4.44 )
Loading...
IoC/DIP其实是一种管理思想

IoC/DIP其实是一种管理思想

关于IoC的的概念提出来已经很多年了,其被用于一种面象对像的设计。我在这里再简单的回顾一下这个概念。我先谈技术,再说管理。

话说,我们有一个开关要控制一个灯的开和关这两个动作,最常见也是最没有技术含量的实现会是这个样子:

然后,有一天,我们发现需要对灯泡扩展一下,于是我们做了个抽象类:

但是,如果有一天,我们发现这个开关可能还要控制别的不单单是灯泡的东西,我们就发现这个开关耦合了灯泡这种类别,非常不利于我们的扩展,于是反转控制出现了。

就像现实世界一样,造开关的工厂根本不关心要控制的东西是什么,它只做一个开关应该做好的事,就是把电接通,把电断开(不管是手动的,还是声控的,还是光控,还是遥控的),而我们的造各种各样的灯泡(不管是日关灯,白炽灯)的工厂也不关心你用什么样的开关,反正我只管把灯的电源接口给做出来,然后,开关厂和电灯厂依赖于一个标准的通电和断电的接口。于是产生了IoC控制反转,如下图:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (22 人打了分,平均分: 4.59 )
Loading...
《Rework》摘录及感想

《Rework》摘录及感想

读了《Rework》这本书好多遍,每次读都有不同的感想。但从来没有把这些感想记录下来,今天把《Rework》书中的一些章节做一些摘录,并把我的一些感想总结出来。供大家参考。这是一本平生以来让我中毒很深的书,也是一本让我思考得很多的书。希望看到这篇文章的人都能好好地读读这本书。这本书并不难读,是一本你可以一口气不中断就可以读完的书。

现实世界

“这在现实世界里面行不通”,当你向人们介绍一个新创意时,人们总是这么回答你。这个“现实世界”听起来如此令人沮丧,……只有人耳熟能详,习以为常的事情才会胜利,即使是这些事情已经漏洞百出陈腐低效。

揭开“现实世界”这个锅盖,你会发现居住在里的人都充斥着悲观主义和失望的情绪。更糟的是,他们想将别人拖进他们的坟墓。如果你是充满希望和野心的人,他们会试着说服你,你的想法是不可能的。他们会说你在浪费时间。

“现实世界”并不存在,那只是人的一个借口。只是某些人为了开脱 自己的无所作为,跟你一点关系也没有。

感想:我经常会向一同事和朋友提及一些我的想法,朋友同事们经常会回答我——这个事某某人,某某团队做过了,没成功。或是对我说,你做这个事的时候,要小心这个要小心那个。我觉得,这个时候是最考验我们的时候了,要有一个清醒的头脑去分析别人的话,别人真不代表自己。这个世界上大多数人都是比较保守的,大多数都对这个现实世界都有或多或少的恐惧感。当然,你可以选择做大众,但是如果你想让你的人生有些不同,有些精彩,我还是建议你不要和大多数人想得一样,如果你和大多数人的想法一样,你必然会和大多数人一样的平庸。当然,如果你和大多数人不一样,你要么就是天才,要么就是傻瓜。要证明你自己是不是傻瓜,我们可以看看我们过去有没有过一些小成功或小成绩。如果有,那么就应该大胆地坚持自己的想法。

被高估的“从错误中学习”

你真的从错误和失败里面学到什么了吗?你也许学到了别再重蹈覆辙,但是这有什么意义吗?你仍然不知道接下来该做什么。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (79 人打了分,平均分: 4.71 )
Loading...
持续部署,并不简单!

持续部署,并不简单!

感谢 @常新居士 投递此文 】

这几年,持续集成随着敏捷在国内的推广而持续走热,与之相伴的持续部署也一直备受关注。自前两年,持续交付这个延续性概念又闯进了国内IT圈,慢慢开始在社区和会议中展露头角。许多不明真相的群众跟风哭着喊着要“上”,而许多前CI的半吊子玩家换件衣服就接着干,有的甚至衣服都来不及换……。国内的这些土财主如果不巧请了某些所谓的战略家,除了建了一堆持续集成环境,以及每天嚷嚷着要这个要那个,混乱的状况在根本上没有得到改善。本文无意费力探讨持续集成和持续交付的概念,而是打算谈谈对于大型软件企业,以持续集成为基础实现持续部署(交付)时,所要面对的问题以及可行的解决方案。地主老财们,夜黑风正猛,山高路又远,注意脚下……

And God Said, Let there be light: and there wa— GENSIS, Charpter 1, King James

一、起步

先来讲个故事……

几年前,一对留美的夫妇通过朋友找到我,让我帮忙在国内组建一个开发团队,该团队负责为其开发一款基于社交网络的客户关系管理软件,(暂且称之为项目A)。这个项目除了尚不清晰的需求范围和很紧的期限外,作为业内人士的老公Richard根据眼下流行的软件开发过程还提了诸多额外的要求:

  • 功能要及早交付(以便拿去和潜在的投资人洽谈)
  • 功能在部署到生产环境前要先部署的一个测试环境(Richard要试用后给予反馈)
  • 功能必须经过测试(长期作为软件外包的甲方,对质量要求严格)
  • 要减少后期维护的工作(美国人精贵,少雇一个是一个)
  • 支持协同开发(以便维护人员及早介入)
  • ……

这正是持续集成所要解决的典型场景。针对Richard的要求,我们只要建立一个基于Hudson(现在叫Jenkins)+Maven +SVN 的持续集成环境(再加上持续集成所要求的测试和过程)就可以很好地满足上述要要求,此方案的结构如下:

阅读全文 Read More

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