One more struggle, and I am free
按：今天在网上看到阮一峰推荐的《Hype Driven Development》，忍俊不禁，联想到工作中的很多经历又百感交集。趁春节假期翻译出来（练练手），与大家共享。
软件开发团队所做的软件架构或技术栈的决策，很多并没有经过踏实的研究和对目标成果的认真思考，而是不准确的意见、社交媒体的信息，或者就些是“热闹”的玩意。我称这种作派为“热闹驱动开发（Hype Driven Development，HDD）”，眼见它的危害，我赞成更专业的做法，就是“脚踏实地的软件工程”。下面我们一起看看HDD的来龙去脉，想想能如何改进。
最近面试了很多技术人员，其中不少之前的工作履历还不错。但是，因为他们之前的创业经历，我并不能发offer。
看到这里先别着急下结论，让我仔细说说理由。
时常与一些同行朋友说起“软件难做”的话题，一方面软件确实挺难做，变数着实太多（推荐《梦断代码》），另一方面，让人理解软件难做，更是不容易的事情。如果说第一个问题靠苦练内功还能看到希望，第二个问题就近似无解而让人绝望了。下面两个场景，相信大家都不陌生：
头儿说：你们开发怎么这么慢？拿这么高的薪水，做事还这么慢？我急得不得了，只可惜我不懂开发。我如果懂，我去学校招50个码农，连续熬夜一两个礼拜，绝对可以做出我想要的系统。
头儿说：我真是对系统失望透顶了。想我以前刚创业的时候，七八个人，五六台电脑，什么事都是靠喊，那时候工作效率多高，人均产值多高？现在人才到几百个，就成了这个鬼样，说要上系统，上了系统有变好吗……
我有时候会想，这些说法在普通人看来似乎也没有错，但行业中人都知道错得厉害。那么，问题究竟出现在哪里呢？我想来想去，觉得原因大概在于，持这样说法的人往往只依靠来自生活经验的“逻辑”和“直觉”，还没有真正理解“软件”（或者说“系统”）到底是怎么一回事。
上个月，有个以前的同事问我：“你在的时候，为什么不把原来的系统都重做了，我们明明有实力啊”。
我说：“我们也做了很多事情嘛，系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。”
他说：“对，但我还是想知道，你为什么不把系统重做了呢？”
于是我问：“我离职之后，后来似乎多投了不少人重做系统？结果怎么样呢？”
他说：“结果，结果就是做业务要同时操作三四套系统……”
就我所见，把原有系统“推倒重来”的喜好不只程序员有，使用者更有。拿我几年前的那份工作来说，刚入职老大们就来跟我讨论系统重做的打算：需要多少人，多少钱，多长时间，能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛：速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出“敢叫日月换新天”的劲头，来个干脆的彻底解决。
这种心情可以理解，但在我任内“重做系统”一直没有被提上日程，整个技术团队所做的都是“改良”的工作，内容就像我上面说的：系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。这个选择我有充分把握，而且在我看来，如果断然“推倒重来”，我未必能比继任者做得更好，甚至可能更糟糕，因为“推倒重来”绝不是那么简单的事情。
我刚刚工作的时候，面试官曾经跟我说：好好干两年，可以迅速从程序员成长为工程师。当时我觉得太诧异了，从很多招聘启示来看，“程序员”不就等于“工程师”吗，只是“工程师”更好听一些而已。等我工作久了，才知道“程序员”和“工程师”真的是不一样的——程序员只写程序，工程师写能在现实世界中创造价值的程序。
可惜，很多软件开发人员未必清楚两者的差别，甚至做了很久也只算程序员而不算严格意义上的工程师。所以我就自己的观察和经验，谈谈程序员和工程师的差别。
在超市结帐的时候，收银员都会给我们打一张小票。有时候同样的商品我们会买两三件，打印在小票上面，有时候只有1行记录，数量是3（“听装百事可乐 x3”），但也有时候有3行记录，数量都是1（“听装百事可乐 x1” 重复3行）。这个现象很有意思，為什麼不统一呢？而且据我观察，后一种情况明显更多。分明是前一种做法更节省纸张，为什么更少采用呢？
我曾经设想，是因为收银的机器性能太差，内存很少，只能维护简单的数组结构，不能维护集合，也不能每添加一样商品就去重新扫描一次数组做修改。但是继续观察就会发现，这个说法站不住脚——现代的收银机性能足够很好了，甚至手机的性能都在突飞猛进。那么这么做的原因到底在哪里呢？就在我百思不得其解之际，一个偶然的机会解开了我的疑惑。
众所周知，日本车在全世界都是很受欢迎的。究其开端，很多人会想到20世纪70年代的石油危机，认为是油价高涨，为尺寸小、油耗低的日本车打开了市场。这固然可以解释一部分原因，但另一方面，为何日本车能够持续受到欢迎，为何日本车能摆脱“价廉质差”的形象，既有优惠的价格又有优异的品质（缺陷率常年很低）。这一切，都与日本汽车厂商所采用的“精益生产”，尤其是丰田开创的“丰田生产方式”（Toyota Product System, TPS）有很大的关联。最近因为与供应链打交道很多，我花了些时间学习这种生产方式。有趣的是，我发现，它的价值不只限于汽车行业，甚至不只限于制造业，对其它许多行业（包括软件行业）。所以下面我讲讲丰田生产方式给我的启示。
说起API，做开发的人大概都知道也用过，我也是如此。不过除去使用，我还亲眼目睹过API制定，参与搭建过开放API平台，也与合作方商量确定过API方案；算是各个方面都有了解和经历，感受过让人啧啧称奇的赞赏，也经历过举步维艰的尴尬。目睹还有很多同行在API的泥泞里挣扎，我把自己的经验写在这里与大家分享。
大家都知道，API是Application Program Interface，也就是应用程序接口，看起来非常容易理解，实际却并非如此。据我观察，不少API方案之所以陷入了泥潭，就是程序员对API理解错误，把它看成了“对外开放的函数”：某个动作可能之前需要用户鼠标点击触发，现在开个口子给程序用消息触发，这就是API了；推广开来，现在流行的API化、开放平台的潮流，无非是多开一些这样的口子而已。
几年前，我从温伯格的《技术领导之路》中学到一点：技术人员往往更喜欢和机器打交道，因为他们“认为”自己更适合和机器打交道；但是，优秀的技术人员必须（也必然）具备好的沟通能力。所以，温伯格鼓励各位技术人员多加练习和其他人打交道的能力。温伯格的这个观点我是非常赞成的，好的技术人员一定需要“勇敢”面对他人，不能被“自实现的预言”局限在机器的世界里。
不过我也发现，“技术人员（当然我主要说的是软件开发人员）不适合跟人打交道”的负面影响不止于此，它还成了一种刻板印象（stereotype），进而影响到开发团队之外的人。这个问题其实很严重，它会导致其他人和开发人员沟通时自觉或者不自觉地切换到“和机器沟通”的模式上来，比如单纯依赖邮件而避免见面沟通，比如“你只管这么做出来就好了，别管我用来干什么”。以面向机器的模式来与人沟通，结果往往是完整的项目（而不是狭义的“软件项目”）割裂开来，皆不欢喜。
“面向接口编程”是程序设计的规则之一，它可以将具体实现封装为具有一定逻辑意义的抽象行为。这样做的好处多多，比如有利于在较高层次上思考，而不必操心细节；比如避免外部代码因为具体实现变化而作修改。广大开发人员，不管自己设计程序时有没有注意“面向接口编程”，都会或多或少地从“面向接口编程”中获益——我上大学时曾听某师兄说：“编程还不容易，从网络上找一些类库来调用就好了”。接口隐藏了背后的实现，可是，许多开发人员不但写程序止步于接口，思维同样止步于接口。接口背后是什么，他们写的程序不关心，他们自己也不关心，而且振振有词“我这是面向接口编程”。但是，这真的是好事吗？
我刚工作时，所做的项目里有几个问题是自己搞不定的，甚至整个项目组也没有人能搞定。好在项目经理很有办法，找了他之前的同事兼职帮忙，写出最难的模块，我们只管调用现成接口就可以了。当时大家都松了一口气，至少不会因为自己水平不够，耽误项目进展了，内心也非常感激这位兼职的高人。可是，随着项目的进展，我们搞不定的问题越来越多，于是越来越依赖兼职的帮忙，整个项目也因此越来越被动。我仔细观察，发现这类搞不定的问题虽然反复出现，归结起来只集中在某几个领域，而每次这位兼职高人给过来的程序，尺寸变化并不大。所以我认定，这些问题并没有太多难度，只要解决其中一个，应该就可以举一反三，顺势全部解决。于是我花了一周的业余时间，逐行细抠接口之后的代码，终于尝试独立解决了一个这类问题，给项目经理看过，他非常高兴，从此甚至对我有些另眼相待。当时我想，他这么高兴，是因为我为公司省了钱，再也不必烦劳以前的同事兼职了罢。