首页读后感 正文

人月神话读后感

时间:2016/11/4 10:00 分类:读后感

  人月神话读后感

  当我捧起《人月神话》,马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》,已经很久没有看到这么好的书了,郑重推荐。

  把感触比较深的几点记下来,顺便整理一下自己的思路,与大家分享。

  1,保持设计的概念完整。无论对小软件还是大软件,都必须由一个设计师主导,最多两个人讨论来共同完成软件的整体设计。作为一个软件,一个系统,必须有一个清晰明确的概念模型,大家都在这个框架下工作,所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念,但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是,即使是总设计师一直是同一个人,他脑海中所认为理所当然的规则或者概念,很可能由于没有明确的文档化,而没有成为所有开发者共同的概念。在其他开发者编码的时候,就可能会生成与概念相抵触的东东(模块,功能,算法),导致整体结构的恶化。这个时候总设计师一定要即时发现,做出更正。

  概念的完整性,对于很多小规模软件,由于开发人员不多,开发经理一般都能控制住所有的代码,概念完整性在组织层面就维持住了。但要注意以后的Bug修改,功能扩展的时候,也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统,则必须通过树状组织结构,层层控制,总设计师还是一到两人,每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组,就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验,希望以后能有机会参与比较大的项目。

  2,“一个拿2倍工资的人,生产率可能是其他人的10倍。”我和我的同学,一个小公司的技术总监聊起这个,他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人,做出的贡献特别大,应该相当于我们公司普通的十个程序员,不过工资最多也就是普通程序员的二倍。是不是有些不公平呢?我也说不清楚。因为那些普通程序员也十分的努力。不过,我觉得,作为公司,应该给最好的人最好的待遇,或者说给比目前更高的待遇。

  组建一个团队,最好的就是那种精英团队,大家都是牛人,效率会特别高。微软就是这种思路吧,把最聪明的人集中在一起,想不成功都难亚。

  3,进度落后与增加人力。记得当年看《C++编程思想》,Bruce说“十个妇女不能在一个月内生下小孩”(大意),于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的:“向进度落后的项目中增加人手,只会使进度更加落后”。(m.lizhi.com)

  以前,增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话,难道只有“加班”一条路了?但长期加班是对个人的摧残,我更愿意利用业余时间去看书,例如看这本“人月神话”。)

  如果不想加班,不想削减功能,不想推迟发布日期,那么……唯一的方法还是只有…加人。加足够的人。而且不要逐步加入,一定要一次性加入。要小心的是,新加入的人可能对原来的组织造成冲击,或者对原来的设计有不同意见(特别是加入的人中有比较强大的设计者)。那么,就当作,新组建了一个团队吧。交流,培训新人,就设计达成一致,继续向者目标前进。

  感触还有很多,以后如果有机会再写。不过,我决定去买本英文版回来,收藏,以后再多看几次。

热门文章

重点栏目推荐