《程序开发心理学（银年纪念版）》 试读笔记及感悟

        本书的题目非常吸引人，第一次见到“程序开发心理学”，就被它吸引了。内容简介中讲述：作者“前瞻性地提出了将程序开发作为一种人类行为来考察的观点”，这非常有创新性。


一、一些好的内容及其个人感悟

        2. 优秀程序的要素

        （1）“如果准备把程序开发作为一项以人为主体的行为来研究，我们首先就需要确定一些标准，用来衡量程序的性能。换而言之，在谈到某位程序员比另一位更高明，或者某个程序比另一个程序更优秀时，我们需要知道所指的是什么。”

        作者的思路非常清晰，眼光非常敏锐。向其学习。


        （2）“在对程序的所有要求中，首先是要求它必须正确。换而言之，对于任何一种可能的输入，它都应该给出正确的输出。当我们说一个程序“可行”时，指的就是这个意思。我们经常听到“可行的程序总比不可行的要好”，确实如此。”

        程序的“可行性”是第一位的。如果都不可行，那怎么谈其他呢？


        （3）“程序开发中经常遇到的一个问题是要符合开发的日程计划，推迟完成的程序常常没有意义。最起码地说，我们不得不比较一下，到底是一个可能（在未来）完成的高效率程序带来的潜在节省更大，还是没有一个程序的损失大。有这样一个值得注意的例子：据一家公司估计，其委托另一家软件公司正在开发的线性规划软件，每个月可以为其石油炼制的工序节省100万美元。这样，即使是只比开发计划推迟一个月完成该软件，该软件也需要在没有任何其他费用的前提下运行10年，才能挽回这一个月的损失。”

        这段话提醒了我。我们小团队在开发的时候，容易低效和推迟进度，这也是“拖延症”的体现。所以还是要严格按照日程计划来完成。


        （4）“如果强调的是程序的效率，那么我们往往去追求‘紧密式’的代码，而如果在未来要对这些代码进行修改，那将会非常棘手。如果使用的是更高层的语言，那么为了使程序更高效，我们往往需要深入到机器语言层。这种做法至少抵消了原本用更高级语言编程的一个好处——在不同机器之间的可移植性。其实际效果是，我们将被局限于特定的某台计算机或特定的某个实现——基于这种实际的感受，我们不得不承认这难以令人满意。
        但是那些叫嚣着要追求效率的管理者，正在那些在得知修改代码的沉重代价后，为此而伤透脑筋的人。相反，那些过于强调程序的通用性和易于修改性的主管们，在发现自己的程序运行起来又慢又费空间时，往往又会变得怨天尤人。对于这些问题，我们必须保持一种成熟的心态——要知道，无论是心理学还是魔法，都无法帮助我们同时实现这两个相互矛盾的目标。要求程序同时具有高效率和适应性，正如企盼找到一位美丽而谦恭的妻子。尽管美貌与谦逊同时集于一身并非不可能，但通常我们还是必须在二者之间做取舍。至少，具备一种优点，要比哪种都没有更强。”

        追求程序运行效率，但未来难以修改，修改代价沉重，可移植性差。<——>强调程序通用性和易于修改性，但运行起来又慢又费空间。“高效率”和“适应性”之间，必须要做取舍。


        （5）作为一个好的程序，必须具备哪些要素呢？我们必须考虑到不同程序各自的优点，同时还要兼顾其所在的环境。其中一些重要因素有：

            1. 该程序是否符合功能需求？或者更确切地说，它在多大程度上满足功能需求？

            2. 该程序的开发是否按照计划完成？根据一些特定的方法，我们能够预测出的项目计划可能的偏差幅度会有多大？

            3. 当条件改变时，该程序是否可能修改？修改的成本有多大？

            4. 程序的效率如何？这里的效率是指什么？为了补偿某一方面的低效率，我们是否会牺牲另一方面的高效率？

        这一点可以作为以后判断程序优劣的一个参考。


        （6）许多主管似乎依然希望得到所有东西，却不知道更重要的应该是通过明智的权衡，得到自己可能得到的最佳成果。

        这个涉及到管理方法和心理学。确实，当技术部门的主管，可能会想得到很多成果，但是要把握好“度”，讲究策略，才是最重要的。



        5. 程序开发团队


        （1）一个大致的规律是：由三名程序员组成的团队，只能够完成一名能力相当的程序员所能够完成的工作量的两倍。另外，如果每个开发组分别由三名程序员组成，那么基于同样的原因，三个这样的开发组协作完成的工作量，将是单个开发组的两倍，或者说是单个程序员所能够完成的工作量的四倍。因此，假设某个工程单个程序员需要八个月才能完成，如果我们希望四个月内得到结果，那么我们就需要派上三名程序员；而如果我们希望在两个月内完成工作，就必须分配出九名程序员。

        需要注意的是，如果程序员的能力大体相当，那么很可能两个月就是完成该任务所需要的最少时间——因此如果考虑到把程序员们组织、协调起来所花费的时间，我们就有充分的理由怀疑，在短于两个月的时间内，即使是多达九名程序员，他们能做得出什么真正有用的东西。如果我们的确需要更早地得到最终的程序，我们就必须雇用水平更高的程序员来完成任务。

        这个统计数据让我吃惊，这样的分析也让我受益颇多。我前段时间组织一个三人小团队在一个月内完成一个非常有创意的项目，但是人手太少，而初期设想的太美好，因此最终也没有能够完成到满意。看到这段话，深有感触。


        （2）尽管我们可以预计到，那些（相对而言）缺乏经验的程序员对当前的任务贡献甚微，但是我们还是应该在开发团队中安排一到两名这样的程序员。一旦开发团队中有了这样的成员，团队的目标就变得更加多样化了——既有开发本身，也兼有培训——同时工作的组织方式也会受到影响。

        这一点真棒！我原来一直以为团队成员，越是个个经验丰富，对团队越好。原来安排实习生，还有这样的好处！


        （3）在程序开发的过程中，开发团队中各成员的地位，通常在很大程度上取决于其他人对其个人能力的了解程度。如果程序能够（在团队中自由）流通，供程序员们相互评判、指正，那么“精英们”就能够更快地脱颖而出。反过来，如果团队成员就像苦行僧一样，隐居在各自的小隔间里独自工作，那么其在开发团队中的威望，就会更多地取决于其在此前建立起来的声誉——至少在大家意识到这种评价的错误之前的确如此，然而等到那时往往已经是无可救药了。

        开发团队，最重要的还是开发能力。开发能力强的人，就会脱颖而出，而且越做越好。所以，作为一名程序员，应该大力提升自身的开发能力才是长久之计。


        （4）可以设想在一个典型的开发团队中，如果其主管手提长鞭高高在上，就像一位正在率领其分队进攻敌人机枪阵地的中尉一样发号施令，那么团队的成员会如何做出反应。不必去想象那些更为温和一点的独裁式“领导”，因为有许多无知的执行官，正在使用这种方法对待手下的程序员。

        对开发小组的领导者而言，非常有借鉴意义。对于致力于从事领导岗位的人而言，这一点早点知道为好。


        （5）至于哪些因素才是导致集体中的成员对工作感到满意的关键，社会学家在经过研究之后，划分出了4个主要方面。
        1. 物质的奖励与机会。
        2. 工作本身所具有的挑战性及其趣味性。
        3. 其所隶属的更大单位的总体条件，比如雇员的福利、工作条件，以及该单位在同类单位中的相对低位。
        4. 主管与领导者的能力。

        经常在被面试的时候，被问到：“你更看重的是公司的什么？”然后自己脑海里也不是特别清楚地能说出到底什么才是重要的。这段话是一个参考，当然更重要的，还是要自身有能力，然后还很踏实靠谱。


        （6）就社会科学家对“领导能力”一词的使用而言，其含义应该是“对他人的影响能力”。程序员一般会更加注重创造性的工作及专业能力，在他们所从事的工作范围内，他们会对那些被自己认定为很出色的人更加器重。这样，与那些世界级的口若悬河的推销商们相比，作为一名语调温和的程序开发奇才，将可以更加轻松地对程序员们进行领导（或影响）。当一名根本没有编过程序的领导者被指定负责某个开发团队时，除非该领导者明确地或者含蓄地承认自己在技术问题上的能力欠缺，否则注定会有麻烦发生。即便是那些曾经当过程序员的人，只要他后来有相当长的时间脱离了这个行当，如果他依然企图去与团队中的其他成员在程序开发才能方面一比高低，那么情况就糟糕透顶了。对于那些公开承认自己在程序开发方面经验欠缺的人，他的团队成员还有可能会尊重他，但是如果由欧人企图掩盖自己在这些方面的无知，那么等到他迟早露馅的时候，就会招致程序员们的无情嘲弄。

        这一点感触很深。因为我的前任领导就是这里面描述的失败的管理者，而我曾管理一个小团队，当时也是这样的人。因此当时在管理的时候困难重重。当现在自己的技术学得还不错的时候，回顾当时的经历，觉得简直是噩梦。幸好一切还来得及。

        还有一点感触就是：参加面试的同学，一定要诚实，不要吹嘘自己的开发能力。如果面试官面试过程中发现你真实水平与自己简历所写或者是自己所吹捧的有差距，那么一般都是直接拒绝。


        （7）团队的领导者需要学习的东西包括：
        1. 无论主管们怎样地强调诺言，他们真正关心的只是结果。
        2. 如果希望得到的结果与在整个团队的参与下所确定的工作目标一致，那么这一目标就会非常轻易地实现。
        只要牢记这些事实，被指派的团队领导者就可能克服由于被指派而造成的困难，进而成为一位独立自主的领导者。他也会把“指手画脚、发号施令的能力”转变为“领导能力”。

        这些是领导者必须要把握的原则，这样才有可能能领导好。


        （8）作为一名被指派的团队领导者，如果他的手下无法完成某项任务，但是他的上级却强迫他接受这项任务，那么他所能采取的最好方法，就是坚决予以抵制。自然地，他必须确保还能接收到新的信息，这些信息可能改变他的处境——比如当上级管理层对他承诺，将给他分配更多的人力和更优惠的上机时间。但是，他必须为自己评估一下，到底这些承诺兑现的可能性有多大，因为一旦他向自己的上级做出了承诺，那么他们就很可能把他从他们那里争取到的条件扔到九霄云外。但是当管理层转而讨论除资源或者任务定义之外的企图方面时，他的判断绝对不能有丝毫的动摇。最为典型的承诺是，在事成之后将给予他特殊的奖励，但是他必须保持头脑清醒，千万不要被奖励的诱惑冲昏了头脑，而不考虑得到它的可能性到底有多大。
        当上级管理层提出奖励的许诺时，团队领导者除了一味地抵制之外，别无良方。他必须乐于借助自己的专业判断力量，来支撑自己作为一位被指派的领导者的地位。如果他本身是位优秀的程序员，那么他在这场斗争中就拥有双重的筹码——因为他对自己的判断更加充满自信，同时他也很清楚，即使他丢失了这份领导者的职位，也不至于沦落到讨饭的地步。然而，要是他对自己的专业精通程度有所怀疑，那么面对这种暗藏威胁的、微不足道的承诺，他很容易就会上当受骗。

        我曾经作为一名团队领导者，或者被称为“夹生饭”，就被上级欺骗过。他给我很多口头承诺，最后很多都没有实现，而我还真信了。这一条让我顿时悟到很多。


        （9）领导能力方面的一个悖论非常简单：只有随时准备下台的领导者，才有可能获得成功。



二、对这本书试读章节的看法

        本书试读章节选择的很好，从试读章节都能学到这么多东西，更加勾起了想看完整本书的欲望。

        在此，提出两个小建议：

        （1）PDF第21页（本书第16页），提及“如果更仔细地分析图1-1”，以及“图1-1中的程序虽然不长，但……”但是，试读章节中却没有图1-1出现，这样会造成阅读时候的疑惑。

        建议：以后的试读章节，内容选取更完善一点。引用到别的图片什么的，建议也整合进来。

        （2）试读章节的PDF文件，既无法将文字复制出来，也无法转换为别的格式。是否是为了安全性考虑，做了这些限制？

        建议：将PDF设置为可直接复制其文字，这样的话，做笔记会更方便一些。


        总体，从本书试读章节中学到非常多的东西。感谢有这样的活动！