1,我认为学习编程的最困难部分,是将做事的方式往追求完美的方向调整。
2,编程是由他人来设定目标,供给资源,提供信息。编程人员很少能控制工作环境和工作目标。用管理的术语来说,个人的权威和他所承担的责任是不相配的。
3,导致项目延期的主要原因:
首先,我们对估算技术缺乏有效的研究,更加严肃地说,它反映了一种悄无声息,但并不真实的假设——一切都将运作良好。
第二,我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆。
第三,由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地进行估算这项工作。
第四,对进度缺少跟踪和监督。其他工程领域中,经过验证的跟踪技术和常规监督程序,在软件工程中常常被认为是无谓的举动。
第五,当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。这就像使用汽油灭火一样,只会使事情更糟。越来越大的火势需要更多的汽油,从而进入了一场注定会导致灾难的循环。
4,作者关于软件任务的进度安排使用了很多年的经验法则:
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试,所有的构件已完成
5,每个团队成员认为自己是争取小红花的学生,而不是构建系统软件产品的人员。为了满足目标,每个人都在局部优化自己的程序,很少会有人停下来,考虑一下对客户的整体影响。
6,我主张在系统设计中,概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路,宁可省略一些不规则的特性和改进,也不提倡独立和无法整合的系统,哪怕它们其实包含着许多很好的设计。
7,架构师必须:
第一,牢记是开发人员承担创造性和发明性的实现责任,所以结构师只能建议,而不能支配;
第二,时刻准备着为所指定的说明建议一种实现的方法,同样准备接受其他任何能达到目标的方法;
第三,对上述的建议保持低调和平静;
第四,准备放弃坚持所作的改进建议;
8,一种普遍倾向是过分地设计第二个系统,向系统添加很多修饰功能和想法,它们曾在第一个系统中被小心谨慎地推迟了。
9,实践是最好的老师,但是,如果不能从中学习,再多的实践也没有用。(Experience is a dear teacher, butfools will learn at no other.)
10,我并不是很同意销售人员所吹捧的“完备信息管理系统”——管理人员只需在计算机上输入查询,显示屏上就会显示出结果。有许多基本原因决定了上述系统是行不通的。一个原因是只有一小部分管理人员的时间——可能只有20%——用来从自己头脑外部获取信息。其他的工作是沟通:倾听、报告、讲授、规劝、讨论、鼓励。
11,不愿意为设计书写文档的原因,不仅仅是由于惰性或者时间压力。相反,设计人员通常不愿意提交尝试性的设计决策,再为它们进行辩解。“通过设计文档化,设计人员将自己暴露在每个人的批评之下,他必须能够为他的每个结果进行辩护。如果团队架构因此受到任何形式的威胁,则没有任何东西会被文档化,除非架构是完全受到保护的。
12,系统软件开发是减少混乱度(减少熵)的过程,所以它本身是处于亚稳态的。软件维护是提高混乱度(增加熵)的过程,即使是最熟练的软件维护工作,也只是放缓了系统退化到非稳态的进程。
13,系统各个组成部分的开发者都会做出一些假设,而这些假设之间的不匹配,是大多数致命和难以察觉的bug的主要来源。
14,(为了使自己能够得到来自手下真实有效的信息),首先老板必须区别行动信息和状态信息。他必须规范自己,不对项目经理可以解决的问题做出反应,并且决不在检查状态报告的时候做安排。
15,培养设计人员:
第一,尽可能早地、有系统地识别顶级的设计人员。最好的通常不是那些最有经验的人员。
第二,为设计人员指派一位职业导师,负责他们技术方面的成长,仔细地为他们规划职业生涯。
第三,为每个方面制订和维护一份职业计划,包括与设计大师的、经过仔细挑选的学习过程、正式的高级教育和以及短期的课程——所有这些都穿插在设计和技术领导能力的培养安排中。- 118 -
第四,为成长中的设计人员提供相互交流和学习的机会。
16,那些想看到完美方案的人,其实在心底里就认为它们以前不存在,以后也不可能出现。- 亚历山大·波普,批判散文
Whoeverthinks a faultless piece to see, thinks what ne’er was, nor e’ershall be.- ALEXANDER POPE, AN ESSAY ON CRITISIM
17,创造性活动包括(1)概念性结构的形式规格化,(2)使用现实的介质来实现,(3)在实际的使用中,与用户交互。
18,软件产品易于掌握的特性和不可见性,导致了它的构建人员(特别容易)面临着永恒的需求变更。
19,“管理人员的职责不是要人们去工作,而是是创造工作的可能。”
2,编程是由他人来设定目标,供给资源,提供信息。编程人员很少能控制工作环境和工作目标。用管理的术语来说,个人的权威和他所承担的责任是不相配的。
3,导致项目延期的主要原因:
首先,我们对估算技术缺乏有效的研究,更加严肃地说,它反映了一种悄无声息,但并不真实的假设——一切都将运作良好。
第二,我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆。
第三,由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地进行估算这项工作。
第四,对进度缺少跟踪和监督。其他工程领域中,经过验证的跟踪技术和常规监督程序,在软件工程中常常被认为是无谓的举动。
第五,当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。这就像使用汽油灭火一样,只会使事情更糟。越来越大的火势需要更多的汽油,从而进入了一场注定会导致灾难的循环。
4,作者关于软件任务的进度安排使用了很多年的经验法则:
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试,所有的构件已完成
5,每个团队成员认为自己是争取小红花的学生,而不是构建系统软件产品的人员。为了满足目标,每个人都在局部优化自己的程序,很少会有人停下来,考虑一下对客户的整体影响。
6,我主张在系统设计中,概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路,宁可省略一些不规则的特性和改进,也不提倡独立和无法整合的系统,哪怕它们其实包含着许多很好的设计。
7,架构师必须:
第一,牢记是开发人员承担创造性和发明性的实现责任,所以结构师只能建议,而不能支配;
第二,时刻准备着为所指定的说明建议一种实现的方法,同样准备接受其他任何能达到目标的方法;
第三,对上述的建议保持低调和平静;
第四,准备放弃坚持所作的改进建议;
8,一种普遍倾向是过分地设计第二个系统,向系统添加很多修饰功能和想法,它们曾在第一个系统中被小心谨慎地推迟了。
9,实践是最好的老师,但是,如果不能从中学习,再多的实践也没有用。(Experience is a dear teacher, butfools will learn at no other.)
10,我并不是很同意销售人员所吹捧的“完备信息管理系统”——管理人员只需在计算机上输入查询,显示屏上就会显示出结果。有许多基本原因决定了上述系统是行不通的。一个原因是只有一小部分管理人员的时间——可能只有20%——用来从自己头脑外部获取信息。其他的工作是沟通:倾听、报告、讲授、规劝、讨论、鼓励。
11,不愿意为设计书写文档的原因,不仅仅是由于惰性或者时间压力。相反,设计人员通常不愿意提交尝试性的设计决策,再为它们进行辩解。“通过设计文档化,设计人员将自己暴露在每个人的批评之下,他必须能够为他的每个结果进行辩护。如果团队架构因此受到任何形式的威胁,则没有任何东西会被文档化,除非架构是完全受到保护的。
12,系统软件开发是减少混乱度(减少熵)的过程,所以它本身是处于亚稳态的。软件维护是提高混乱度(增加熵)的过程,即使是最熟练的软件维护工作,也只是放缓了系统退化到非稳态的进程。
13,系统各个组成部分的开发者都会做出一些假设,而这些假设之间的不匹配,是大多数致命和难以察觉的bug的主要来源。
14,(为了使自己能够得到来自手下真实有效的信息),首先老板必须区别行动信息和状态信息。他必须规范自己,不对项目经理可以解决的问题做出反应,并且决不在检查状态报告的时候做安排。
15,培养设计人员:
第一,尽可能早地、有系统地识别顶级的设计人员。最好的通常不是那些最有经验的人员。
第二,为设计人员指派一位职业导师,负责他们技术方面的成长,仔细地为他们规划职业生涯。
第三,为每个方面制订和维护一份职业计划,包括与设计大师的、经过仔细挑选的学习过程、正式的高级教育和以及短期的课程——所有这些都穿插在设计和技术领导能力的培养安排中。- 118 -
第四,为成长中的设计人员提供相互交流和学习的机会。
16,那些想看到完美方案的人,其实在心底里就认为它们以前不存在,以后也不可能出现。- 亚历山大·波普,批判散文
17,创造性活动包括(1)概念性结构的形式规格化,(2)使用现实的介质来实现,(3)在实际的使用中,与用户交互。
18,软件产品易于掌握的特性和不可见性,导致了它的构建人员(特别容易)面临着永恒的需求变更。
19,“管理人员的职责不是要人们去工作,而是是创造工作的可能。”