《人月神话》读后感

     过去几十年系统、程序开发中,很多东西不是很完善,一个又一个的淹没在焦油坑中,程序编程编程系统产品,成倍需要高达九倍,而只有它才是真正有用的产品,是多数系统的开发目标。编程的乐趣有一种创建事物的纯粹快乐;快乐来自于开发对其他人有用的东西;整体过程体现出魔术般的力量;学习的乐趣;来自于工作易于驾驭的介质上。同时我们也有着编程的苦恼,必须追求完美;是有他人来设定目标,供给资源,提供信息;概念性设计是有趣的,但寻找琐碎的bug却只是一项重复性的活动。更新快,制作慢。

     软件项目中存在着灾难:1、开发人员对项目的非科学估测,乐观的认同;2、人数和时间互换的混淆;3、开发人员的乐观导致忽略了很多错误,相对反而增大了系统测试的量;4、软件经理空泛的估算,容易让软件顾客放弃自己;5、向进度落后的项目中增加人手,只会使进度更加落后。

     做任何事情不能太过盲目乐观,还得有科学性的依据,脚踏实地,切勿浮躁。

     有人认为一个开发队伍就应该像一个外科手术队伍——对应各自的职位、工作分配。这样可以避免杂事干扰工作,提供他们的质量和开发效率。同时,还要学会如何分布运作,交流模式,达到良好的效果。

     同时团队必须保证完整一致的概念,这样才能让开发人员统一完整的战线,也才能打赢这场项目开发站。概念的完整性要求一个人来完成,这就是所谓的贵族专制吧。开发人员整个队伍协同开展工作,根据技术说明。按照时间进度,然后以切合实际的行动去完成项目开发,这就是所谓的民主政治。

     一个结构师在项目开发中主要实现设计,但是不能支配开发人员,因为真正的实现是由开发人员完成的。结构师只是提供建议。

     我们需要一个非常必要的工具——手册,上面是产品的规格说明。这就是开发人员需要追求的精确程度,定义规定什么,未规定什么。形式化定义,要选择一个标准,其他作为辅助。

     项目开发首要看先决条件,如果没有,那么这是一个废项目,开发就是浪费财力物力人力。失败的教训中有两个重要的原因:交流和组织。孤立的工作环境并不一定好,开发人员缺乏交流,就对整个项目的问题不能进行及时的交流和解决,这样各位开发人员对开发进度无法全面了解。所以必要的交流是必须的。一个项目缺乏组织也是不行的。管理者对项目有个全面的了解掌握,才能进行全面的分工布局,对开发者进行恰当的位置分布,从而提供项目的开发效率和质量。项目工作手册,类似工作安排计划,这样项目才能有条不紊的进行。

     只有不断的实践,从实践中获得经验,才能在开发工作中做到胸有成竹。

     最后需要不断的对项目进行优化,一达到目前做好的效果。

     软件系统可能是人类创造中最错综复杂的事物,往往一个很小的功能,其实也需要开发人员进行完善的架构设计,考虑对其他模块的影响,以及代码编写工作的难易。用户在前台可能看到的只是几个文字,实际中却是开发人员日夜奋战的结果。客户的需求不会考虑实现的困难,有可能他们认为可以轻易实现的功能,却会让开发人员抓耳挠腮。不得不说,这是两个世界的对话。

     无论怎样,沟通是不可避免的,只有相互交流,相互理解,才能做出精品来。

      关于著名的Brooks法则——对于进度已经落后的软件开发计划而言,若是增加人力,只会让其更加落后。人们常拿人月来计算软件的工作量,但是Brooks发现软件的开发工作是需要人与人之间密切沟通的,使得设计工作不易分割。一般来说,一件复杂的工作大量投入人力,会使工作完成的更快,更加出色,但是在软件设计中,就不是。尤其是大型软件开发。往往增加人手反而会起到反作用。不得不重视。

赞 (0) 评论 分享 ()

相关阅读

    无相关信息