自考英语国家概况:《程序开发心理学》读书笔记

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

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

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

第一章        阅读程序

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

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

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

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

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

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

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

　　第二章  优秀程序的要素

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

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

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

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

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

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

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

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

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

　　第三章 如何研究程序设计

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

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

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

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

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

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

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

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

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

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

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

第四章 程序开发组

----本章主要讨论了程序开发组内部关系以及程序开发组和外部环境之间的关系。强调了程序开发组内部交流的重要性、互查代码的必要性、要求主管给与程序开发组充分的交流场所、鼓励团队合作精神、希望主管不要盲目拆散高效的团队。

正式与非正式机构

　　主管们很喜欢玩组织结构图的游戏，但是如果将程序员之间的交流，严格限制为图中那狭窄而笔直的线条，那么程序开发将不会取得多大的成果。人与人之间的交流沟通既不是那么狭窄，也不是那么直截了当，更不是用一张组织结构图就能表示出来的。

　　工程项目中的非正式结构在很大程度上要取决于其工作结构，因此或多或少都会与组织结构图相符；而具体符合到什么程度，则取决于该项目的组织化程度。无论其正式结构如何，也总会有一些相伴而生的非正式结构来进行更正和补充。有时候，如果当权者非常明智，他们可能会把出自非正式结构的新方法以正式的形式固定下来。

　　非正规的机制到处存在，而且如果你还没有真正搞清楚其规律，就企图改变什么，那将会十分危险----你可能会把有些操作系统搞得一团糟。

自然环境与社会结构

　　程序开发过程中的社会交流方式，会转而影响到正在进行中的开发工作。

　　只要在领取计算机输出的地方，安排相邻的一间屋子作为公共休息室，那么人与人之间就会在信息交流的过程中，得到很多有益的东西。但是，个性化的邮件发送系统却会使程序员与这种交流隔离得更远；而通过终端系统实现的远程任务进入与退出，则会进一步加剧这种隔离。

　　----难怪GTEC有break room啊，总算理解了除了提供饮料和休息场所之外更重要的交流功能。

错误与唯我独尊

　　如果一名程序员真的把自己编写的程序视为其自我的延伸，那么他就绝对不会希望在他的程序中发现任何错误。不仅如此，他还会尽力证明，自己的程序都是正确的---甚至于，即使他发现了重大的错误，他也会睁一只眼闭一只眼，对错误视而不见。

无私式程序开发

　　---就是code review，没想到温伯格25年前就提到了

建立与维护程序开发的环境

　　在一个计算中心里同样会建立起一个整体的社会环境，对于无私式程序开发方式，这种环境要么积极提倡，要么一味抵制。