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