《程序開發心理學》讀書筆記
《程序開發心理學》主要為我們介紹了程序開發的過程以及設計過程中的思維方式�！冻绦蜷_發心理學》讀書筆記是小編想跟大家分享的，歡迎大家瀏覽。
作為一本與計算機有關的圖書，在1971年初次出版之后，能夠經過45年仍然保持活力，不能不說它是一本神奇的書。“本書開創了一個新的領域，即將程序開發作為一種人類行為來看待，而不僅僅是與硬件、軟件相關。”
45年來，雖然計算機軟硬件技術在飛速地更新換代，但人類作為程序開發的主體，人類的心理狀態和行為模式與45年前并沒有太大的不同。因此本書作者溫伯格先生45年前的諸多真知灼見如今依然適用。又由于20年前出版銀年紀念版的時候，作者沒有直接修改原書，而是在保持原貌的基礎上增加評注，讓我們可以更真切地看到在開始的25年間，軟硬件技術進步和管理知識積累給程序開發的各方面帶來的或多或少的影響。
我猜有兩類人大概會喜歡這本書：
第一類是有一些開發經歷，喜歡觀察、思考并愿意嘗試改善開發過程的程序員;
第二類是程序員出身轉而從事開發管理工作，同樣喜歡觀察、思考并愿意不斷嘗試對開發過程做出改善的技術主管。
此外，我非常希望其他管理層的主管們也能來讀一讀這本書，對軟件開發的過程及組織能夠有更多的了解，不過書里吐槽管理層的地方有點兒多，只怕他們就算勉強來讀了也不見得喜歡。
另外在序言中，溫伯格先生提醒讀者：
讀者的責任是要根據自己的經驗與需求，對書中的所有觀點進行權衡取舍。... ... 我不希望讀者在閱讀過程中貿然接受某種觀點，因為這種讀書的態度正是我們應該努力戒除的。本書中提供的素材只是讀者在自己思想形成的過程中需要消化、吸收的食物，而不應該是個人思想的簡單替代品。
這個要求其實適用于讀任何書。
本書從 1、作為人類行為的程序開發;2、作為社會行為的程序開發;3、作為個人行為的程序開發;4、程序開發工具 四個方面進行了闡述。
第一篇
作為人類行為的程序開發
本篇前兩章閱讀程序和優秀程序的要素嘗試將程序開發看成一項以人為主體的行為加以研究，并論述了進行這種研究的可行性和必要性，第三章如何研究程序設計則從人類行為學和心理學研究方法的角度進一步討論了對程序開發進行研究的可行性。
(作為一名程序員，閱讀本書的樂趣與收獲更多來自溫伯格先生隨意揮灑的各種經驗之談。每章結尾的小結、思考題和本章評注，也是值得多花費些時間和精力的部分。)
第一章 閱讀程序
程序被編寫成什么樣子，取決于眾多的因素。有的是由于計算機的局限，有的是由于程序語言的局限，有的是由于程序員的局限，有的是因為歷史的偶然，而有的則可能是因為規范。
思考題：
請主管回答
如果你是一線主管，你是否有能力閱讀你手下的程序員所編寫的程序?或者，就閱讀程序的能力而言，你是否與“老一輩”的計算機和語言一同落伍了?如果你有這個能力，你真的會去閱讀程序嗎?如果此前你不閱讀程序，為什么現在不嘗試一下，看看會發現什么?
如果你是高層主管，你手下的一線主管們是否有能力閱讀他們手下的程序員所編寫的程序?你能肯定嗎?向程序員了解一下，然后重新回答這個問題。然后查明一線主管是否真的閱讀程序，即使他們有這個能力。我們的調查顯示，由于各種原因，九成的一線主管不閱讀程序。你是否認為，如果不經常閱讀程序員的程序，一線主管能知道程序員的能力如何，工作是否出色嗎?
請程序員回答
你上次閱讀別人的代碼是在什么時候?為什么經過了這么長的時間?最近一次有人閱讀你的程序并且與你討論，是在什么時候?這個人是你的主管嗎?
到程序庫或者向你的好友借一份程序。試著分析并找出其中各段代碼存在的原因，看看是否屬于本文中介紹的某種情況。通過這個練習，你有什么收獲?
找出你至少一個月之前親自編寫的一個程序，參照第2題的方式進行分析。從這個練習中，你又有什么收獲?
除了回答問題，我們還能從思考題中看到什么呢?哪些作者提出的問題經過這四十多年已經被很好的解決了?哪些問題目前仍然繼續存在呢?哪些問題在良好管理的團隊里已經不再是問題，而在管理不善的團隊中仍然存在呢?
本章評注：
在軟件維護的過程中被閱讀得最多的代碼，往往并非是最好的代碼。也許正因為如此，這部分代碼才最需要維護。對于根本區分不出代碼優劣的那些用戶來說，閱讀程序的確不會有什么幫助。25年來，這些問題始終沒有改變。
但是，開發人員把他們的工作提交給別人審閱，或者希望通過審閱他人的工作來提高水平時，為什么會如此之難呢?令人奇怪的是，高明的程序員善于通過排演和審查過程來發現有價值的東西，而那些自以為是的人卻不是這樣。正因為如此，和司空見慣的情況一樣，高手越來越出色，差勁的越差。
45年之后，情況依舊。
第二章 優秀程序的要素
那些叫囂著要追求效率的管理者，正是那些在得知修改代碼的沉重代價后，為此而傷透腦筋的人。相反，那些過于強調程序的通用性和易于修改性的主管們，在發現自己的程序運行起來又慢又費空間時，往往又會變得怨天尤人。對于這些問題，我們必須保持一種成熟的心態——要知道，無論是心理學還是魔法，都無法幫助我們同時實現這兩個相互矛盾的目標。通常我們必須在二者之間做取舍。
在溫伯格先生寫作本書的45年前，效率主要指程序在計算機中的運行效率，在硬件性能已經翻天覆地的今天，把“效率”這個詞理解為軟件的開發效率，這段話同樣成立。
作為一個好程序，必須具備哪些要素呢?我們必須考察到不同程序各自的優點，同時還要兼顧其所在的環境。其中一些重要的因素有：
該程序是否符合功能要求?或置更確切地說，它在多大程度上滿足功能要求?
該程序的開發是否按照計劃完成?根據一些特定的方法，我們能夠預測出的項目計劃可能的偏差幅度會有多大?
當條件改變時，該程序是否可能修改?修改的成本有多大?
程序的效率如何?這里的效率是指什么?為了補償某一個方面的低效率，我們是否會犧牲另一方面的高效率?
思考題：
請主管回答：
你根據什么標準來確定應該獎勵哪個程序員?在你的標準中，是否存在互相矛盾的現象(比如，強調程序的效率，同時又要求程序具有通用性)?你會很明確地告訴程序員，自己希望在他們的程序中找到什么嗎?或者說，你是否只是告訴他們，你希望程序很快、很小、整潔、易于修改、錯誤很少，并且能在一周內完成?
在你的公司中，制定開發進度表的重要程度如何?你是否認為“失之毫厘、謬以千里”?或者你是否認為，在獎勵程序員時應該更加看重穩定性，而不是偶然的一次歪打正著?即使一個計劃不可靠，只要它是完成進度的唯一希望(盡管可能根本無法完成該程序)，程序員還是會采用它——你知道這是為什么嗎?
請程序員回答:
在開始進行某個項目時，你的腦子里是否已經有了一些明確的準則?在確立這些準則時，你根據的是不是自己對于重要性的認識?或者，是依照上級主管的看法?在項目的進行過程中，這些準則有無更改?或者，你是否有某種辦法，來確保其不被動搖?
在編寫程序時，你曾經有多少次想到過它在未來可能被別人修改?反過來，在修改別人的程序時，你又曾經咒罵過幾回?
你是否曾經因為追求"性能"而延誤了工作進度?反過來，是否曾經因為要在規定時間完成，而沒有做到盡善盡美?
第三章 如何研究程序設計
最優秀的程序員同時也是那些最善于自省的。如果他們發現做錯了什么，他們會對導致這個結果的思維過程(或物理過程)進行檢討，然后，他們會采取一些相應的措施，對這個過程進行調整。這種被稱為“根源分析”的方法，正是人們希望從我這里獲得的，同時也是我希望讓更多企業掌握的——然而不幸的是，這種方法還沒有得到很多人的青睞。更多的人仍然喜歡使用“過失追究分析”的方法，這種方法的效果恰恰相反，它會誘導人們把引發問題的根源隱藏起來。
管理心理學中的一條基本原則：關注下屬工作的主管，將會取得更好的成績。
許多主管都希望他們手下的程序員像一個個代碼模塊似的工作，那些曾經做過程序員的主管們更是如此。這些主管認為，每個部下猶如一個小黑盒，只要輸入要求，工作結果就會源源不斷地輸出;根本無需任何觀察，更不用說相互之間的交流溝通了。很多負責軟件開發的主管，就是不愿意與下屬并肩工作——這里最主要的原因就是，他們從未接受過任何有關的培訓，以至于他們根本不了解具體工作應該如何著手。
第二篇
作為社會行為的程序開發
本篇主要從社會行為角度對程序開發進行研究，溫伯格先生把程序員集體分成三種類型：程序開發組、程序開發團隊和程序開發項目，并用三章的篇幅來依次討論。
我理解，這里的程序開發組指的是一種自發形成的帶有互助性質的最小型的松散組織，它有可能跟正式的組織結構重合(最理想狀態，可以極大提高整個組織的開發效率和產品質量)，但更多情況下會是一種非正式的結構。小組成員有可能是同事或者前同事、也可能是技術討論組中正在進行類似的開發工作的網友，而后一種情況也有可能通過換工作轉變成前一種情況。成員們樂于把工作和學習中碰到的問題拿出來互相討論，互相幫助查找問題，取長補短，相互學習，共同進步。技術主管應該致力于把自己領導的團隊變成一個這樣的開發組。
程序開發團隊則是一個正式的組織結構，程序員們被組織到一起來完成一項必須多人協作才能完成的任務。
程序開發項目是進一步擴大的組織，它由多個團隊組成，一起完成一項復雜的、可分割的大型項目。隨著組織的`擴大，程序開發項目主管會遇到更多的組織管理問題，甚至一些社會性問題。
第四章 程序開發組
為提高開發的效率與質量，程序員需要避免唯我獨尊式的心理，克服認知失調。溫伯格先生提出了“無私式程序開發”。
馮·諾伊曼很早就意識到，他在檢查自己工作方面，確實能力不夠，他也許是能夠認識到這一點的第一位程序員。那些與他相識的人們回憶說，馮·諾伊曼總是跟別人講自己是多么蹩腳的程序員，并且不厭其煩地請別人閱讀他的程序，期望發現其中的錯誤與紕漏之處。然而在今天人們的心目中，馮·諾伊曼一定是位無與倫比的計算天才——他渾身上下每個毛孔都應該是完美無缺的。當然，馮·諾伊曼的天才絲毫不容懷疑。然而他對自己作為一個人所具有的缺陷非常清楚，他的這種自知之明，也使他遠遠超過當今的一般程序員。
關于團隊集體在軟件開發過程中的價值，還有個別人仍然沒有認識到。或者也許他們確實認識到了，但是受制于其對個人職位的患得患失，他們的做法總是南轅北轍。現在對軟件開發主管們的考評，很大程度上仍然是根據其已有的成果多少，而不是看其是否有能力建立能夠創造出更多成果的團隊，或是看他們的成果質量。在這樣的壓力下，主管們就會極盡其能事，編造種種相互矛盾的甜言蜜語去哄騙其屬下，以期得到更多成果——當然，這些成果大多是短期的。他們的一些下屬也可能領悟出這個游戲的原理，于是也會效仿這種伎倆，去欺騙他們的下屬······，這樣一直下去，直到他們也成為這樣的主管。這種主管根本不屑于去建立團隊，也開發不出什么高質量的成果，而只會再帶出更多像他一樣的下屬——有朝一日這些人又將成為下一代被這樣誤導的主管。
第五章 程序開發團隊
無論具體情況如何，程序開發團隊的規模和組成似乎都符合這樣一條基本的規律——如果希望通過最小的代價獲得最佳的開發效果，你必須找到盡可能出色的程序員，并且給他們以盡可能長的時間，這樣你需要的程序員數量也將最少。反之，如果你希望工作能盡可能快地完成，或者雇用盡量少的經驗豐富的程序員，那么開發成本與不確定性都會隨之增加。
在程序開發的過程中，開發團隊中各成員的地位，通常在很大程度上取決于其他人對其個人能力的了解程度。如果程序能夠(在團隊中自由)流通，供程序員們相互評判、指正，那么“精英們”就能夠更快地脫穎而出。
為了實現在集體目標上真正的意見一致，最好的辦法莫過于讓開發組自己來確定其目標。首先，在目標制定時廣泛參與，可以確保目標能夠被大家充分理解。另外，這個過程使集體中的每個成員可以有機會對共同的目標做出公開的承諾，而——也許是因為認知失調的作用——這種公開的承諾已被證明可以提高目標的可接受性。這種參與和其他因素不相干，但是參與本身卻似乎是一項重要的因素，它能夠決定各個成員是否真的接受了開發團隊的任務目標，并提高開發效率。
而最大的危險則來自于主管，由于他們都是經過程序開發中的層層選拔才得以出頭的，所以這些人總是希望在手下成員看到問題之前，就已經把每一個細枝末節都詳細地定義好了。再沒有其他做法能夠更挫傷成員的積極性了，它只能使成員覺得自己不過是“編碼器”而已。
就社會科學家對“領導能力”一詞的使用而言，其含義應該是“對他人的影響能力”。程序員一般會更加注重創造性的工作及專業能力，在他們所從事的工作范圍內，他們會對些被自己認定為很出色的人更加器重。這樣，與那些世界級的口若懸河的推銷商們相比，作為一名語調溫和的程序開發奇才，將可以更加輕松地對程序員們進行領導(或影響)。當一名根本沒有編過程序的領導者被指定負責某個開發團隊時，除非該領導者明確地或者含蓄地承認自己在技術問題上的能力欠缺，否則注定會有麻煩發生。即便是那些曾經當過程序員的人，只要他后來有相當長的時間脫離了這個行當，如果他依然企圖去與團隊中的其他成員在程序開發才能方面一比高低，那么情況簡直就糟糕透頂了。對于那些公開承認自己在程序開發方面經驗欠缺的人，他的團隊成員還有可能會尊重他，但是如果有人企圖掩蓋自己在這些方面的無知，那么等到他遲早露餡的時候，就會招致程序員們的無情嘲弄。
目光短淺、難以依賴的團隊領導者可能會認為博得管理層歡心的最好方法，就是無論他們要求什么都滿口答應。但是最后，管理層需要的不只是諾言，而更重要的是恪守諾言，只有在團隊的領導者有能力使整個團隊都接受這個諾言，并且以此作為集體的目標，諾言才有可能兌現。
團隊的領導者需要學習的東西包括：
無論主管們怎樣地強調諾言，他們真正關心的只是結果。
如果希望得到的結果與在整個團隊的參與下所確定的工作目標一致，那么這一目標就會非常容易地實現。
領導能力方面的一個悖論非常簡單：只有隨時準備下臺的領導者，才有可能獲得成功。
將影響到一個團隊的生命期及其績效的因素包括：
各成員的特長與不足。
目標設定的方式。
待開發的程序的結構。
由外界強加的領導管理結構。
某些成員的性別，以及其他成員對待這種性別的態度。
團隊與其周圍環境中其他部分之間的溝通聯系。
團隊領導人在技術方面的能力與欠缺。
第六章 程序開發項目
如果項目主管希望穩定地推進自己的項目，他就必須嚴格遵守這樣一條簡單的格言：
如果某個程序員是不可或缺的，那么還是越快請他走人越好。
關于績效評價，溫伯格先生舉了一個逐層匯報系統的例子。
有一個眾所周知的心理學原理：如果要使學習的速度最快，必須向主體及時地反饋其表現之好或之壞到了什么地步。但是也許不為人所知的一點是如果人們感到他們的績效正在受人考評，同時又不能充分了解別人到底如何評價自己的工作，那么他們就會通過不斷變化的方法來試探這個評價系統。在像這樣的報告系統之中，如果在提供了輸人數據之后，處于底層的人們沒法獲得相應的評價反饋，那么他們就會隨心所欲地改變自己輸人的數據，然后觀察可能產生的不同效果——以期得到一些反饋，哪怕評價的結果很不理想。
第三篇
作為個人行為的程序開發
在探討了程序開發中人類作為主體的共性問題之后，本篇開始討論具體程序員的個體偏差。我感覺這部分沒有前面兩篇精彩，尤其是與性格理論相關部分，溫伯格先生在評注中也表示，如果要在25年后重寫這本書的話，這一部分將是改動最多的。
在談到業余程序員與專業程序員時，溫伯格先生說：
如果希望確定一名程序員的工作是否出色，我們就必須看看，他是不是按照恰當的級別來處理這個問題。有些人可以憑借其才氣與個性，成為一名出色的業余程序員，但是從專業程序員的標準來看，這種才氣與個性往往正是極不合適的。重要的是根據手頭待解決的問題來調整自己工作方式的能力，而一旦缺乏這種能力，任何人都絕對不適合做一名專業程序員。
程序員工作績效的差異，在很大程度上取決于其對完成任務目標的不同理解。
除了智力以外，程序開發的成功(或者失敗)還取決于其他的很多因素。我確實曾經發現，有些人貌似駑鈍，卻可以寫出高質量的、很有用的代碼;而另外一些人雖然看起來更顯聰穎，卻從沒寫出過任何有用的代碼。簡而言之，今天的我依然堅持自己經過了25年時間考驗的立場：“·····較之智力因素，人格因素、工作習慣及培訓等方面的因素要與此更為相關。這些因素與智力因素不同，它們都可以通過后天經驗發生改變。因此，選拔程序員的問題就轉化成為培養程序員的問題。"
我所謂的“培養程序員”，并不是強行要求他們按照某種“最佳”模式進行思考。我在自己的博士學位論文中曾清楚地指出問題求解的模式是因人而異的。所以，如果有什么力量強制某個程序員按照另一個人的模式進行思考，那么就必將削弱該程序員解決問題的能力。因此，最大的挑戰并不在于創造性思維本身，而是創造性的交流，用可以為(各有其獨特思維方式的)其他人所接受的方式重新表述我們自己的思想。
對照自己前些日子的工作，創造性交流是我目前十分欠缺的。
主管們所犯的一個錯誤就是，他們總是假設工作績效差的原因是由于缺乏積極性。于是，他們會企圖借助一點“外部驅動力”來彌補“內在驅動力”的不足。而在這種時候，其實程序員所承擔的外部壓力往往已經夠大了，而并非不夠。
關于積極性，最廣為人知、也最廣為人接受的一項研究成果就是：如果適當地增加“驅動力”，那么在開始階段確實可以提高工作績效;但是一旦超過一定的極限之后，繼續增加這種“驅動力”只會很快地令工作績效降為0。在復雜的任務中，更容易看到這種工作績效急速下降的現象，這正是它對程序開發如此重要的原因所在。比方說，過于努力地去查找錯誤，與根本不去查找同樣壞，至還要更壞。實際上，往往要等到程序員已經決定放棄從而不再承受壓力之后，許多程序錯誤才能被排除掉。給程序員施加高壓，以期他們能夠很快地排除某個程序錯誤，這種做法已經被證明是最差的策略——盡管截至目前，這仍然是最常采用的策略。
為了激勵程序員，就可以授予他們金錢之處的獎賞——比如說，對他的工作質量給予更多地關心，或者讓他負責一點規劃工作。需要提醒你的是：這并不只是要為公司節省經費，而是為了更有效地激勵他們。
也許正是由于管理人員反復不斷地催促盡快“完成”任務，所以經常出現的情況就是：一旦程序被認為是“可以工作的”，程序員馬上就宣告其大功告成——其實這往往是一種誤解。但是作為程序員，只要希望學習，那么你就必須一邊頂住來自管理層的壓力，一邊花時間對自己的成功進行總結。而對于管理人員來說，一個好的做法就是：每當程序員宣稱自己的項目已經“大功告成”時，給他一天的時間放松一下——這并不是一種獎賞，而是為了讓程序員加深對該項目的理解。
第四篇 程序開發工具
本篇中溫伯格先生花了很多篇幅討論語言問題。我對此不感興趣，因此略過。
第五篇 結語
結語的最后一段我很喜歡，摘錄于此：
我們正站在一個新時代的邊緣，正是由于蘊藏于計算機之中、遲早要發生的革命，這個時代才有可能到來。站在這個邊緣，我們有兩個可以選擇的力向——邁人自由的黃金時代，抑或是倒退回專制的黑暗年代——無論你如何選擇，這個世界中任何已知的事物都將被人類征服。也許任何個人的努力對最終的結果都不會有什么影響，但是我們絕對不應該放棄嘗試，因為否則其后果必然是回到專制。這本書就是我反抗專制、反抗人奴役人、反抗被自己的無知所奴役的一次努力。但愿專制的力量不會利用這本書，但是毫無疑問，專制的力量確實會借鑒這本書。既然在這方面的希望破滅了，那么我只能希冀，處于杠桿另一端的正義力量能夠從本書中獲得更大的幫助。
【《程序開發心理學》讀書筆記】相關文章：
程序開發員簡歷封面模板09-22
程序開發個人簡歷范文09-07
《拖延心理學》讀書筆記感觸09-18
Android手機開發程序員求職簡歷模板05-17
博克《拖延心理學》讀書筆記11-23
兒童教育心理學讀書筆記02-02
內資房地產開發公司的設立程序06-17
Android應用程序開發課程的CDIO教學實踐的論文08-07
程序員必備IT軟件開發常用英語詞匯08-15
《設計師要懂心理學》的讀書筆記06-20