网站备案是需要去哪里做,wordpress撰写文章卡顿,网站的登录界面怎么做,夜间网址你会回来感谢我的from:http://ttcs.spaces.live.com/blog/cns!C3759CC6FCEEBDD7!121.entry?sa147831050November 10梦断代码读后介绍 一#xff0c;这本书讲了什么#xff1f;软件是人们自以为最有把握#xff0c;实则最难掌握的技术。作者罗森伯格对OSAF主持的Chandler项目进行长期调查147831050 November 10 梦断代码读后介绍 一这本书讲了什么 软件是人们自以为最有把握实则最难掌握的技术。作者罗森伯格对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,《软件工程师的抱怨》一则有趣的笑话 软件工程师、硬件工程师、部门经理乘车去瑞士开会。行驶到一处陡峭山路时刹车突然失灵。汽车不受控制一路侧滑下去飞越过路障奇迹般地蹭着山石停了下来。乘客们有惊无险不过面临一个问题他们抛锚在半山上汽车制动无效。该怎么办 “我知道该怎么办”部门经理说“先开个会提出愿景形成任务书定义一些目标持续改进并找到严重问题的解决方案这样就能上路了。” “不行不行”硬件工程师说“太花时间了...我带了把瑞士军刀转眼间就可以拆下汽车的制动系统、分离故障并修好它这样就能上路了。” “嗯”软件工程师说“动手开干之前我想应该把车推到山上看看事故是否会重现。” 如果问程序员报告缺陷他的第一反应是问你“重现问题了吗”---意思是说你能确定让问题再现一次吗如果答案是肯定的事情就成了一半。如果答案是否定的程序员就会耸耸肩膀将负责推给硬件故障或者宇宙射线。^_^
