怀着很好奇的心情,我开始了第零章的阅读,这一章的标题是软件时间,其实大致浏览了一下目录发现这本书的标题其实很灵活,有的标题让人感觉摸不着头脑,但是我相信当我读完这本书的时候我就会豁然开朗了。言归正传,在这一章中主要是编者的自述,读起来更想是在读一篇小说,在编者的自述中可以看出他的编程经历,从他的身上其实是可以看到自己的影子的,因为将来我也会是一名程序员,那种心境是我完全可以感受和体会到的,其中有一句话我觉得说得很有道理,作者之所以将本章标题命名为第零章,是想指出计算机程序员和其他人的一处小小不同:程序员从零开始计数,而不是从一开始。作者这一个小小的搞笑其实也使我们产生了共鸣。在作者的叙述中我也了解到了软件的发展历程以及过程中好多伟大的研究者为其发展而做的贡献,让我深刻的体会到软件工程的摩天大楼不是一下子就能够盖好的,是需要我们付出数百万倍的努力的,这一章使我对软件工程的发展陷入了深深的思索。。。
接下来开始了第二章的阅读,同样,标题让人捉摸不透--死定了,怀着疑问的心情我继续读了下去,这一章同样是运用叙事的方式,一开头讲述了程序员们因为完不成任务而陷入深深的苦恼中,他们其中的人认为原因是一直没有蓝图,才会碰到难以预料的问题,而另一个人认为不确定因素太多,所需时间取决于他人所花的时间。然而他们记录在Bugzilla中的第44个缺陷过了好长时间仍然没能修复,一开始他们认为是一个小问题,没想到居然花掉了他们大把的时间,最终意见取得一致:黑洞式的缺陷,即无法确定修正所需时长的缺陷,,在Bugzilla中应该用特别的警示词标记出来,后来又提到了软件项目难以按进度安排实现,这种情况极为常见,而且为众人所宽容。在软件开发的世界里,进度延误普遍到人们特意生造出一个委婉词来描述它:slippage,也就是失速的意思。作者用了一个很形象的比喻来解释这种状况:就像是在软件开发项目中暗藏有一条线缆,线缆系紧时,进展迅速,线缆断开时,工作停止。然而历史上任何软件均曾有其隐藏的线缆,对于改进软件开发所做出的努力,都是为了让线缆保持系紧。弗里德里克.布鲁克斯在《人月神话》中曾经说过,对软件时间所导致问题的最早也是最好的诊断。他曾经也提到,软件开发者通常都是乐天派,他们认为每个缺陷都可以被迅速修正,且修正旧缺陷必能减少新缺陷的数量,这种盲目乐观,加上程序员想要取悦主顾,往往让进度在一开始就偏离正轨。在预计及安排项目进度上的每一分努力,都是危险且具欺骗性的神话,所谓人月,是一种科学管理概念,它假定生产力可被拆分为不连续,无差异,可替换的单元。并且布鲁克观察到,只有在任务能分派给许多互相之间无需沟通的工作者时,人和月才是可互换品。了解到了布鲁克斯法则暗示最理想的开发组规模是一个人--无须停下工作与同事沟通的单个开发者。学术计算领域一直提倡开元,1985年,麻省理工怪才斯托曼对于商业软件产业封闭代码积习的憎恨,创办了自由软件基金会,发布了一种特殊的许可,即将全部代码,复用组合到新产品中,,这种被称为GPL的许可显然意在限制将自由程序私有化的行为,但是批判者将他看做是可怕的传染病毒。直到后来归纳出了开放源代码软件开发模式。开元不仅给出了一种生产和分发软件的替代性经济基础方案,它还能彻底改变软件开发的具体过程。在瑞蒙德的《大教堂与集市》中了解到了大教堂模式。接下来了解到了莲花开发公司的创始人卡普尔,了解了他创建软件公司的辛苦历程以及OSAF开发者的辛苦,以及Chander项目的运行历程。