本来想等读完之后再来写读后感的，不过由于引起的共鸣或者说带来的感想确实不少，还是决定先写写，免得以后有所忘记，^_^
Joel on software不愧是jolt的得奖书籍之一，写的非常的不错，不过建议大家直接看E文版，不要看中文版，中文版翻译的实在不怎么样，给人的感觉根本就是直译的方法，象其中体现出不够专业的翻译的词到处都是，象连编、内用软件等等词，里面翻译的很多话都翻译的很晦涩，估计如果对joel讲的那个方面不懂的话，看中文版反而会完全看不懂...
Joel on software是本很薄的书，讲的主要是joel在软件方面的一些经验、想法、实践，joel是以前Microsoft Excel团队的领导之一。
目前看了大概一半，流水帐式的记录下读书的笔记：
1、Joel测试：改进代码的12个步骤
Joel测试，业内非常知名的对于软件团队的一种评价手段，12个步骤都点中要害，虽然估计大家都了解，还是决定在这里再次列出：
§ 使用源代码版本控制吗？
§ 能一步完成系统构建吗？
§ 做日构建吗？
§ 有Bug库吗？
§ 在编写新代码之前修复Bug吗？
§ 有最新的进度表吗？
§ 有功能规格说明书吗？
§ 程序员拥有安静的工作环境吗？
§ 你用到了你资金能力内可买到的最好工具吗？
§ 有测试人员吗？
§ 新聘人员在试用期写代码吗？
§ 进行走廊可用性测试吗？
以上12点就是著名的Joel测试了，你可以试着对你的团队打打分，只有得到11分或12分的才是比较好的软件团队，而10分以及10分以下的团队都存在这样那样的问题。
Joel举了个例子是微软中的软件团队都在12分以上.........
其实自己看了下，确实，这12点都是对于团队来讲很基本的要求，但是你的团队能得几分呢？
2、Unicode与字符集知识
Joel认为每个程序员都应该了解Unicode与字符集知识，java界的程序员由于基本都会碰到编码问题，所以我觉得这个部分对于java程序员来说通常都不是大问题，不过我从这章节中仍然是学到了更为底层的编码知识，^_^
3、功能规格说明书
这个部分一直就认为至关重要，无论是产品性质还是项目性质，功能规格说明书其实和平时写需求规格说明书还是有些不同的，功能规格说明书其实通常都已经向用户展现了一套真实的系统，joel在书中说的一点给我感触颇深，就是写这种书的时候应该写的带有些趣味性，这点看似容易，做起来难，就像XP中的系统隐喻一样。
4、每日构建
这个相信大部分业内人士都已经认同了，但有多少团队在真正的执行呢？
这个章节给我带来的最大的体会不是每日构建的好处的学习，这个我都已经知道了，最大的体会是当joel讲到编译器是为了提升edit－compile－test这个环，给我带来的最大的感想就是要提升团队能力、效率其实同样也是这样，去寻找这个环，就像jira这样的工具就可以帮助提升report－fix－test这个环的效率。
5、Bug修复
这个章节让人体会到了做软件各个环境还是要想到软件的本质的，软件的本质是商业性质的服务，所以即使在进行Bug修复要有去考虑商业性质上的因素。
6、稿纸原型开发
^_^，这个章节带来的共鸣来源于我很多时候都倾向于用纸、白板来表达我的设计思路，而不是用visio、rose去绘制那些受N多规范约束的图，更讨厌别人在看这些图的时候首先看的是这些图是否符合这种、那种规范。
稿纸原型这种方法其实同样，更容易进行快速的交流....
7、自动获取用户故障报表
这个我想是N多软件人员都想做到的，^_^，自动的获取用户的故障报表，这样对于修复bug会有很大的帮助，多么的希望有这样的记录方式：对于出现异常的部分就会有操作过程的完整录像，同时提供相关的环境信息等，这样的话对于bug的修复会有很大的帮助。
8、面试游击指南
面试绝对是个很大的学问，要求在很短的时间较准确的去评估一个人是否适合某个职位，joel给出了他的面试步骤：
§ 介绍自己
§ 询问应聘人员最近从事的项目情况
§ 问不可能回答的问题。(如北京有多少个公交车站)
§ 程序设计提问
这个环节很重要，目前情况来看，还是能现场让面试者在机器上写点代码比较好.....
§ 你满意吗？
§ 你有任何问题吗？
joel表达的重要思想和我之前写的一篇blog一样，面试人员应该给应聘者创造一个轻松的环境，让应聘者尽量的展示他自己的能力，joel认为对于应聘者他最看重的是机敏和成事这两个方面，机敏表明了joel很重视应聘者的学习和适应能力，成事则表明joel很重视应聘者的实战能力，而不是纯粹的理论水平。
9、不配备测试人员的五个首要(错误)原因
这个环节给我很大的体会，至少在我经历过的几个公司都没有做到配备测试人员的条件，而且测试人员到底需要什么样的水准，在现在的业界也没个准，反正我是一直认为合格的测试人员应该是由高程、系统设计师这样的人发展过去的。
10、任务换人有害无益
这点深有体会，在这个章节中joel讲的重点是同时面对多任务的现象，这里他举了个例子，是多线程处理的例子，我们都知道，一直以来都认为多线程处理方式的支持是业界的重大发展，joel举了个例子去说明多线程处理的时候效率远比顺序执行的时候慢，当然，其实我觉得这是joel举的一种特例，他主要还是为了去表达人去面对多任务通常来讲是不如让这个人按顺序的完成任务的好，这点我是非常同意的，至少我自己就是这样，就像joel书中所说的一样，当面对一个任务的时候我基本都会较好的完成，但当同时面对两个任务的时候很容易造成两个都完成的很慢或者一个完成的较好，而另一个则根本就没怎么做，主要是在任务切换的时候需要花费很长的切换时间，joel在书中所说，本来一天八小时的有效工作搞不好会变成两小时，^_^，我就经历过这样的现象。
BTW：
Joel网站：
http://www.joelonsoftware.com