![软件随想录 卷1 - [美] Joel Spolsky](https://static.book345.com/covers/s/9787115384058.jpg)
书籍介绍
这不像一本四平八稳的软件开发管理指南，而更像一位脾气火爆、爱抬杠的资深工程师在博客上跟人吵架的合集。Joel Spolsky 最戳中读者的地方，是他对'抽象'的警惕：越是往上层爬，越容易遗忘底层那些简单却根本的东西，而多数灾难性的错误正源于此。他劝程序员从 C 语言和 CPU 讲起，劝团队'每日编译'、'立刻修 bug'、'给程序员安静的工作环境'，这些如今被奉为常识的做法，很多都出自他的直言不讳。书里商业内容占了不小比重，面试、激励、外包取舍，观点鲜明甚至偏激，'奖励有害''任务切换有害'这类标题本身就带着立场。它真正适合的是愿意被作者'冒犯'、并因此重新审视自己日常工作的开发者，而非寻求标准流程手册的人。
作者简介
乔尔•斯波尔斯基（Joel Spolsky）
是一名软件行业的资深人士，他的开设的个人博客“乔尔谈软件”（www.joelonsoftware.com）深受程序员们的欢迎，被誉为“反呆伯特宣言”。斯波尔斯基设计和开发了许多广为使用的软件，参与过的软件产品包括微软Excel和朱诺邮件客户端的用户界面。他还创立了位于纽约市的Fog Creek软件公司。
AI导读
核心看点
- Joel测试十二问，快速评估团队开发成熟度
- 深入解析Unicode与字符集，避免国际化陷阱
- 强调编写规格说明书，以文档驱动设计决策
读者共识
- 观点穿越二十年，至今依然具有极高参考价值
- 翻译质量参差不齐，建议对照原文或忍受
- 实战经验总结，比纯理论书籍更具启发性
精彩摘录
- "我觉得，人们所犯的一些最大错误（即使再体系结构的最高层）的根源在于，对处于最底层的几个简单事物理解不够或者一知半解。 编译器设计人员都知道的那样，语法分析与解释是在编译处理过程中最慢的部分。只要谈我们在解释、分析与建立抽象的内存语法树时，发现它涉及许多处理起来很慢的字符串素材，以及许多执行起来很慢的内存分配内容就够了。 所有这些事情都要求用户去思考字节，字节影响着用户在各个体系与策略方面做出决定。这就是我为什么坚持一种教学观点——大学一年级学生需要从基础学起，即用C语言以及从CPU开始向上逐步构建自己程序设计技能——的原因。"
- "Joel测试 1.使用源代码控制机制吗 2.能一步完成连编吗 3.每天都做连编吗 4.有故障信息数据库吗 5.在编写新代码之前修复故障码 6.有最新的进度表吗 7.有规格说明书吗 8.程序员拥有安静的工作环境吗 9.你用到了你资金能力内可买到的最好工具吗 10.你有测试人员吗 11.新聘人员在试用期写代码吗 12.进行走廊可用性测试吗 一个可用的故障信息数据库必须至少为每个故障包含如下数据： 1.重现故障的完整步骤 2.预期功能 3.观察到的故障行为 4.要分配给谁 5.是否已修复 如果故障跟踪软件的复杂性是组织你跟踪故障的唯一因素，那么建立一个包含上述关键信息的五字段关系表，然后开始使用它。"
- "每一位软件开发人员必须、绝对要至少具备UNICODE与字符集知识（没有任何例外！）"
- "我发现流行的Web开发工具PHP，几乎完全忽视了字符编码方面的问题而单纯地使用8位字符，它不太可能开发出好的国际Web应用程序。 因此，我要做出一项宣示：如果你是一位21世纪的程序员，却不知道字符、字符集、编码技术与Unicode方面的基本知识，那么要是让我逮着，我打算通过让你在潜艇上剥6个月的洋葱来惩罚你。我发誓我会那么做。 ASCII能够使用32-127之间的数字表示各个字符。这种编码能够很方便的用七个二进制位来表示。由于那个时期生产的大多数计算机使用8位大小的字节，因此用户不仅可以存放所有可能的ASCII字符，而且有整整以为空余下来。"
- "Unicode勇往直前地创建一种单一字符集，试图囊括地球上所有合理文字体系，以及诸如一些Klingon之类的人为书写体制。一些人错误地人为，Unicode就是一种每个字符占用16个二进制位，从而总共可以表示65536个可能的字符的16位字符编码方案。这并不十分正确。 事实上，Unicode在考虑字符方面给出了一种不同的思路。你需要去理解它的这种思考方式，否则一切显得毫无意义。 于是乎，光彩照人的UTF-8概念就横空出世了。UTF-8是另外一种存放字符串的Unicode代码点的体系，他在内存中使用8位字节存放那些神奇的U+编码。 即使你将我刚才所说的一切忘得一干二净，我也要请你记住一个极其重要的"
- "CityDesk决定在内部用UCS-2（2字节）Unicode处理一切。这种编码形式也是VisualBasic、COM与Windows NT/2000/XP作为其固有字符串类型使用的。在C++代码中，字符串就定义为wchar_t而不是char，并且使用以wcs打头的函数而不是以str打头的函数（比如说，使用wcscat与wcslen，而不是strcat与strlen）。 CityDesk发布Web版时，将网页转换为UTF-8编码形式，该编码方案多年来一直得到Web浏览器的良好支持。"
- "我相信，在任何重大项目（要花一周的编码时间或者一个程序员之力才能完成）上，如果不编写规格说明书，所花的时间一定会更多并且生成的代码质量总是更低下。 究其原因是，规格说明书最重要的功能在于设计程序。即使由本人编写所有的代码，并且写规格说明书仅仅是让自己看，写规格说明书的行为——将程序描述到每分钟做些什么这样详细的程度——也将迫使自己切实去设计程序。 故事的宗旨在于指出，在用人类使用的自然语言设计软件产品的时候，也许只要用几分钟思考几种可能性，并修正与改进自己的设计。 但是，当用程序语言设计软件产品时，就要花几星期进行迭代设计。更为糟糕的是，刚花两个星期写了一些代码的程序员将会非常喜爱那些代码，而"
- "一个普遍得令人害怕的错误是，在如何设计产品方面存在分歧，可争论又永远的不到解决。Windows2000的首席开发人员Brian Valentine因其座右铭“要么不到10分钟就做决定，否则接下来就没边了”而为人知晓。 编写规格说明书是使所有恼人的设计决定得以明确的极好方式，而不管决定的大小与否。要是没有规格说明书，决定方面出现的问题就会遮掩起来。即使很小的决定通过规格说明书也能明确下来。"
目录
用户评论
感谢把实战经验与教训分享出来的人，而不是把这些秘而不宣在企业内部。
和人月神话一样，是一本值得多次阅读的书，而且文风幽默
和程序员打交道的朋友也推荐来看看
顺手翻过了第一本，世纪初微软故事和更加不想看的软件工程，在我的“为不选计算机专业找补列表”上又添一项，为这书真的捋了一遍C语法——好吧，再添一项。
原来Joel是软粉啊..
书中的内容并不系统，确实符合“博客书”的说法。如果你想从本书获得管理经验或开发经验（系统性的），不推荐阅读此书，这本书更多的是一些实践出来的技巧
感觉年代有点久远。翻译很用心，已经非常生动了。比较多篇幅在讨论微软的产品，可能有些结论还偏过时了。最大亮点在于诙谐接地气的吐槽内容，感同深受。“别被架构航天员忽悠了，除非出了以前的技术做不到的东西，那别来浪费我的时间。”
与编程有关的内容很少，商业占了很大一部分。
有趣且有益的一本书，对于一个小白来说很多地方完全看不懂，看懂的地方都很受教，留着吧，会常读常新的
下载
收藏