随笔 - 119  文章 - 290  trackbacks - 0

博客搬家了哦,请移步
叫我abc

常用链接

留言簿(12)

随笔分类

我的博客

搜索

  •  

积分与排名

  • 积分 - 299330
  • 排名 - 84

最新评论

阅读排行榜

最近开始阅读《人月神话》,读到“外科手术队”章节,我就明白了这本书能如此受青睐的原因。
人月理论是不能应用于项目计划的,人数和时间并不是成简单的反比:人数的增加,则意味着不同思维的增加和交流的增加,当这一切默默的纠缠在一起后,项目就渐渐沉入沼泽。
传统的项目计划和任务分配方式,是将一个系统分为多个子系统,将每一个子系统的设计和编码分配给其中的一个或者几个programer。这种模式下我看到的现象是,一个无比混乱的组合,没有一个人拥有这个组合的完整的概念,包括main-programer;每一个programer只是随机(虽然他们都经过认真的思考,并有可能选择了最佳的位置)的将子系统插入到这个组合之中,唯一的期望是子系统可以工作。
我想这一景象很多人会心有感触,这一传统的模式还是很普遍的,因为我就身在其中。
外科手术队是这样一种模式:一个或者两个主刀医师,main-programer或者framework-designer,负责定义整个系统的概念、约束和控制流,并将他们的工作成果交给programer去实现。就好比建筑师统一设计好了蓝图,然后由建筑队负责施工。试想如果建筑队里面的每一个家伙都兴趣盎然的给建筑的某一部分进行自己独有的设计和实现,并为了组合而相互妥协,那最终建成的东西将会是何物?
想必多数人对外科手术队模式的反映是:“所有的乐趣都被main-programer和framework-designer剥夺了”,“programer岂不是沦为coder,毫无前途可言”。但其实不是,外科手术队并没有外包那么夸张,主刀医师只是定义了整个系统的概念、约束和控制流,但是并不出设计文档之类有关实现的东西,并且任务仍旧以子系统(已经被定义和约束)的形式分配,因此programer能在指定的约束下进行创造和实现。
有关外科手术队模式,我有过类似的经验。一个little-demo,3人的合作,我提取了其中所需要的所有的类,并为每一个类指定了接口,以及安置位置,也就是概念、约束和控制流。我拥有整个系统的完整的概念,但是我没有任何实现,我可以把它的每个子系统交给任何人实现,因为我清楚一切都能工作,不能工作又是谁的责任。每个programer可以选择任何实现方式,并在实现方式上进行设计。
OK,有关《人月神话》的内容暂时先这么多吧。

PS:另一个考虑的事情,是重构。似乎没有多少项目组,会在自己的项目计划中为重构保留时间,理由多半是进度和成本···但问题的严重性在于,传统的项目计划模式(非外科手术队模式),所组合出来的系统,本身就缺陷冗杂,如果没有适时的重构,病情只会越来越严重。因此我期望的模式是,为项目计划保留重构的时间,当项目版本进行到一定程度,大多数组员都认为系统需要重构的时候,就给出一个重构的版本周期,全员投入到重构当中。
重构会影响进度和成本,却没有多少证据证明这个论断:因为人们在尝试有益的事情之前,都直觉上的拒绝在重构上浪费时间,这只是一种只能看到短期利益的目光罢了——设计和编码并不是系统开发的全部!

再PS:老久没有更新BLOG了,结果排名之类的反而又升了一点····无语

posted on 2007-07-08 15:37 LOGOS 阅读(1249) 评论(9)  编辑 收藏 引用

FeedBack:
# re: 读《人月神话》 2007-07-08 16:00 天津大学计算机学院 常兴龙
哈哈,写得不错不错。尤其最后一句:老久没有更新BLOG了,结果排名之类的反而又升了一点····无语
  回复  更多评论
  
# re: 读《人月神话》 2007-07-08 16:40 SmartPtr
"老久没有更新BLOG了,结果排名之类的反而又升了一点····无语"

***************************
这可能是cppblog不够火的原因, 没有比较多的新人, 新文章涌现出来。。。对cppblog应该说是很可惜的一件事:)  回复  更多评论
  
# re: 读《人月神话》 2007-07-08 17:55 eXile
其实,这也是C++当前所处的境遇,CSDN的BLOG首页推荐上,甚至把C++拿掉了,也难怪,它已完全变成C++初学者的论坛。
对此,个人认为有几个原因:
1)c++越来越专注于特定领域
2)高水平的C++程序员越来越少(很多人是C大牛,但不是C++大牛)
3)c++自身发展的一些失误
  回复  更多评论
  
# re: 读《人月神话》 2007-07-08 18:11 eXile
正好在书中看到这么句话:
团队人数加倍并不等于开发周期的减半。它可能只会缩短1/3。如果团队超过10 个人的话,增加更多的人员可能反而会延缓项目的进度。
而且项目开发周期越长,团队内的成员对整个项目代码的熟悉度就越少,加上不确定的人员流动,新来人员的业务不熟等其他可能性,这项目会越来越复杂。
总的意思就是,项目人数不能太多,周期不能太长。
  回复  更多评论
  
# re: 读《人月神话》 2007-07-09 10:49 LOGOS
开发周期是不能控制的,这是本质问题,就好像5分钟的煎蛋流程不能压缩到5秒钟一样。
但是认为通过增加人手而能缩短周期的想法是不可取的  回复  更多评论
  
# re: 读《人月神话》 2007-07-09 12:10 eXile
开发周期可以通过软件的的版本升级进行控制,要不软件也不会有1.0, 2.0.....  回复  更多评论
  
# re: 读《人月神话》 2007-09-07 09:43 又见人月神话
See: http://blog.csdn.net/mmmbook/
这是一个链接梦想的博客。5年以来,真正品味过《人月神话》并深刻体验过的朋友,将在这里聚合。  回复  更多评论
  
# re: 读《人月神话》 2009-07-31 23:43 奋起者
我是第一次读《人月神话》的,虽然是第一次读,但是凭借我读年的读书的习惯,很快的可以捕捉到很有价值的东西。这本书真的是需要多次复读的。很有价值!  回复  更多评论
  
# re: 读《人月神话》 2009-07-31 23:47 河北师范大学软件学院--Gavin
作为一个软件工程的学生,我觉得学习如何编码很重要,但是当我这次读完《人月神话》,才意识到,能够编码原来只是一件很小的事儿。真正的软件开发还需要更高的境界!架构,软件,和项目的重构以及管理等等许多方面都是需要好好学习和培养的!  回复  更多评论
  

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理