《JeolOnSoftware》

joel on software大家应该比较熟悉了：

http://www.joelonsoftware.com/index.html

关于jeol，可以看下他的背景，耶鲁大学，91年进入微软，在excel组作为programmer manager，而且是在一线编程的，后来又经历的一些公司，最后单干，他们的trello.com非常棒，几个同事和我在用。

简而言之，这哥们很hardcore，说的很多东西很不错。

我读的这个纸版的书《jeolOnSoftware》（http://book.douban.com/subject/1426838/）其实比较早了，中文翻译版是05年出的。

这个书里的确有含金量高的地方，但是也有很多地方比较基础，笔记加一些个人评论：

14 不要被太空架构师吓到

jeol描述了这样一群人，他们喜欢做很多抽象，以至于脱离了现实，作为理论很好，但是对于现实却没有意义，jeol称之为太空架构师。

他们倾向于在大公司里面任职，只有这样的公司才能供养这样的身份巨高，却对基本业务没什么贡献的人，喜欢为了创新而创新，喜欢搞革命，弄个大体系。。。。

这些东西的确是牛的，但需要踏踏实实的积累和卓越的能力。

这篇文章里，jeol更多的是吐槽，的确是，这样的人本身常常在公司里面浪费公司的资源（高薪+引来的抱怨），如果跳出来指导项目开发，很可能把一个团队的青春年华毁掉，远离这些不脚踏实地的人吧。

吐槽之外，也不能一概而论的说抽象和革命性的东西都是不好的，毕竟我们还是时不时看见有革命性的东西发生，但是个人觉得一个是要尊重客观事实和规律，脚踏实地，不要强求，更不要忽悠，做一个真正让人尊敬的开发者。

15 fire and motion

这是一个军事广泛运用的基本策略，就是向敌人开火，敌人肯定要低头，然后你可以趁着这个机会（在敌人不知道的情况下）抢占更有利的地方，但是你一定要移动，否则敌人知道你的地方，在你换弹夹的时候，就会反击你。

这的确是一个很好的策略，在软件竞争中常常用到，大公司会做这样的火力覆盖：你不用买我的产品，从更便宜的小公司买也可以，但是务必要保证支持xml/soap/j2ee否则你可要挂。于是小公司在谈的时候就不得不调整自己的开发，支持本来不需要的这些特性，这样自己的成本和速度的优势就被削弱，而大公司则继续前进。

或者大公司迫使你来跟随，然后它自己来向有利的地方前进。

yeah, fire and motion.

18 二元文化

这个概括我很喜欢：unix是想让程序员爽的系统，windows是想让人民群众爽的系统。

因此两个系统有着很大的不同，应用场所也很不同。

反言之，你如果想做一个卖给大众的东西，你就不能不顾大众的需求，按着自己觉得酷的方式来做。

21 激励

原来的题目是“重金奖励害多利少”，我不是很认同，但是里面说的内容还是很有同感的。

讲的是微软excel团队的愣头青hr认为这些行业内最顶级的人才仅仅需要钱就可以驱动，他们设定各种奖项，然后向调戏幼儿园小孩（我觉得也很像耍猴）一样去设立一个奖项，期望这些开发者能够玩命，谁做的好就给谁。

微软和jeol需要的人才肯定是vision驱动的，就像《魔鬼代言人》里面撒旦和罗麦斯首先谈的是要干什么（统治世界xxx），然后大家达成共识了，没什么好谈了，罗麦斯才开玩笑的说我们谈谈money吧，撒旦哈哈一笑，说“that's the easy part”，这才是吸引顶级人才的方式。

对顶级人才用耍猴的策略，这样那样的原因，总是找一些不懂开发者的人来“激励”开发者，而且这些manager们非常难有

22 不配备测试人员的5个原因

这个部分后面工作中还真有遇到对测试的重要性认识很外行的情况，不过这个也不是很大的问题，知道就好了，而且没有发现这一点也不意外，尤其是在google宣称程序员自己测试巨牛无比之后。

首先这是一个在实际生产中的客观事实：

在微软（我上一家游戏公司也如此）有着非常大规模很正规的测试团队，以至于所有的问题都会被抓出来，然后干掉。

我在上一家公司惊奇的发现，最后游戏发售的时候如此的稳定，没有bug，根本就不是程序员写的那么完美，几乎可以说就是测试团队的功劳，庞大的测试团队几乎和开发团队一样大，从项目早期就开始有，一天天不间断的测试，然后通过正规的bug数据库，反馈给开发组，开发组再作为task分配给各个人。

测试团队如同定海神针一样，作为开发团队的后盾存在，记得一次我做了一个巨大的改动，一次提交了狂加班一个月的很具颠覆性的改动，心里颇为不安（尽管我一再检查了代码，确认都ok，但是规模太大了，有过一定开发经验的人都会知道，这里几乎就一定会有问题，不太可能一次性通过），然后测试团队针对这样的改动，分配了较多的人，连续测了几天，都ok，然后我就可以把心放下，回家睡个安稳觉了----定海神针。

测试团队至关重要基于这样的事实：

• 地球上不存在写程序没bug的程序员，而且一般我们所在的公司里面充满了水平很一般的程序员，测试团队是必须要有的，当然这个测试团队可以是程序员自己，也可以是一个专门的测试团队，但是必须要有。
• 测试并不是一个巨简单的工作，好的测试人员的抓错能力和差的相差很大，软件越是复杂，这个越是大，作为最复杂的软件之一：游戏，程序员的测试能力只能用很差来形容，简言之，程序员自己的测试能力是不够的。
• 客观地说，程序的人力成本毕竟是要高于测试人员的，出于成本的考虑，也需要有专门的测试团队。
• 实际上，比较好的公司会做很多这样的成本计算和控制，比如给程序员最好的机器配置，办公室搬家的时候有专门的人来搬

所以逻辑很清楚了，必须要有测试，而且有专门的测试团队是性价比最高的。

另外一个公司里面容易犯的错误就是测试人员的职业发展问题，如果测试人员只能止步于测试，那么可以想象，肯定是“流水的兵”这样的情况，而我们需要的是有资深的测试带着一个团队的测试来工作，那么给测试人员有其他的发展空间是很必要的（比如转成designer等等）

23 任务切换的代价

原标题是”任务换人有害无益“。

jeol谈到同时做多个任务的代价要高于一个个做，这个论点在有一年的gdc上也有一个producer说过，因为我们的大脑就是这么设计的：单任务执行能力强，多任务执行能力差。

尽管有人有着很好的多任务处理能力，但是对于绝大多数来说，同样的能力下，一个个任务完成是最高效的。

至于任务换人。。。那是最低效的事情之一了，除非必须如此，否则最好不要这样。这里的飞机就多多了，说到这里，我觉得程序员最强者的一个重要元素就是能淡泊程序员典型的自我欲望，比如说在另外一个人接手的时候，会有一个倾向就是，如果按照前人的做法，就显不出我牛了，然后潜意识里就要自己搞一套，在这样的潜意识下，所以符合这个方向的东西就会被夸大，给项目组x个理由要重搞，或者自己直接重搞。

在《浪潮之巅》里面讲到盖茨对dos的支持，可以说是能够超越程序员自我欲望的一个典型，不是很理想化的直接抛弃一个落后的东西，而是更加理智的去采取最合适的策略。

另外一个切肤之痛就是我现在经历的引擎和游戏一同开发，美术团队等待引擎工具的功能来产出，项目自己也有milestone的压力，那么很多feature都是做到一个80分即提交，然后转向下一个，有问题和改进的需要再回头做。

这个是在”引擎和游戏需要一同开发“的大前提下的最优策略，但是相比引擎先行1年这样的情况就有质的不同，这种情况下，完全可以更加深远的设计，更加少的任务切换，和专注的实现。

24 重写代码

原标题是”绝不去做的事情，第一部“

里面写了网景公司花了3年时间，重写了他们认为很烂的代码，结果导致错过了大好的竞争机会，市场占有率直线下降（从%90到%4）。

嗯，对于这种案例我觉得也没有太大意思，这么多年来，你可以找到通过重写把自己弄死的，也可以找到重写进而脱胎换骨的，这不是一个简单的一概而论的”应该还是不应该“的问题。

比如我邮件的签名档就是carmack给abrash作序的一句话：

“Much heroic programming ensued. Several hundred thousand lines of code were written. And rewritten. And rewritten. And rewritten”.

在做网景这样的公司战略级重写决定权衡的时候，起码要有商业产品端的大局观和技术方面的纵深思考两方面的权衡，还是那句话，程序员需要超越自己作为程序员来思考问题才会得到一个正确的结果。

那么为什么程序员爱重写呢，jeol提的两点我很赞同：

• 程序员有一种做完美建筑师的倾向，其实这个倾向是程序员技术快速持续提升的重要价值观，在作为纯粹技术来说，非常好的一个特点，但是实际做产品的时候，就需要产品端的视野来平衡
• 阅读代码比写代码要困难的多，尤其是经过产品化的代码，常常会很是”很丑陋“以至于阅读和搞懂这样的代码非常的痛苦，重写则爽多了

重写为什么危险呢？

• 丑陋的代码或许是必须如此
• 它就是有那么多奇怪诡异的情况要处理，也就是你再写一遍也差不多，同时你浪费了那么多时间
• 那些诡异情况，常常是在一开始写的时候想不到的，然后实际测试或者上市的时候才发现的，然后才添加了，原始代码的丑陋中蕴含了大量的通过测试（测试团队或者用户使用）才获得特殊需求，而这种在一开始很理想化的设计的时候几乎都是考虑不到，这部分极有可能要再走一遍。
• 如果和原始团队水平大抵相当的话，那么重写之后大抵也是类似的水准

那么不妨跳出”重写“的这个局限，可以看出代码如果能够在设计和实现上更加的优美，在诡异需求的时候能够有足够的文档和说明，这是多么重要的啊，一开始就把事情做对，那么就不会陷入”泥潭中的怪兽“的绝境，也不会给项目带来”需要重写“的危机，糟糕的代码即便最后决定不重写，也会大幅度拖慢项目进展。

一份能够经过时间考验的代码，对初始的奠基人的要求是超极高的，务必要以虔诚谨慎的态度投入其中。

26&27 了解内部机制

这一部分的道理很简单，但是我们极易因为懒惰而犯这样的错误。

就是现在东西越来越大越来越复杂，越来越多的东西被抽象，但是要把东西用对用好（而不是随便用用），你必须还是要懂的其内部的机制（这也随着规模越来越大，变得越来越难了），而内部机制的比例规模就像冰山未露出的部分那么大。

比如STL，了解了其中的内存分配机制之后，你就很容易写出不仅对，而且高效的实现出来。

游戏引擎也是如此。

最后jeol给了这样的建议，如果你没法找到一位你将要依赖的语言和平台方面有几年扎扎实实的实践经验的专家之前（套用引擎也适用），不要贸然启动一个项目。

29 全能型管理团队

jeol在这里列举了大量事实，说明商业上很棒的人，但是对技术不懂的人，根本无法领导一个软件公司。

同时如同网景公司（同时也让我想起了idsoftware）这种，对技术很在行，但是商业方面很有欠缺的人也很难领导好一个公司。

尽管很难，但是这就是一个事实，要想让公司发展的好，管理团队就需要能够很好理解并且喜爱技术和商业。

31 作为哼哈二将，只管去做事

这一章颇有意义，项目管理不只是项目负责人才能做的事情，做为底层的开发者一样可以做很多，方法就是：只管去做就好了。

项目组里有这样那样的问题，但是你可以用你做事的正能量来影响项目组，先保证自己的事情完成，然后去做一些帮助项目组的事情（设置sourcecontrol，bug数据库，写一些文档。。。）。

32 放权问题

如果下属足够强力可以信任，那么就交给他去做，否则要干预，单纯说信任或者说控制都是不对的。

33，要好好设计

极限编程里面提倡的是不要过度设计，但是很多人歪曲成不要设计，上来搞起，不行再改。。。然后就倒霉了

要好好设计，就这么简单

35，提防非自主开发综合症

这一章我觉得是这本书里最棒的一章，很精辟的谈论了我们的常常会遇到的，而且是战略级的问题：是自己来做还是使用别人的。

jeol给出的答案是（我也非常赞同）：

如果这个是你的核心业务，如果程序开发团队能做好，或者不会明显差，那么即便会耗费很大的精力，还是要保证自己来做。

这就是ue和ce里面的stl部分都自己来实现的原因，因为性能是engine的核心业务，而stl在性能和一些feature上的支持并不好，所以一些容器类要自己来实现。

而tree什么的对于ue并不是核心业务，那么使用第三方的speedtree未尝不可。

究其原因就是，核心业务方面不只是要求能够完成，而且有着非常高的要求，比如engine里面就要尽可能的快，效果好，开发效率高，这是真正定义你的价值的部分。

而重用一些第三方的东西，一般来说不会出现能够完全满足你的需求和质量要求的东西（否则你就没有必要存在了），而你需要保持一个在漫长开发周期中，对核心业务的控制力和持续提升的能力，这只有你自己做才能实现。

当然如果自己搞不定，那还是多快好省的重用第三方的为好。

36 ben&jerry与amazon

这里谈及了一个比较有意思的商业策略：

• 如果市场比较空，那么amazon这种使用大资金大投入去抢占市场的方式是比较好的
• 市场比较空的时候，抢占市场最重要，投入的资源几乎一定会有产出，时间才是最重要的因素，如果能用钱来换时间，那么就去做，比如核心技术人员要搬家，那么公司就应该雇人帮他搬，然后让他把搬家的时间拿来工作
• 如果市场比较饱和，那么就要走ben&jerry公司的方式，一步一个脚印的去积累，先保证不死，然后去一点点扩大自己的生存空间

37 鸡与蛋的问题

这个在手机上比较明显的问题，系统要卖的多才会有人来给这个系统开发软件，但是要有人开发软件才会卖的多，这个鸡与蛋的问题。

实际解决的时候jeol提到了其中一个方面，即兼容性。

在软件开发过程中，对于不是相距很遥远的软件提供兼容性，可以让你不至于失去很多用户，进而能够保持鸡与蛋问题上的平衡。

实际中，苹果的app store通过很棒的政策，吸引开发者来开发，进而和苹果产品互相促进也很棒。

里面一个示例让我印象很深刻，win95的内存机制更准确，但是当时流行的软件simcity有一个bug，既是释放了一个内存，然后又立即使用它，在原先的pre win95的系统的内存机制下可以，但是win95不行，于是ms就反汇编了simcity，然后专门提供了一个simcity的模式，这样simcity爱好者在win95下也能很好的玩到simcity。

纯技术上看，这简直太下贱了，但是在商业行为上，意义重大。

40 公开源代码的经济因素

这里是一个微观经济学的一个定律：对产品的需求在其配属品价格降低的时候提高了。

比如去海南的机票便宜了，那么去海南旅游的人就会变多，顶饭店的人也会变多一样。

这就是为什么大公司会开发如此多的免费产品，ibm会大力开发eclipse，sony和微软都会给游戏机提供免费的（当然还是比较粗糙）的游戏引擎雏形。

超越时代的技术

在读这本书的时候，里面不停地提到为数不少的很超前的技术，但是都因为不适合当下结果终结了。

这就好像自然界的淘汰法则一样，如果原始人突然有一群人变异，变成智力很发达但是体力不行，或者抵抗力不行，那么这种在几十万年后会成为宠儿的人就会被自然界因为抵御不了这样那样的危险而淘汰。

适者生存，就这么简单！