《程序开发心理学》读书笔记

标题: 《程序开发心理学》读书笔记（一）

上次就说要好好看温伯格的书，今天开始看《程序开发心理学》，在这里做一点点摘录和写一点点感想（蓝色部分），权当是读书笔记吧。

读完序，给我留下最深印象的是译者的序中这么一句：“本人曾经因为侥幸发现其中（指此书）一处小纰漏，得到了温伯格先生寄来的一美元奖励，他对科学的这种严谨而坦率的态度，令人钦佩。”

----张亚勤院士曾经这样评价温伯格先生：他是从个体心理、组织行为和企业文化角度研究软件管理和软件工程的权威和代表人物，他有着程序员、系统事、咨询师、专业作家的多重身份。因而我先前就知道自己开始阅读的将是一位软件业大师的作品，现在又被温伯格先生的高尚人格深深打动，于是心里顿时生出了顶礼膜拜般的感情，我也毫不怀疑自己将从中受益匪浅。

第一章        阅读程序

----这一章的名称是阅读程序。温伯格认为阅读程序是了解程序员编写程序的一个关键步骤。但我认为这一章并没有具体介绍阅读程序的方法，实际上主要介绍了影响程序编写的几个因素，提出了在程序编写的过程可能涉及到的程序员心理原因，为后面的章节埋了伏笔。另一个重要的观点是，将程序开发作为一种人类行为来观察，从这个意义上来说，程序开发也是一种艺术创造的过程，同写作、作画并没有质的差别。是在特定的环境下，特定的程序员在特定的心理状况下的艺术品，其中任何一个因素的变化都可能导致艺术品的结果不同。这解释了为什么将程序开发和心理学结合起来研究的来由，因为毕竟，程序员也是人。

程序开发也是写作的一种形式，他和其他的写作形式没有什么两样。要学习写作，最直接的途径就提笔写作 。

----我坚信这一点。所以我完全明白我现在的编程水平差是平时写程序太少的缘故。

记得有一次看NBA比赛，当雷吉.米勒一次次出手三分手起网破，唐蒙给他的评价是“无它，惟手熟尔”。这一场景使我时时回想起来都倍感振奋，成为我脑海中永恒的经典画面。写程序和写作一样，想写得好，没什么捷径可走。

程序被写成什么样子，取决于众多的因素；一旦我们真的阅读了程序，就会发现无论是否必要，其中这些代码之所以如此编写，有的是由于计算机的局限，有的是由于程序语言的局限，有的是由于程序员的局限，有的是因为历史的偶然，而有的则可能是因为规范。但是，不管究竟是什么原因是最终的软件加入了某段特定的代码，这种原因必然有其基于心理学的一面。这使我们相信，把程序开发作为一项以人为主的活动来加以研究，将会取得丰硕的成果。

----这也使得我相信，温伯格将程序开发和心理学结合起来研究，并不是毫无道理的。

关于上面所说的五个局限

1．  机器的局限 ：比如，如果制造主存储器的成本足够低，中间存储器就根本没有必要存在。但这只是个理想的假设，实际上，我们不得不是用磁盘等存储介质—这将带来大量的程序开发工作。另外，每种设备都有其特定的时钟特性、定址模式以及存储容量。我们发现大量代码的作用，只是为了克服那些我们将可能遇到的硬件配置的不尽完美之处。

2．  语言的局限 ：例如，FORTRAN语言中存在大量的冗余代码，有的是因为DO循环无法逆向计数，有的是因为不允许用表达式作为跌代的增量或上下限，有的是因为数组下标必须从1开始。在其他的许多语言中，同样充斥着对旁枝末节的无聊限制。除非这些限制被去除了，否则我们可能根本不会意识到有这些限制。（温伯格说，这是一个心理学的问题，将会在后面的章节讲到，我也很期待看到后面相关内容，这里先留个悬念）

3．  程序员的限制 ：一是程序员可能不了解程序语言的所有功能，二是程序员可能不知道某些特定的算法，或者不能同时兼顾一个大问题的各个部分，从而有效的避免重复劳动。

----比如我第一次写程序，是一个打印乘法表的程序，不知道用for语句循环，只会直接在屏幕上打数字。这就好比小时候写作文，不知道小心翼翼这个词要比“很小心的样子”这样的描述好得多一样。

4．  历史遗留问题 ：一些代码并没有根据程序语言的最近改进而作修改，这就使得任何一段代码都可能存在历史遗留问题。而且如果某段程序运行很好，那么任何人都不大可能对它进行考察。

5．  规范 ：在几乎所有的程序中，总可以找到一些代码，现在的确已经成为人们所需要的功能。即使能够成功地从程序中剥离出这些核心部分，我们也不应被假象所误导，以至于认为可以在一开始就以该内核为规范。在知之甚少的情况下，程序员很难确定其最终的意图；如果在制定规范时，缺乏对计算机功能的起码了解，据此去写出搞校的代码也是很困难的。规范随着程序和程序员的发展而获得改进，写程序的过程是在特定的计算机硬件上使用特定的程序语言，由特定的程序员在特定的工作环境中，以一系列特定的历史事件为背景进行的，这些事件不仅决定了程序的形式，而且包括代码的功能。

第一章的内容就这些，先写到这里。

 

标题: 《程序开发心理学》读书笔记（二）

第二章  优秀程序的要素

----同第一章类似，这一章仍然没有涉及到心理学的内容。主要介绍了优秀程序的几个要素，按温伯格认为的重要次序如下：是否符合技术规范、是否按日程计划完成、适应性以及效率。重要的观点是，世界上并不存在一个绝对的评判程序的标准，但可以从上述几个方面来对程序进行一定程度的好坏评定。

如果准备把程序开发作为一项以人为主体的行为来研究，我们首先就需要确定一些标准，用来衡量程序的性能。尽管我们对这些问题多少有些概念，但是我们将发现，答案并不象想象的那么简单。道理很简单：程序开发不仅是一项人的行为，而且是一项人的复杂行为。

----温伯格首先认为并不存在一种绝对的标准来评判一个程序的好坏，比如称某个程序的优秀程度为80%，这是不存在的。这恐怕是因为程序有其特定的开发环境、开发人员以及不同的使用环境。然而不幸的是，实际上我们也很难找到一对足够相近的程序，从各个层面来对比他们，因而相对标准也并不实用。从几个要素来评判程序的好坏倒还比较可信，毕竟优秀程序必须是正确的 ，然后才考虑是否按日程完成 、适应性以及效率 的问题。

优秀程序的要素之一：技术规范

如果程序根本无法正常运转，对其效率、适应性以及生产成本的评估就毫无意义。无论如何，我们需要务实一些，需要承认：也许根本没有哪个完美的程序曾经被写出来过。每一个真正大型和重要的程序“都必然包含很多个纰漏”。所以，程序符合其事先制订的技术规范（可行性）的程度不尽相同，在对程序进行评估时，必须考虑到其不完美的一面。

优秀程序要素之二：日程计划

即使不考虑符合技术规范的问题，效率的问题仍然不是最重要的。有时候程序推迟发布会带来重大损失。一旦开发计划没有按时完成，总会有一大堆令人烦恼的后果。实际上，一般的开发主管宁可先做12个月的计划，然后在12个月内完成，也不愿计划为6个月，但却花费9个月。

----书中提到，这一点在心理学方面大有研究的余地。目前的有关研究只考虑时间的平均值，温伯格提到应该衡量开发时间的方差。期待在后面的章节看到此讨论。

优秀程序要素之三：适应性

温伯格认为，程序的适应性比效率重要，因此先讨论适应性。多数程序在其生命期内都会被修改，但实际上，很少有哪位原作者会考虑到可能的后续修改。文档会在一定程度上使程序易于修改，因而文档的质量也应该在很大程度上决定到对程序的评分。

适应性不是没有代价的。Fisher基本定理告诉我们：一个系统对某一特定环境的适应性越强，他适应新环境的能力也就越弱。为了强调程序的效率，我们往往追求“紧密式”的代码，而如果未来要对这些代码进行修改，那将会非常棘手。

----效率和适应性犹如鱼和熊掌不可兼得。因而往往只能取其一，至少这比哪个都没有强。

优秀程序要素之四：效率

终于讲到效率了，不过衡量程序的真正效率，并不像乍看起来那么简单。

如果我们首要关心的是程序运行的效率，那么第一步工作就应该是检查一下，看看哪些方面的规范改变以后，可以提高计算机的效率—此时，我们并不顾及用户使用是否方便。诚然我们可以把一些交叉结算的工作交给人来汇总，但是通过这种方式来节省计算机运行时间，却可能使人工花费更多的时间。

在多机、多道程序的环境中测量效率的困难比单机、单任务的环境要困难得多 。用户所希望的并非程序的平均执行时间最小化，而是其标准偏差的最小化，即程序的运行稳定性最佳。

----最近在看Jeffrey Richer的一本<Applied Microsoft .NET framework>，感觉他对效率非常重视。几乎每讲一个内容，都会提到如何提高效率。比如，值类型的装箱拆箱，他带领我们深入学习其中的原理，查看IL代码来分析程序中装箱拆箱的次数，然后改进程序将他们降至最低以使程序达到效率的最优。而温伯格将程序的效率排在优秀程序要素的第四位，他们俩的观点使我们能够对效率保持一个比较客观的认识，不要走向任何一个极端。

 

《程序开发心理学》读书笔记（三）

第三章 如何研究程序设计

 

在 前两章里，我们已经将程序开发看成一项以人为主体的行为来加以研究，但由于程序开发是一项异常复杂的行为，现有的有关人类行为的科学结论并无法完全适用， 因此我们必须创造一些新的方法来研究程序开发行为。本章介绍了几种研究人类行为通常使用的方法，并一一指出这些方法不完全适合程序开发行为研究的原因。

 

1 ．自省

例如，在使用 PL/I 语言的时候，有些程序员无法处理五层以上括号的嵌套。通过对这种现象的自省，我们还不足以得到下面更具一般性的规律：人脑无法处理五层以上的括号。

 

就程序开发心理学而言，每个命题都有可能成为一条“定律”。仅仅凭借一个关于自省的例子，还远不足以作为支持其成为定律的证据。为了获得一条“定律”，我们必须对其原理进行研究，以便对其应用范围做一界定 ---- 因为，每条定律都会受到这种限制。确实，通常对这种限定的了解，较之对定律本身的了解更重要；而只有对大量的案例进行调查分析之后，才有可能明确这些限定。

 

2 ．观察

我们要观察人们到底在做什么，而不是他们自认为在做什么。

 

需要注意的问题一：观察只能告诉我们人们确实在做或做过的事，而不一定就是他们能做的全部。因此，即使在对几百名程序员进行观察后，没有发现任何人使用超过五层的括号，我们也不能据此得到“结论”：没有人能使用六层括号。

 

需要注意的问题二：要搞清楚我们究竟要观察什么。一旦我们观察到一例六层括号，我们还需要对促成或者妨碍这一案例发生的环境条件进行界定。

 

需要注意的问题三：观察者与被观察者之间的干涉现象 — “霍桑效应”。此效应得名于西部电气公司所属的霍桑工厂。 1924~1927 在此进行的一项有关工业心理学的实验以失败告终。在实验过程中，无论工作条件如何变化，生产效率始终一路攀升。实验者最后意识到，这是因为工人们受到关注内心油然而生的自豪感产生的效应。解决的办法：“参与式观察”，观察者融入到被观察者的文化氛围中而不会被察觉。

 

在有关计算机的研究中，我们可以使用计算机对程序开发进行不为人察觉的观察。但是计算机产生的数据量巨大，给研究人员分析提取有效数据带来障碍。而且计算机用于记录日志的计时分辨率通常为一秒，但在许多心理学研究中，我们需要精细到毫秒的级别。

 

3 ．实验
为了降低数据量太大带来的处理的代价，同时增加与我们感兴趣的行为有关的信息却增加了，我们可以设计一些实验。

实验带来的限制：

I.        由于实验经过了高度的精炼，以至于可能遗漏了我们最感兴趣的数据。

II.       实验的特殊条件会限制被试的行为，以至于我们在也无法观察到在自然条件下所观察到的结果。

  a)        选择实验对象时，过分依赖于实习生

  b)        强调程序开发是个体行为，忽略群体效应的研究

个体式的研究方式，必然会强行将单个个体从其正常的工作环境中剥离出来。如果在研究青蛙游泳的行为时，有人将他们的腿割下来放到水中，然后试图观察到腿会游泳，那么一定会让人贻笑大方。然而那种强迫程序员在工作时与外界隔绝的做法，与割青蛙腿有什么区别呢？事实上，很多人都习惯于这样一种推理的逻辑：既然青蛙是凭借腿来游泳的，为什么还要去研究其它部分，把一件原本“显而易见的”事情搞得如此“复杂”呢？

---- 很精彩的一段比喻，不过我认为对程序个体行为的研究不仅非常重要，也是研究群体效应的基础。

4 ．心理学测量
我们可能用“从事程序开发时间的年头”来衡量“程序开发经验”的问题。但在有关人类行为的观察和实验中，可以测量的指标很多，我们不得不在林林总总的指标中搜索，期望者通过某一个或少数几个，就能获得一些领悟。在这个过程中，任何蛛丝马迹都不能放过，也不能将任何看起来荒谬的观点排除在外。

就目前而言，在程序开发心理学方面将要进行的大多数工作，不得不先去“寻找问题本身”，我们需要首先弄清楚哪些是可以测量的以及那些是值得测量的。与其说我们在研究被观测对象，不如说我们在研究测量的方法本身。

5 ．利用行为科学中的数据
在行为科学中以前所积累的经验有能够为我所用之处，但这些理论所依据的前提条件，与程序开发过程的实际情况相去甚远。

我们可以从众多领域中获得有益的启发，通过结构中存在的缺陷，将有助于我们确定可以向哪些领域寻求帮助。但是，我们千万不要把这种结果太当回事，这只不过是一个提供方便的工具而已。

 

第五章 程序开发团队

团队的组建

一支程序开发团队之所以成立，是为了承担并完成某项由任何个人都无法独自完成的任务。这种要求，不仅仅与待完成工作的技术要求相关，同时也与可以找到来参加该项工作的人员的能力以及允许完成任务的时间长短有关。

个 人能力与日程进度二者之间存在着互补的对应关系。在开发日程与工作结构之间同样存在着一种重要的关系，许多程序开发任务之所以没有在计划的日程内按时完 成，其原因都可以追溯到最初的日程规划以及开发路线上，最初的这些计划总是一厢情愿地把开发过程中的所有条件都设想为最好。但是如果企图对各种可能出现的 问题都在事先面面俱到地做好准备，我们就不得不需要在团队中设置很多附属人员。另外，如果整个任务必须通过划分再分配给一批人，那么需要进行的协调工作量 也会增加。

程序开发团队的规模和组成似乎都符合这样一条基本规律---如果希望通过最小的代价获得最佳的开发效果，你必须找到尽可能出色的程序员，并且给他们以尽可能长的时间。

在 程序开发的过程中，开发团队中各成员的地位，通常在很大程度上取决于其他人对其个人能力的了解程度。在被分配各某项特定工作之后，某个成员也可能相应地获 得或者丧失一些地位，负责何种开发工作，将决定不同成员的身份地位。为了组织好一个团队，我们必须在推行过程中，在各成员的敏感性格之间如履薄冰般周旋。

目标的设定和认同

社会心理学家们已经证实：只要有一名成员与集体的目标不一致，那么该集体的整体水平就将受到影响。这种影响不仅来自于这个成员本身，而且也来自于集体内部其他成员的绩效下降。

为 了实现在集体目标上真正的意见一致，最好的办法莫过于让开发组自己来确定其目标。如果开发团队的任务不是开发一个特定的系统，而是为其他程序开发组提供服 务和支持，那么这种目标不明确的问题就会更加突出，必须经常提醒他们注意自己的贡献，否则，他们的工作就会越来越具体，而且没有什么产出。

当 然，最好的情况时，一支开发团队只有一项明确定义的任务。然而这个世界上的事情很少会这样简单。即使其任务只是完成一个程序，也有可能在诸如速度、空间或 者时间进度等方面存在冲突 ，人们对这些方面的重视程度可能不同。如果没有明确地告诉每个成员应该对各个方面强调到何种地步，那么他们各自的工作目标就很有 可能相互矛盾，其效果将互相抵消。

如果不同成员对团队的目标理解不一致，而且这些不同观点之间的差异几乎无法察觉时，这些分歧的消除就显 得极为迫切。如果在团队中持续出现这种争论，那么这就是一个确定的信号，它显示出团队内部存在着更深层次的冲突--比如可能是为了争夺团队的领导权--所 以绝对不能因为其貌似琐碎就掉以轻心。

团队的领导者及其领导方法

程序员们一般会更加注重创造性的工作以及专业能力 ，在他们所从事的工作范围内，他们会对那些被自己认定为很出色的人更加器重。与那些世界级的口若悬河的推销商们相比，作为一名语调温和的程序开发奇才，将可以更加轻松地对程序员们进行领导 。

民 主化集体得以运转的一个重要前提，并不在于所有成员掌握同等的领导权力，而是在团队内部真实的集体生活之上（而不是来自外界的强加），确定领导权力的分 配 。一支真正的民主化团队，总是特别能适应环境的改变，所以面对难以预料的困难，这种团队很容易成为一个值得信赖的开发团队。

目光短浅、 难以依靠的团队领导者可能会认为，博得管理层欢心的最好方法，就是无论他们要求什么都满口答应。但，管理层需要的不只是诺言，更重要的是恪守诺言。作为一 名被指派的团队领导者，如果他的手下无法完成某项任务，但他的上级却强迫他接受这项任务，那么他所能采取的最好方法，就是坚决予以抵制。如果他本身是位优 秀的程序员，那么他在这场斗争中就拥有双重的砝码--因为他对自己的判断更加充满自信，同时他也很清楚，即使他丢失了这份领导者的职位，也不至于沦落到讨 饭的地步。只有随时准备下台的领导者，才有可能获得成功。

团队中可能出现的危机

把团队的工作划分为两种类型分别对待：以完成团队任务为直接目标的工作，以及在面临危机时以维护团队的有效运行为直接目标的工作。

在开发团队中，成员们会倾向于推选两名互补的领导者：一位是任务权威，另一位是协调工作的权威 。

民主式团队更有能力经受住成员离开的影响，但这样的团队通常很难接受新成员。从外界看，一个民主式的团队的外表显得更加冷漠和不友好，而一个集权式的团队则会对外来的加入者表现出异乎寻常的热情和友好--这似乎是一个悖论。(hennry:?)

团队中如果出现某个成员没有能力胜任其承担的那部分工作，民主式团队最可能的办法就是逐渐的该成员不能胜任的工作转移给其他成员。如果某个成员能力很强，但是却与周围的人合不来，那么这个问题就会比某个成员能力极差的情况更为严重。(hennry:?)