阅读笔记1: 人月神话

“人月神话”这个书名乍听起来真像是一部科幻小说或是言情小说的名字,真是很吸引别致,后来经老师提醒才知道这竟是一部在软件行业中享有里程碑地位的名著,一部在软件领域拥有极高声誉,畅销了20多年的必读经典。在这本书中,以我的总结,作者主要详述了包括工程计划,团队组成,文档重要性,项目排错等等的软件工程世纪的方方面面。

而“人月神话”顾名思义让人联想到神话故事,而事实确实作者阐述软件开发项目上项目进度和开发人员这两个概念的不能互换与混淆。

对此书,老实说,可能能力十分有限,对其理解也不是很深刻,在此提出对我影响最深的几点概念: 焦油坑的提出使我想到一个事实,虽然此书出版已20多年,但它所能反映的在软件项目上的问题依然能给软件工作者带来困扰,就如同在焦油坑中挣扎,问题依然没有解决。

人月神话概念的提出,引出Brooks法则:向进度落后的项目增加人手,只会导致进度更加落后。这就是除却了神话色彩的人月。因此缺乏了合理的时间进度是造成项目滞后的最主要原因。

在第三章中,作者有用了一个很好的实例:外科手术队伍。他提出了疑问,如何在有意义的时间进度内创建大型系统呢?要使工作易于管理,他给整个软件团队使用分解的技术,明确了各个工作细则,明确体系架构和实现之间的界限,如系统结构师必须专注于体系结构,其他依然。

为什么软件设计会和贵族专制,民主政治有关呢?因为概念设计必须由一个人或有默契的少数人一起才能进行,概念完整性必须要求系统只反映唯一的设计理念,而用户所见的技术说明来自少数人的思想。 如何避免画蛇添足呢?这告诉我们必须坚持设计拥有两个系统以上开发经验结构师的决定,同时保持对特殊诱惑的警觉,才可以不断提出正确的问题,确保原则上的概念和目标在详细设计中完整体现。 软件设计很重视贯彻执行这一概念,以用户手册为中心,即需求分析,设计人员与实施人缘进行交流,会议,电话记录,电子邮件来沟通,避免理解错误,最终的测试以用户手册为准则进行测试。此时还要注意,不同系统的用户手册是不同的GUI的可能是界面说明,程序也可能是借口说明。

posted @   stdrush  阅读(50)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 25岁的心里话
· 闲置电脑爆改个人服务器(超详细) #公网映射 #Vmware虚拟网络编辑器
· 零经验选手,Compose 一天开发一款小游戏!
· 因为Apifox不支持离线,我果断选择了Apipost!
· 通过 API 将Deepseek响应流式内容输出到前端
点击右上角即可分享
微信分享提示