《joel说软件》读书笔记

本书又名《软件随想录 卷1》，下面只是第一和第二部分的笔记总结，关于“第三部分joel对常态问题的遐想”暂时没有阅读。

• 回归本原

1.字符串连接函数 施勒梅尔算法

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

如果你要对一个字符串做上百次连接的运算，每一次都要从开头遍历，这就是施勒梅尔算法，它会让你的程序运行慢上一个级别。

如果返回最后一个字符的指针，那就快很多了。

char* mystrcat( char* dest, char* src ) 
{ 
  <span style="white-space:pre">	</span>while (*dest) dest++; 
<span style="white-space:pre">	</span>while (*dest++ = *src++); 
<span style="white-space:pre">	</span>return --dest; 
} 

2.c语言和pascal语言的字符串处理

c语言判断字符串的长度是在最后一个字符的后面加特殊字符"\0",而pascal是在第一个位置存字符串的长度。

3.内存分配的区块

4.xml和数据库的查询

xml和数据库的查询速度有巨大的差异

• 乔尔测试

补充：源代码管理系统：svn和github   Git和SVN之间的五个基本区别 - 文章 - 伯乐在线

• 软件开发者不可不知的Unicode和字符集知识。

1. UTF-16 UTF-8
2. 不能确定编码的字符串没有任何意义
3. c语言宽字符 L

• 轻松撰写功能规格书

     撰写功能规格书的3大理由：

1.      更改技术文档比更改程序代码容易的多
2.      节省沟通的时间
3.      没有详细的说明，就无法制定进度表

规格书应包含的部分：免责声明，作者，使用场景，非目标，概述，细节，待解决的问题，多角度的注解，规格书需要与时俱进。

谁来写规格书？

人月神话里说一个卓越的软件工程师比100个糟糕的程序员加起来作用还大，但是考虑到人件的影响，我们需要一个项目经理来领导其余的程序员工作。

如何招到靠谱的项目经理？不要招典型的程序员，不要招营销人员，不要让程序员听命于项目经理。

规格书写作技巧：要幽默（防止没人读），易于理解，不要过多的技术术语，如果有，过于学术化的名词要有注解。注意排版。慎用模板。

• 轻松掌握软件开发进度

1.使用excel

2.保持简单

3.每个功能点应该分成几个子任务

4.只有程序员才能准确的预估时间

5.细分任务，每个任务以小时为单位。

6.记录原始和当前的时间估计，训练自己的时间估计准度。

7.每天更新实际用时。

8.把休假考虑在内

9.把调试代码的时间也考虑在内

10.把集成时间考虑在内

11.预留缓冲时间

12.不要压缩程序员的预估时间

13.缩减功能以减少开发时间

• 修复bug

1.尽可能收集bug的所有信息

2.衡量bug的成本与收益

3.算出修复所有bug的价值

• 错误报告

建立bug数据库(小项目可以用记事本)

每个好的错误报告都要包括以下三个步骤：

      1.重现的步骤

      2.期望看到的

      3.实际看到的

好的测试员会把重现的步骤缩减到最短。

只有一开始测出问题的人才能关闭这个bug。

要解决错误可以有很多种办法，解决理由有：不予修正，暂缓，无法重现，重复的问题，设计限制。

• 软件开发的五个世界

注意这五个世界所要求的软件开发质量是不一样的。

• 二元文化

	核心区别	区别举例1	区别举例2	区别举例3
unix文化	重视为程序员提供有用的程序	重视命令行	一项程序结束如果没有产生任何输出信息，就说明程序执行正确	文档应该写的简洁而完整，读者可以推导出未写出的结论并且信任自己的推导，一件事很少会讲两遍.
windows文化	重视对非程序员提供有用的程序	重视图形化界面	程序执行后如果没有任何提示你就搞不清楚是因为出错了而没有输出还是没出错只是不输出。	了解一般使用者一般不读文档，因此一件事情会多次提醒。

为什么会出现这种文化差异呢？

因为unix文化成熟的时候没有那么多一般使用者，而windows就是要尽可能多的赚到用户的钱。

---

第二部分 开发人员的管理

• 面试游击指南

      面试官有时候会故意刁难你，看你能否坚持自己的正确的观点。好的面试者会坚持自己的观点，然后试图说服面试官。

• 重金激励害多利少

      原因是绩效考核的不正确，负面评价对士气伤害很大，而正面评价对士气的激励也不如想象的那么好(会让他们觉得自己是为了拿到好成绩才好好工作的，就像巴普洛夫的狗)。

      大多数人都认为自己把事情做得很好(即使不是)。

      评价机制的不合理：比如某人是团队的粘合剂，总是能够在士气低落的时候激励大家，某人总喜欢研究新技术，别人有问题总要靠他解决，但是他写的代码量很少，这两种人可能得到的评价很低，但是不可否认他们的作用很大。

      绩效考评会使团队产生间隙。

• 不配备测试人员的五个错误原因

      1.问题是懒惰的程序员弄出来的

      2.我的软件放在网络上。即使有问题也马上就能修好。

      3.客户会替我测试软件。

      4.有资格可以胜任的人都不想做测试人员。

      5.我请不起测试人员。

      注意这五条理由都是错误的。

• 任务换人有害无益

      作者用cpu并行和单步循环举了个例子，说明在切换任务上人所花的时间绝对比单步处理的时间多得多。

      绝对不要让人同时做一件以上的事。

• 不到万不得已不要想着去重构代码
• 冰川下的秘密

      程序员和非技术人员的思考语言不一样。

      客户不知道他们要什么，别再期望客户知道他们要什么。

      冰山理论：原型图上漂亮的接口只占10%的工作，而真正的90%的程序设计都是看不到的。

      推论1：把使用接口的画面展示给非程序人员看时，如果这个接口很不好，对方会以为你整个程序也是很不好的。

    推论2：相反，如果这个接口很漂亮，对方会以为这个程序几乎已经完工。

    推论3：展示时唯一重要的就是外观。一定要让它美得冒泡。

• 漏洞抽象定律

      可靠的tcp建立在不可靠的ip协议之上。

      所有重大的抽象机制在某种程序上都是有漏洞的，所以我们有一天遇到了这些漏洞，不得不去学习它的底层实现。

      比如二维数组的访问(内存分页)，sql语句查询的快慢(逻辑上等义的sql语句查询起来速度完全不一样)，c++的字符串处理。