第4章讲述了当时技术工业处于了最低点时期,大量程序员失业,而同时在这个特殊时期OSAF获益匪浅,相继有志愿者和员工加入OSAF。软件常常涉及前台和后台,Chandler的后台工作陷入了艰难技术决定,他们需要一种“对象持久化”的机制,最简单的手段是采用另一种数据库技术,即对象数据库。各种部分的需求也越来越多,正经历一个危险时期。他们经过讨论开始了尝试,但是也遇到了很多难题。最后OSAF发布了Chandler第一个里程碑版本(其实是内部版本),虽功能很少,但是给团队成员带来了安慰和鼓励。

第5章管理软件必须要做交易,在软件世界里,多数选择都归为令人神伤的三向交易,通常都为坏消息。在对Chandler后端的争论开始后,卡普尔就认为需要聘请一位项目经理,来定制进度、做决定。为OSAF寻找项目经理的工作缓慢,软件项目管理中存在一种充满讽刺意味的天性,多数项目经理很清楚项目中的困难,他们会提前做些什么。在软件管理中,协作是工作的核心,OSAF在4月份发布了Chandler0.1版,接下来就是完整的设计方案。

第6章开篇通过作者想要备份方案,拖动了文件夹,但是文件夹却没有了,最后通过撤销文件夹恢复。卡普尔对软件的设计总是抱有热情,也一直致力于将软件设计确立为独立的专业领域。他的好多说法在今天看来都足以自证。他们关注的主题转向了文档,小组的讨论开始叫做文档架构会议,经过一个月后,他们遇到的问题解决了。卡普尔从0.2版吸取教训—该死的布鲁克斯法则。

第7章Chandler0.3版发布,意味着现在设计组渴求一张更彻底、更接近最终需要的Chandler外观和行为路线图,他们需要细节、需要蓝图、需要规格说明。规格说明是程序员的圣经,共享信息是Chandler最重要的特性之一。Chandler缓慢进展被怀疑,感觉永远也做不出来,但是一直坚持,坚信总会有回报。

posted on 2015-06-21 23:51  menghuanzhixing  阅读(157)  评论(0编辑  收藏  举报