按:今天在网上看到阮一峰推荐的《Hype Driven Development》,忍俊不禁,联想到工作中的很多经历又百感交集。趁春节假期翻译出来(练练手),与大家共享。


软件开发团队所做的软件架构或技术栈的决策,很多并没有经过踏实的研究和对目标成果的认真思考,而是不准确的意见、社交媒体的信息,或者就些是“热闹”的玩意。我称这种作派为“热闹驱动开发(Hype Driven Development,HDD)”,眼见它的危害,我赞成更专业的做法,就是“脚踏实地的软件工程”。下面我们一起看看HDD的来龙去脉,想想能如何改进。

(more…)

最近面试了很多技术人员,其中不少之前的工作履历还不错。但是,因为他们之前的创业经历,我并不能发offer。

看到这里先别着急下结论,让我仔细说说理由。

(more…)

时常与一些同行朋友说起“软件难做”的话题,一方面软件确实挺难做,变数着实太多(推荐《梦断代码》),另一方面,让人理解软件难做,更是不容易的事情。如果说第一个问题靠苦练内功还能看到希望,第二个问题就近似无解而让人绝望了。下面两个场景,相信大家都不陌生:

头儿说:你们开发怎么这么慢?拿这么高的薪水,做事还这么慢?我急得不得了,只可惜我不懂开发。我如果懂,我去学校招50个码农,连续熬夜一两个礼拜,绝对可以做出我想要的系统。

头儿说:我真是对系统失望透顶了。想我以前刚创业的时候,七八个人,五六台电脑,什么事都是靠喊,那时候工作效率多高,人均产值多高?现在人才到几百个,就成了这个鬼样,说要上系统,上了系统有变好吗……

我有时候会想,这些说法在普通人看来似乎也没有错,但行业中人都知道错得厉害。那么,问题究竟出现在哪里呢?我想来想去,觉得原因大概在于,持这样说法的人往往只依靠来自生活经验的“逻辑”和“直觉”,还没有真正理解“软件”(或者说“系统”)到底是怎么一回事。

(more…)

上个月,有个以前的同事问我:“你在的时候,为什么不把原来的系统都重做了,我们明明有实力啊”。

我说:“我们也做了很多事情嘛,系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。”

他说:“对,但我还是想知道,你为什么不把系统重做了呢?”

于是我问:“我离职之后,后来似乎多投了不少人重做系统?结果怎么样呢?”

他说:“结果,结果就是做业务要同时操作三四套系统……”

就我所见,把原有系统“推倒重来”的喜好不只程序员有,使用者更有。拿我几年前的那份工作来说,刚入职老大们就来跟我讨论系统重做的打算:需要多少人,多少钱,多长时间,能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛:速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出“敢叫日月换新天”的劲头,来个干脆的彻底解决。

这种心情可以理解,但在我任内“重做系统”一直没有被提上日程,整个技术团队所做的都是“改良”的工作,内容就像我上面说的:系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。这个选择我有充分把握,而且在我看来,如果断然“推倒重来”,我未必能比继任者做得更好,甚至可能更糟糕,因为“推倒重来”绝不是那么简单的事情。

(more…)

我刚刚工作的时候,面试官曾经跟我说:好好干两年,可以迅速从程序员成长为工程师。当时我觉得太诧异了,从很多招聘启示来看,“程序员”不就等于“工程师”吗,只是“工程师”更好听一些而已。等我工作久了,才知道“程序员”和“工程师”真的是不一样的——程序员只写程序,工程师写能在现实世界中创造价值的程序。

可惜,很多软件开发人员未必清楚两者的差别,甚至做了很久也只算程序员而不算严格意义上的工程师。所以我就自己的观察和经验,谈谈程序员和工程师的差别。

(more…)

在超市结帐的时候,收银员都会给我们打一张小票。有时候同样的商品我们会买两三件,打印在小票上面,有时候只有1行记录,数量是3(“听装百事可乐 x3”),但也有时候有3行记录,数量都是1(“听装百事可乐 x1” 重复3行)。这个现象很有意思,為什麼不统一呢?而且据我观察,后一种情况明显更多。分明是前一种做法更节省纸张,为什么更少采用呢?

我曾经设想,是因为收银的机器性能太差,内存很少,只能维护简单的数组结构,不能维护集合,也不能每添加一样商品就去重新扫描一次数组做修改。但是继续观察就会发现,这个说法站不住脚——现代的收银机性能足够很好了,甚至手机的性能都在突飞猛进。那么这么做的原因到底在哪里呢?就在我百思不得其解之际,一个偶然的机会解开了我的疑惑。

(more…)

众所周知,日本车在全世界都是很受欢迎的。究其开端,很多人会想到20世纪70年代的石油危机,认为是油价高涨,为尺寸小、油耗低的日本车打开了市场。这固然可以解释一部分原因,但另一方面,为何日本车能够持续受到欢迎,为何日本车能摆脱“价廉质差”的形象,既有优惠的价格又有优异的品质(缺陷率常年很低)。这一切,都与日本汽车厂商所采用的“精益生产”,尤其是丰田开创的“丰田生产方式”(Toyota Product System, TPS)有很大的关联。最近因为与供应链打交道很多,我花了些时间学习这种生产方式。有趣的是,我发现,它的价值不只限于汽车行业,甚至不只限于制造业,对其它许多行业(包括软件行业)。所以下面我讲讲丰田生产方式给我的启示。

(more…)

说起API,做开发的人大概都知道也用过,我也是如此。不过除去使用,我还亲眼目睹过API制定,参与搭建过开放API平台,也与合作方商量确定过API方案;算是各个方面都有了解和经历,感受过让人啧啧称奇的赞赏,也经历过举步维艰的尴尬。目睹还有很多同行在API的泥泞里挣扎,我把自己的经验写在这里与大家分享。

大家都知道,API是Application Program Interface,也就是应用程序接口,看起来非常容易理解,实际却并非如此。据我观察,不少API方案之所以陷入了泥潭,就是程序员对API理解错误,把它看成了“对外开放的函数”:某个动作可能之前需要用户鼠标点击触发,现在开个口子给程序用消息触发,这就是API了;推广开来,现在流行的API化、开放平台的潮流,无非是多开一些这样的口子而已。

(more…)

几年前,我从温伯格的《技术领导之路》中学到一点:技术人员往往更喜欢和机器打交道,因为他们“认为”自己更适合和机器打交道;但是,优秀的技术人员必须(也必然)具备好的沟通能力。所以,温伯格鼓励各位技术人员多加练习和其他人打交道的能力。温伯格的这个观点我是非常赞成的,好的技术人员一定需要“勇敢”面对他人,不能被“自实现的预言”局限在机器的世界里。

不过我也发现,“技术人员(当然我主要说的是软件开发人员)不适合跟人打交道”的负面影响不止于此,它还成了一种刻板印象(stereotype),进而影响到开发团队之外的人。这个问题其实很严重,它会导致其他人和开发人员沟通时自觉或者不自觉地切换到“和机器沟通”的模式上来,比如单纯依赖邮件而避免见面沟通,比如“你只管这么做出来就好了,别管我用来干什么”。以面向机器的模式来与人沟通,结果往往是完整的项目(而不是狭义的“软件项目”)割裂开来,皆不欢喜。

(more…)

“面向接口编程”是程序设计的规则之一,它可以将具体实现封装为具有一定逻辑意义的抽象行为。这样做的好处多多,比如有利于在较高层次上思考,而不必操心细节;比如避免外部代码因为具体实现变化而作修改。广大开发人员,不管自己设计程序时有没有注意“面向接口编程”,都会或多或少地从“面向接口编程”中获益——我上大学时曾听某师兄说:“编程还不容易,从网络上找一些类库来调用就好了”。接口隐藏了背后的实现,可是,许多开发人员不但写程序止步于接口,思维同样止步于接口。接口背后是什么,他们写的程序不关心,他们自己也不关心,而且振振有词“我这是面向接口编程”。但是,这真的是好事吗?

我刚工作时,所做的项目里有几个问题是自己搞不定的,甚至整个项目组也没有人能搞定。好在项目经理很有办法,找了他之前的同事兼职帮忙,写出最难的模块,我们只管调用现成接口就可以了。当时大家都松了一口气,至少不会因为自己水平不够,耽误项目进展了,内心也非常感激这位兼职的高人。可是,随着项目的进展,我们搞不定的问题越来越多,于是越来越依赖兼职的帮忙,整个项目也因此越来越被动。我仔细观察,发现这类搞不定的问题虽然反复出现,归结起来只集中在某几个领域,而每次这位兼职高人给过来的程序,尺寸变化并不大。所以我认定,这些问题并没有太多难度,只要解决其中一个,应该就可以举一反三,顺势全部解决。于是我花了一周的业余时间,逐行细抠接口之后的代码,终于尝试独立解决了一个这类问题,给项目经理看过,他非常高兴,从此甚至对我有些另眼相待。当时我想,他这么高兴,是因为我为公司省了钱,再也不必烦劳以前的同事兼职了罢。

(more…)

Next Page »