豆瓣🔗:

电子书看多了真的需要换纸质书籍读读。这本书是阮一峰翻译的，所以读中文版也就还好。

印象中大三的那个寒假在本科图书馆根据目录大概翻阅了感兴趣的一部分。当时自己使用的语言主要是Java，看到作者“学校只教Java的危险性”这部分，记得当时害怕极了，尽管学过C和C++，但是自身的确在Java上花费了更多时间，当时有种落荒而逃的感觉😅。这几天重新看这部分以及这本书，有很多东西能get到了，阅读时有会心一笑的时刻。而且阅读过程中居然觉得作者心思很细腻，很多事情的论证都有点经济学和心理学的意思，一点都不nerd。

和《黑客与画家》的作者Paul Graham一样，都是很有趣的人，当然也很厉害。说实话还是很喜欢这种Geek的思想和幽默的。我猜想《软件随想录》没有《黑客与画家》那么出名是因为计算机专业术语比较多，有很多点要事先明白才能get到作者的幽默和讽刺。不过Joel讽刺网景和Paul Graham讽刺微软倒是不相上下😂。

很喜欢的书，阅读过程中想着应该买一本纸质书以后再读，或者直接阅读Joel的BLOG中最新的文章更好（但这不是为了逃离电子屏幕才看纸质书的嘛🌚）。

阅读中随手记录下笔记和想法。

《软件随想录 卷1》

第一部分 比特和字节：编程实践

02 回归本原

1
2
3
4
5

void strcat(char* dest,char* src)
{
  	while(*dest) dest++;
  	while(*dest++ = *src++);
}

这段代码使用了施勒梅尔算法。

施勒梅尔是笑话的主人，作者也太幽默了。

更佳的代码：

1
2
3
4
5
6

char* strcat(char* dest,char* src)
{  	
  	while(*dest) dest++;
  	while(*dest++ = *src++);
  	return --dest;
}

03 Joel测试

乔尔测试

(1)你们用源代码管理系统吗?

(2)你们能一键编译吗?

(3)你们做每日编译吗?

(4)你们有bug数据库吗?

(5)你们在写新代码前修改以前的bug吗?

(6)你们的进度表是最新的吗?

(7)你们有软件规格书吗?

(8)程序员的工作环境安静吗?

(9)你们使用了能买到的最好工具吗?

(10)你们有测试人员吗?

(11)你们面试时会要求应聘人员写代码吗?

(12)你们做过走廊可用性测试吗?

08 轻松撰写功能规划书

当你的某种做法遭到“不够专业”的批评时，你就知道批评者根本没有站得住脚的反对理由。

11 完美主义者是如何修复bug的

修复bug这件事，只有在它带来的价值高于其成本时，才值得去做。

15 干扰射击

也许这就是高效率的关键：只管开始就好了。

没想到Joel这样的大佬也会有拖延也会有摸鱼不想敲代码的时候。

你必须每天进步一点点。即使你的代码很烂，bug很多，没人想用，都没关系。如果你不断进取，不断写代码、改bug，那么时间就会站在你这一边。

有点鸡汤的感觉，但对当下的自己何曾不是种鼓励。

18 二元文化主义

UNIX文化看重编程对其他程序员的价值，而Windows文化看重编程对非程序员的价值。

读这篇对UNIX和Windows的认识更进一步了。

第二部分 管理开发者

23 任务切换有害论

(1)串行处理的平均速度更快；

(2)任务切换需要的时间越长，多任务并行处理的性能下降越明显。

并行处理不一定比串行处理更好，然后延伸到管理程序员：

对于管理者的启示是：永远不要把多于一项的任务指派给同一个人做。

24 永远不要做的事情

读代码比写代码还要难。

《软件随想录 卷2》

第一部分 人员管理

老实说，只要有两个以上的人待在一起，就会有政治。

当下还不太理解的一句话，还是在象牙塔里吧。

Robert D. Austin 写过一本书《组织绩效评估与管理》(Measuring and Managing Performance in Organization)。书中提到，当你引入新的绩效测量方法时，会有两个阶段的发展。第一阶段，你实际得到了你想要的东西，因为还没人想出作弊的方法。但是，到了第二阶段，你实际让事情变得比原来更糟，因为每一个人都想出了如何将你测量的指标最大化的对策，即使代价是毁掉公司，他们也在所不惜。

耳目一新的论点。

第三部分 设计的作用

除非受过专门训练，明确知道自己想要什么，否则人们挑中的就是自己最熟悉的。