《人月神话》读后感

  1. 职业的乐趣
  2. 职业的苦恼
  3. 编程系统产品
  4. 巴比伦塔,一个失败的伟大工程
  5. 祸起萧墙
  6. Silver Bullet!最强杀招!
  7. 落后的进度与增加的人力
  8. 独裁者
  9. 总结

职业的乐趣

问:这个职业好在哪里?编程让你很有成就感吗?

职业的苦恼

问:这个职业不好在哪里?哪些让你很不爽?

当你乐在其中的时候,我希望少点苦恼。

人月指工作量单位,即人力(人)和时间(月),若3个人花2个月完成项目则工作量为6人月。人月神话意味着人月是具有欺骗性质的,因为它暗示人员数量和时间是可以相互替换的,但实际上人月之间的平衡不是线性关系,5个人2个月完成的项目10个人1个月并不一定能完成。

编程系统产品

一个程序系统产品远难于个人独立开发、使用的程序。
程序:它本身是完整的,可以由作者在所开发的系统平台上运行
编辑器里的一段代码、一个方法,可以实现某些功能,可能有BUG。
程序产品:即把独立程序转变为可被任何人运行的、已经过测试的、有完备文档和可维护的程序。这将是独立程序的3倍工作量。
制造出来的一个组件,比如权限、流程引擎、SDK。
程序系统产品:即把程序产品转变为具有规范的输入输出接口、在功能上能相互协作可交互的程序集合,将组件集成为整个系统。又加了3倍工作量。
大多数人口中的“软件”,通过标准接口组合了N个程序产品,比如索思OA、云音乐。
所以,一个完整的软件系统产品将是一个独立程序9倍的工作量。
系统开发的目标应该是产出真正有用的软件产品。

巴比伦塔,一个失败的伟大工程

背景介绍

远古时代,人们分散在广阔无垠的大地上。人们都有一样的肤色,用同一种语言,说同样的话。在一次从大规模迁徙的过程中,人们发现了苏美尔地区的一处平原,那里地形平坦,土壤肥沃、水源丰富、灌溉便利。接着他们奔走相告并在那里定居下来。他们准备建造一座带有高塔的城市,这个塔将高达云霄。有了这个城市,我们就可以聚居在这里,再也不会分散在广阔的大地上了。技术方面来看,已经相对成熟了:烧制砖块、沥青提炼。
事情让他们的神知道了,神认为:他们只是一个种族,使用一种的语言,如果他们一开始就能建造城市和高塔,那以后就没有什么难得倒他们了。来,让我在他们的语言里制造些混淆,让他们相互之间不能听懂。”
这样,神把人们分散到世界各地,巴比伦塔也不能在继续建造下去了。

可行性分析

我们先分析下这个项目:一些成功的先决条件,他们是否具备?
先决条件 是否具备
目标? 有,很清晰,造塔!通天!
人力? 非常充足
材料? 泥土和柏油沥青,取之不尽用之不竭
时间? 无限制,历朝历代
技术? 具备,且有丰富的经验

失败的伟大工程

巴比伦塔是一个伟大的大工程,但失败了。
那么,为什么项目还会失败呢?他们还缺乏些什么?核心失败原因在于:沟通。

缩影

缩影,为什么说缩影?巴比伦塔可能是第一个失败的工程,但它肯定不是最后一个。
这样的悲剧在软件行业也一直在发生。要规避失误,我们需要交流、组织(交流的结果)
对于开发人员来说,交流与组织的技能累计和提高软件技术本身一样重要。
交流、组织的方式:
1、电话:
充分利用电话,少用钉钉微信。
2、会议:
常规会议中,团队一个接一个的简要技术陈述。这种方式非常管用,能澄清成百上千的细小误解。
3、工作文档:
书面记录决策是必要的。只有记录下来,分歧才会明朗,矛盾才会突出。
文档能够作为同其他人的沟通渠道。
文档可以作为数据基础和检查列表。
了解项目的来龙去脉,更准确的掌握需求和设计。
主人翁精神,参与感。

祸起萧墙

你了解到的需求不一定是真实需求。隐藏在需求文档背后的是什么?

软件行业有个经典词汇叫“改需求”,我写了条公式来概括我们的工作:

my_work = design + develop + test + release + patch*∞

这是常态,大家都懂。抛开bug不说,修改的过程很苦恼,可能会动你的设计结构、数据结构。作为技术人员,我们需要保证对整体设计的一致性和概念的完整性,除此之外,我们还需要控制系统的复杂程度。所以,在接到需求后多问一个为什么:

客户的真实需求是什么?

我们来看一个案例:今天中午我想吃西蓝花和番薯!

提问:客户的目的是什么?大家猜猜看(互动)
1、希望吃的健康点
2、和昨天吃的不一样
3、减肥路漫漫其修远兮

那么,有对错之分吗?当然没有。一千个人眼中有一千个哈姆雷特。

好,日常软件开发工作中还有很多需求。

从技术角度看,我们需要把上面这张思维方式给抽象化掉。

我们把侧重点放到“输出”。

如客户要的“输出”是希望健康点,那么我们可以把“午餐”包装设计的绿色、健康点。

这是一个协商的过程,目的就一个,让我们的软件功能更贴近用户,让我们的软件改动最小最稳定。

Silver Bullet!最强杀招!

现在有很多快速开发平台,但是真正能够不写代码就完成业务功能的开发平台基本上没有成功的,特别是在业务场景比较复杂情况下,编程自动化基本是不可能的事情。唯一看到有所突破的是关于统一框架和技术平台等方面的建设,在原有的框架基础上我们来构建一个产品开发平台,将跟业务关系不大的权限模型,工作流引擎等集成进去,将常用的可复用组件集成进去,加快开发速度。

不要在追求自动编程平台上下功夫,可以在加强组件复用和技术平台建设上下功夫。

要多从开发模式的改进上来解决没有银弹所提出的各种实际问题,虽然不能够彻底解决,但是可以通过努力来改进。比如增量迭代的开发模型,快速原型法,测试驱动,高级语言和图形化编程等。

落后的进度与增加的人力

进度落后与增加人力。记得当年看《C++编程思想》,Bruce说“十个妇女不能在一个月内生下小孩”(大意),于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的:“向进度落后的项目中增加人手,只会使进度更加落后”。
以前,增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话,难道只有“加班”一条路了?但长期加班是对个人的摧残,我更愿意利用业余时间去看书,例如看这本“人月神话”。)

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

独裁者

系统设计中最重要的是概念的完整性。应明白概念的完整性而不是功能的多样性是评价系统好坏的标准。概念上统一的系统更容易建造和测试。要保证概念上的完整性,设计应该由一个人或者观念一致的小规模小组完成。这看似具有贵族主义倾向,却是保证系统概念上的完整性的需要。架构师的角色与军队的统帅很类似,虽然独裁,但是却是必须的。分离建构和实施是建造大工程时保证概念完整性的重要手段。这不是创造性和非创造性工作的分离。事实上,实施过程中同样需要大量创造性的工作。

要保证项目尽快、低成本地完成,架构师与建造者之间尽早和持续的交流很重要。架构师应如何影响实施呢?首先应记住建造者有创造性实施的责任,架构师只是建议,而不是命令。其次,总是建议一种实施方案,但是永远准备接受其它同样好或者更好的方案。应无声和私人地给予这些建议,同时应准备对别人建议的好的方案给予赞扬和肯定。还有应能听取建造者对于架构的改进意见。第二个系统是一个设计的最危险的系统:最常见的倾向是过度设计。系统可能功能过于丰富,实际上只有半数的功能是常用的。为了避免二次系统效应,可以让一个设计师同时设计二个系统,另外,可以为每一功能付予一个优先值,这样如果时间不允许,可以去掉优先级低的功能。

在工程实施过程中,每周有架构师、软件和硬件实施者代表、市场计划者组成的小组例会是非常有用的。总架构师主持会议,如果对于一个问题达不成一致意见,由总架构师决定。会议应有确定的书面的讨论议案。另外,架构师应随时准备回答实施者对于设计的问题。实施者在有疑惑时不应猜测架构师的意图,而应询问清楚。询问的电话记录应集中起来,分发给所有实施者手中。项目经理的最好的朋友是他每天的敌人:独立的产品测试组织。

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

概念的完整性,对于很多小规模软件,由于开发人员不多,开发经理一般都能控制住所有的代码,概念完整性在组织层面就维持住了。但要注意以后的Bug修改,功能扩展的时候,也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统,则必须通过树状组织结构,层层控制,总设计师还是一到两人,每一层都有对下层的绝对把握能力。

我以前参加过一个15人左右的项目组,就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验,希望以后能有机会参与比较大的项目。

总结

作为一名软件工程从业者,我们的目光不应只停留在那些技术上面,我们应该通过各种渠道,去全面理解自己正在开发的行业,只有这样,才能更加清楚现在正在软件工程的内容的意义,去思考未来的更多可能性。

以上部分内容来自摘抄


转载请注明来源。 欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。 可以在下面评论区评论,也可以邮件至 sharlot2050@foxmail.com。

文章标题:《人月神话》读后感

字数:3.4k

本文作者:夏来风

发布时间:2019-07-07, 21:21:56

原始链接:http://www.demo1024.com/blog/read-rysh/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。