博客首页 | 排行榜 |

马建辉

没有版权,欢迎转载, 功德无量。

个人档案
博文分类
【技术人生】读《人月神话》有感  2012-12-21 15:17
分享到:

本篇技术笔记是《人月神话》一书的读后感。

这不是一部讨论软件设计技巧的书籍,在这本书中看不到任何具体的设计模式或者架构或者编程语言的介绍,甚至它也不是讨论软件工程的书籍,那种书籍是让我们睡着觉的催眠剂。事实上它是一个软件大师结合自己多年主持软件项目开发的经验,非常务实地在分享自己的经验心得,这里面分析了软件本身及其开发过程的特性、人员组织、进度管理等有关软件项目管理的内容,某种程度上,它是关于人和团队的书。

 几天通读下来,不觉枯燥,大师就是大师,能把复杂的事情很简单得表达明白,一个突出的地方在于它非常人性化,不仅描述软件的特性、软件开发的特性,很多地方还涉及到人性。(很多书籍中将软件设计人员假想成没有任何情感和情绪,遵守任何规则的机器人)比如它客观讲述了软件开发过程中的创造性乐趣和劳动本身的艰苦枯燥,它支持技术主管根据专业技术角度做出的进度安排,鼓励他鼓起勇气去反对上级领导根据意愿而做出的进度安排。诸如此类,把一个严肃的专业书籍写得有趣、好读。

这本书给我们哪些启示呢?

1、 缺乏合理的时间进度是造成项目滞后的最主要因素

项目的估计和进度的安排是一门学问,多年的经验告诉我们:必须为系统测试预留足够的时间,无论自以为设计的程序多么完美,系统测试时肯定会遇到问题的,而且测试出来的问题基本肯定不是最后一个,当对程序进行修改后理论证明不会影响其他功能,其实实际上总会影响其他功能的,所以在做进度安排时,拒绝做一个乐观主义者。 

2、 用人月做为衡量软件工作量的单位具有很强的误导性

它隐含了以下假设:人和月具有互换性,而实际上“在进度落后的项目中添加更多的人手只会让项目更加落后”。人月确实是一个非常具有迷惑性的概念,项目管理人员尤其要对这个有清醒认识。 

3、 系统应该由尽可能少的人员来开发

这个论断来源于以下事实:

     优秀程序员和比较差的程序员在生产率上的巨大差异

     需要协作沟通的人员的数量影响着开发成本,因为成本的主要组成部分是相互的沟通和交流,以及更正沟通不当所引起的不良结果。 

4、 功能和理解上的复杂程度的比值是软件系统易用性的最终测试标准

复杂的软件功能和简洁的设计/良好的可读性是可以统一的,无论从什么角度,良好的阅读性都应该是对软件程序进行评价的重要标准,也是延长软件生命周期的法宝之一。 

5、 系统概念的完整性必须由一人或者少数有默契的人来实现;

从软件规模的角度而言,目前实验室所有项目都是小型系统,因此保证设计概念的一致性和完整性是必要的也是可行的,同时为了保证设计概念的一致、风格的一致,我们有理由保持短小精干的队伍,并由架构师维持系统整体设计概念的一致性。每个项目成员需要有足够的自我牺牲和严格自律精神。

书中讲到维护设计概念的一致性和完整性,需要专制和独裁,对于小型软件项目,不仅在概念完整性上需要保持一致,而且推行一致的编程规范和编码风格也是极其必要的,在这个层面上同样需要专制和独裁。 

6、 编程项目中的交流至关重要

毋庸置疑,在编程实践过程中,我们需要根据对项目的理解做各种各样的假设,假设的不匹配和冲突是造成冲突和进度拖延的重要原因。及时的沟通交流和良好的交流方式会帮助保持设计的一致性,同时保持队伍的短小精干也会减少不必要的人员沟通以及培训。 

7、 软件越接近完成,收敛得越慢

修改最后一个bug的时间永远是最长的,必须有足够的心理准备。不仅如此,初步写就的在系统平台上运行的程序和与高质量的软件产品之间有着深深的鸿沟,“软件产品的工作量是程序工作量的9倍”。有些夸张,但对这个论断保持足够的警醒是应该的。 

8、两个领导角色-产品负责人、技术主管

关于这两个角色的描述很有意思。我的理解是,产品负责人主外,技术主管主内。 

9、缺陷修复总会以20%-50%的几率引入新的bug

   除了修改缺陷时要小心再小心之外,对一个可读性强、架构好、质量高的软件进行缺陷修复要比一个破窗户似的软件进行缺陷修复容易得多,出现新bug的几率也小得多。项目新成员带来新bug的几率也会显著高于项目组原有成员。 

10、项目怎么延迟这么长时间?一次一天的进度落后

每次落后一天,慢慢地项目就落后进度一个月乃至一年,慢性的进度偏离是项目组士气的杀手,它难以识别、难以防范,同样也难以弥补。所以需要严格的进度监督,进度安排中里程碑的设计需要足够的清晰、具体、可度量。对进度的控制和把握是技术主管应该遵守的纪律。 

11、将软件作为一系列相关的产品族进行设计

       这对软件的设计提出了更高的要求,也是延长软件生命周期的必然要求。这个要求给软件设计人员提出了更高的要求,除了那些对单个软件的度量标准之外,还要考虑后续的扩展和升级,显然每个产品族的开山之作都需要付出更大的心血。

举个小例子,如果几个月后自己读自己写过的代码,读着觉得很费劲,那怎么能期望其他人在维护你的代码时可以很好的维护呢?毕竟阅读代码是维护代码的前提,维护工作的90%的时间都是用在阅读代码上。

有待进一步加深理解。 

12、文档是项目管理的主要工具

书中提到了文档的几个作用-提纲挈领、项目沟通。我想管理人员可以认识到文档的作用,但对于大部分技术人员,写文档实在是一件彻头彻尾让人厌恶的事情-令人分心,毫无用处,这也是目前大部分技术人员的心语。

很多人不愿意写文档,除了惰性的原因,还在于一旦文档化,便成了被评价的对象,口头交流,很快忘得一干二净,而见诸于书面,就成了个靶子(很容易被断章取义,或者吹毛求疵,比如给人造成这样的印象:通过这个文档,觉得这个人水平也一般般嘛,或者这个家伙真显摆等等)。可是项目相关的文档本身具有极强的信息指示功能,比如理应被所有人员接受的事实或者策略,可能有的小组成员根本不知道,只有见诸于书面,矛盾和分歧才会凸显,只有文档才能真正起到信息散播的作用。 

13、复用需要管理支持

软件复用,可以分为好几个层级,包括语句级别、函数级别、模块级别、系统级别,层级越高,系统的健壮性也越高,而且它不仅仅局限在软件设计人员自有代码的重用,还应该包括组织级别代码的复用,但这需要管理层面的支持。

这里需要强调一个概念,可复用的软件资产需要受控,并且需要有正式的发布,即必须保证该复用的模块或者函数,是足够健壮的,并且除非有重大缺陷,不可变更。

这本书里面还有很多值得深深思考的论点,它是以口号或者标语的形式提请读者们去注意去思考。比如:保持队伍的短小精干,以省去不必要的沟通交流;管理人员需要鼓励技术人员进行如实的项目状态报告;其他不在一一列举了,其实经过多年的开发经验和碰壁教训,再加上这本书中一个个醍醐灌顶的论断和描述,我们对软件特性、软件开发过程、团队合作与沟通交流的了解应该更加深刻,对后续的从业生涯可以走得更加从容,更加出色。

写在最后的话:

软件是迄今为止最复杂的系统之一,不仅在于软件本身的复杂性,更在于人的行为复杂性,所以在加强技能培训的同时,更需要培养软件设计从业人员的专业素养和专业精神,我认为,需要具备的专业精神包括但不限于: 

1、追求卓越 

书中提到(更多的大师们也证明了)卓越的设计来自杰出的设计人员,做为软件设计工作者,无论是个人角度还是从公司角度,都不要拒绝优秀和卓越,平庸不会带来快乐,只会把你拖入日益落后的进度和无休止的低效率的工作泥潭。 

2、追求完美 

我始终认为,设计人员需要偏执主义,对于写代码的,容不得任何bad smell的程序,不断地对代码进行清理和重构,不断地改进程序的可读性、独立性、可扩展性、健壮性,追求设计对象的完美,不仅能够带来具备经济价值的产品级代码,更能带来孜孜追求软件质量的过程中思考的乐趣、创造中的苦与乐。

对于结果,我们在意,对于过程,我们同样关注。提个现实问题:从软件设计各个分工的特性和人性出发,软件的设计开发过程中的追求完美会带来创造的乐趣,可相对而言,软件的测试工作便不具备足够的动力也很少得到创造的乐趣。所以想在实验室内部真正推行代码测试,必须正视这一点,因为软件是与人的创造性密切相关的活动,执行还是在于人。当然除了这个因素,目前软件开发人员编程不规范以及没有进行代码测试的迫切需要也是要素之一。 

3、进取的心态 

进度的落后会带来巨大的灾难,不仅包括经济上的,它更会摧残项目组成员的心理。所以必须有清晰的里程碑定义、如实的项目状态报告、进取的团队合作,项目组成员积极进取的心态是保证项目积极进展的先决条件。

进取不等同于盲目乐观,由于对项目的规模、进度、人员、预算上的估计是非常主观经验性的,而对软件特性的了解直接关系着对软件设计工作量的估计和进度的安排。所以本书对进度和预算的安排有着直接的指导意义,也颇具有现实意义。

类别:胡言乱语 |
上一篇:【设计作品展示】uCOS-Ⅱ平台电动汽车仪表盘的设计与实现 | 下一篇:【技术人生】论嵌入式软件设计中的极简主义
以下网友评论只代表其个人观点,不代表本网站的观点或立场