《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的程序员，而且一般我们所在的公司里面充满了水平很一般的程序员，测试团队是必须要有的，当然这个测试团队可以是程序员自己，也可以是一个专门的测试团队，但是必须要有。
- 测试并不是一个巨简单的工作，好的测试人员的抓错能力和差的相差很大，软件越是复杂，这个越是大，作为最复杂的软件之一：游戏，程序员的测试能力只能用很差来形容，简言之，程序员自己的测试能力是不够的。
- 客观地说，程序的人力成本毕竟是要高于测试人员的，出于成本的考虑，也需要有专门的测试团队。
- 实际上，比较好的公司会做很多这样的成本计算和控制，比如给程序员最好的机器配置，办公室搬家的时候有专门的人来搬
另外一个切肤之痛就是我现在经历的引擎和游戏一同开发，美术团队等待引擎工具的功能来产出，项目自己也有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提的两点我很赞同：
- 程序员有一种做完美建筑师的倾向，其实这个倾向是程序员技术快速持续提升的重要价值观，在作为纯粹技术来说，非常好的一个特点，但是实际做产品的时候，就需要产品端的视野来平衡
- 阅读代码比写代码要困难的多，尤其是经过产品化的代码，常常会很是”很丑陋“以至于阅读和搞懂这样的代码非常的痛苦，重写则爽多了
- 丑陋的代码或许是必须如此
- 它就是有那么多奇怪诡异的情况要处理，也就是你再写一遍也差不多，同时你浪费了那么多时间
- 那些诡异情况，常常是在一开始写的时候想不到的，然后实际测试或者上市的时候才发现的，然后才添加了，原始代码的丑陋中蕴含了大量的通过测试（测试团队或者用户使用）才获得特殊需求，而这种在一开始很理想化的设计的时候几乎都是考虑不到，这部分极有可能要再走一遍。
- 如果和原始团队水平大抵相当的话，那么重写之后大抵也是类似的水准
31 作为哼哈二将，只管去做事
这一章颇有意义，项目管理不只是项目负责人才能做的事情，做为底层的开发者一样可以做很多，方法就是：只管去做就好了。
项目组里有这样那样的问题，但是你可以用你做事的正能量来影响项目组，先保证自己的事情完成，然后去做一些帮助项目组的事情（设置sourcecontrol，bug数据库，写一些文档。。。）。
32 放权问题
如果下属足够强力可以信任，那么就交给他去做，否则要干预，单纯说信任或者说控制都是不对的。
33，要好好设计
极限编程里面提倡的是不要过度设计，但是很多人歪曲成不要设计，上来搞起，不行再改。。。然后就倒霉了
要好好设计，就这么简单
35，提防非自主开发综合症
这一章我觉得是这本书里最棒的一章，很精辟的谈论了我们的常常会遇到的，而且是战略级的问题：是自己来做还是使用别人的。
jeol给出的答案是（我也非常赞同）：
如果这个是你的核心业务，如果程序开发团队能做好，或者不会明显差，那么即便会耗费很大的精力，还是要保证自己来做。
这就是ue和ce里面的stl部分都自己来实现的原因，因为性能是engine的核心业务，而stl在性能和一些feature上的支持并不好，所以一些容器类要自己来实现。
而tree什么的对于ue并不是核心业务，那么使用第三方的speedtree未尝不可。
究其原因就是，核心业务方面不只是要求能够完成，而且有着非常高的要求，比如engine里面就要尽可能的快，效果好，开发效率高，这是真正定义你的价值的部分。
而重用一些第三方的东西，一般来说不会出现能够完全满足你的需求和质量要求的东西（否则你就没有必要存在了），而你需要保持一个在漫长开发周期中，对核心业务的控制力和持续提升的能力，这只有你自己做才能实现。
当然如果自己搞不定，那还是多快好省的重用第三方的为好。
36 ben&jerry与amazon
这里谈及了一个比较有意思的商业策略：
- 如果市场比较空，那么amazon这种使用大资金大投入去抢占市场的方式是比较好的
- 市场比较空的时候，抢占市场最重要，投入的资源几乎一定会有产出，时间才是最重要的因素，如果能用钱来换时间，那么就去做，比如核心技术人员要搬家，那么公司就应该雇人帮他搬，然后让他把搬家的时间拿来工作
- 如果市场比较饱和，那么就要走ben&jerry公司的方式，一步一个脚印的去积累，先保证不死，然后去一点点扩大自己的生存空间