一，这本书讲了什么？
  软件是人们自以为最有把握，实则最难掌握的技术。作者罗森伯格对OSAF主持的Chandler项目进行长期调查，跟踪今年，
试图借由Chandler的开发过程揭示软件开发中的一些根本性大问题。

二，什么是"Chandler"？
  Chandler，一个开放源代码且跨平台的任务管理程序，最早的构思来自于2002年的Outlook-killer。
它是一个免费的组织工具，无论是什么格式或系统的电子邮件和日历任务，他都能进行处理并形成一个平稳的工作流程。
Chandler的别称为“Note-to-self Organizer”(自提示管理工具)。Chandler有很多的奇思妙想，而且为实现这些功能做了很大的努力。

chandler 1.0 下载链接： http://www.onlinedown.net/soft/69898.htm

chandler 1.0图片：

三，Chandler可以做什么？
 理想的Chandler是让任何一台电脑的使用者都能看到他所有的工作数据，如邮件，约会和个人清单 - 类似于一个大的任务管理容器。
换句话来说，它是专门为让工作完美完成而做的系统。而且用户不需要花费很长的时间来学习它。

四，Chandler开发过程：
 在最开始时，OSAF(开发组织的名称)预计在2003年底或者2004年初推出Chandler 1.0。而事实上，他们直到2005年11月份才准备发布Chandler 0.6版(本书只介绍到0.6版)。 
    a,项目构思于2001年和2002年之间，开始于2002年。

b,2003年2月20日，OSAF发布了Chandler第一个里程碑版本。其实“版本”一词并不确切：这只是个“内部版本”，供OSAF开发者所用，并不是为公众所用。

c,2003年4月21日，Chandler 0.1版，公开发布。24小时内，被下载了15000次。在经过漫长的杀bug后，同年6月，OSAF预计同年9月发布Chandler 0.2版。但是，由于资料库的问题，开发组陷入困境中，整个团队弥漫着沮丧的的氛围。开发组采用了时钟驱动的方法来管理。

    d,Chandler 0.2于2003年9月25日发布，距OSAF首次公开Chandler计划已经近一年。它的发布伴随着质疑。下载和使用了这个版本的少量用户惊奇地发现，它的功能比Chandler 0.1还要少。它就像是在一个垮塌后又部分重建的架子上遮了个盖子。
               小对话：1，开发者迈克尔.托伊在blog中竟然写到：“Chandler 0.2即将推出，不过我恳请你们别下载”。
                   2，舍伍德问道，“我们要开个0.2版庆祝派对吗？”

                     “也许开个守灵会吧？”托伊回答说。
                     “不如默哀片刻”卡普尔建议说。
 画外音：如果OSAF还坚持原来的每三个月发布一次新版本的时钟驱动进度计划、尽力在2003年12月底发布Chandler 0.3版，则0.3版绝不会比0.2版更让人满意。
    

e,2004年2月26日，OSAF发布了Chandler 0.3版。新版本包括了新的组件和更成熟的资料库，但基本上还是没法用。但OSAF内部的氛围却与发布0.2版时全然不同。程序觉得自己有了动力。
 画外音：好的程序架构有其内在的吸引力，能够使得开发者愿意继续工作。

      f,Chandler 0.4版于2004年10月26日发布，但一周内只有一千人下载。新版本在启动时看起来有点更像是真正的软件应用，如果你愿意深入挖掘的话，还能发现一些内建的新功能。下载量的下降不足为奇。世界，至少到目前为止，一直在进步。许多以前为Chandler发布高唱赞歌的外部人员抛弃了它，有些正式参与者认为它迷失了道路。但是OSAF内部第一次充满了宁静的感觉。
      一个现象：开发者卡普尔从项目开始就坚持要做诚实、现实的计划和进度安排。但项目在满足进度方面却拥有不佳的记录：平均6个月能发布一个版本，但计划却总假设应在3、4个月内完成一个版本。

       g,Chandler 0.5版于2005年3月30日发布。Chandler现在拥有150万行的代码。在同年4月的中旬，博苏特发现，每位开发者差不多还得花40个工作日才能修正完0.5版留下的缺陷。

       h,开发者准备于2005年9月发布Chandler 0.6版。但此时，他们已经迎来了几十位新同事，也送走了几乎同样数量的老伙伴。他们编写了数以万计的代码行，也面对了自初次构思以来快速变化的软件市场。

五，有趣的点子：
   a,《大教堂和菜市场》---开发软件的两种方式。
      1，大教堂方式：重要的的软件需要像建教堂一般，由独立的巫师或一对相互隔离的魔法师潜心打造，在面世之前绝不发布beta版本。
      2，菜市场方式：早发布、多发布、权委托、尽开放。看似一个乱哄哄的大集市，铺陈了各种日程和手法，要从中得到前后一致和稳定的系统，简直只能指望奇迹出现。可事实上，这种集市风格看来行之有效。

b,《奇客》---我们将要成为 * ？
       大约十年前，人们用“奇客”用来描述那些与计算机沟通易于与人类沟通的人。“奇客”的词源可以追溯到几个世纪之前。原义是“傻瓜”或“笨蛋”。20世纪90年代，当个人计算机踏上美国商业和文化的舞台的中心，那些需要联网或安装打印机但又不懂技术的人，只能寻求身边“计算机奇客”的帮助。早期版本将计算机奇客定义为“以（计算机）程序缺陷为食---不善社交、身有恶臭、面色苍白的偏执狂，具有奶酪刨丝器一般的人格特点。”稍新的版本则带有更多自尊的意味：“奇客，专注于己事的人；追求技术和梦想、不融入主流社会的人。”
 
    c,《软件工程》，用词的谬误！
        正在修建的跨海大桥或者摩天大楼，或许最能体现人们对工程这个词的认识。的却，这也代表了人类对建筑学和物理学的认识和掌握。但当我们谈起“软件工程”时，其实根本就不是那么回事。我们不可能像普通工程那样给一个软件的开发制定出详尽日程，更不可能精准地控制软件开发的进度。很多时候，大型软件的开发更像是一群人在做一件艺术品，而工程和这一点关系都没有。 

d,《软件工程师的抱怨》，一则有趣的笑话：
      软件工程师、硬件工程师、部门经理乘车去瑞士开会。行驶到一处陡峭山路时，刹车突然失灵。汽车不受控制，一路侧滑下去，飞越过路障，奇迹般地蹭着山石停了下来。乘客们有惊无险，不过面临一个问题：他们抛锚在半山上，汽车制动无效。该怎么办？
     “我知道该怎么办”部门经理说，“先开个会，提出愿景，形成任务书，定义一些目标，持续改进并找到严重问题的解决方案，这样就能上路了。”
     “不行，不行”硬件工程师说，“太花时间了...我带了把瑞士军刀，转眼间就可以拆下汽车的制动系统、分离故障并修好它，这样就能上路了。”
     “嗯”软件工程师说，“动手开干之前，我想应该把车推到山上，看看事故是否会重现。”
  
     如果问程序员报告缺陷，他的第一反应是问你，“重现问题了吗？”---意思是说，你能确定让问题再现一次吗？如果答案是肯定的，事情就成了一半。如果答案是否定的，程序员就会耸耸肩膀，将负责推给硬件故障或者宇宙射线。^_^