作者：草小誠
轉載請注原文地址：https://blog.csdn.net/cxcjoker7894/article/details/85319250

前些天讀完了《程式開發心理學》（傑拉爾德·溫伯格），這本書確實不錯，和博主一直以來的觀念相契合，對博主自己程式開發方法論的系統形成有極大的幫助，另外作者在數十年前就能寫下許多當今被大家所認可的方法理論，令人深感敬佩。
本文記錄書中一部分核心論點，以原文為基礎，進而談談博主自己的理解，也有一些博主認為不錯的句子摘抄，主要集中在第二章團隊篇和第三章個人篇，粗體為書中原文。

無私式程式開發與民主化團隊

“如果注意力只是集中在他們自己程式上，那麼即使是輸出中再明顯不過的錯誤，也會被程式設計師忽略掉，而旁觀者則可以一眼看出這些錯誤。”

作者舉了一個例子，即如果一個人買了一臺大眾汽車，那麼在咖啡店等地方等待的時候，在一沓汽車廣告宣傳冊中，就會傾向於只看大眾品牌的宣傳冊。因為人們都傾向於發現自己是對的，在專案開發中，如果遇到一個無法定位又無法復現的問題，開發團隊很容易傾向於忽略這一次“偶然”的錯誤輸出，以致於埋下以後崩潰的釘子，為了避免這樣的情況出現，引出了後面的無私式開發，一份程式碼不會只由書寫者獨自審閱。

“如果一個成員因為分配給他的工作而感到自卑，那麼壓抑這種感情會給團隊凝聚了造成災難性的影響，採用無私式程式開發的方法，可以讓每個人都感覺到自己並非偏於系統的一隅，而是共享了系統的大部分，所以以上情緒可以得到緩解。”

“程式設計師需要知道“為什麼做”，而不是“做什麼”。”

作者提倡讓參與專案的每個人都完全瞭解專案，每個人都知道專案的架構，分工，目標，受眾，需求等等，每個人都有在會議上的發言權和話語權，博主非常贊同，這樣做可以充分發揮每個程式設計師的主動性，也會極大的統一大家的努力方向，減少無用功和偏差的出現。提高大家的存在感和成就感，而且可以讓優秀的有產品思維的程式設計師們也發揮出自己的優勢。

“與那些世界級的口若懸河的推銷商相比，作為一名語調溫和的程式開發奇才，將可以更加輕鬆的對程式設計師們進行領導（或影響）。”

“當一名根本沒有編過程式的領導被指派負責某個開發團隊時，除非該領導明確或含蓄的承認自己在技術能力上的欠缺，否則註定會有麻煩發生。”

雖然博主沒有過這樣的體驗，不過想也知道，被一個什麼都不懂的人對著自己的程式碼指手畫腳，或是被要求做出一些不切實際的需求或實現方式的時候，那體驗一定是極差的。作者舉了一個例子，說一個專案經理開發水平很差卻很愛裝13插手程式設計師的工作，有一次他對一個程式設計師描述他比較愚蠢的想法，那個程式設計師假意說：“嗯，我覺得非常好，可以拿到大會上討論一下。”然後可想而知，這個經理在眾人的嘲笑聲中狼狽下場。所以勇於承認自己的不足，這不止侷限於程式開發領域。

“（不好的管理方式）只能對相對不夠成熟的程式設計師才可行，因為他們不瞭解還有其他的可能，或者對技術相對粗劣的程式設計師也可行，因為他們再清楚不過，其他的可能並不是為他們而存在的。”

這裡說的不好的管理方式，指的是一個開發團隊遇到了一個蠻橫不講道理，水平又不行的領導，既然領導層不會妥協，面對這愚蠢的領導，只能由開發團隊妥協，作者稱此為“強加的工作”，大部分程式設計師不會忍受這樣的環境，但存在即合理，既然有這樣的現象，一定有其原因，原因就是有些程式設計師因為上述兩點，忍受著在這樣的環境中工作。

“領導能力方面的一個悖論非常簡單：只有隨時準備下臺的領導者，才有可能獲得成功。”

這裡的領導指的是專案經理，在專案經理之上還有公司領導層，在其之下則是專案的開發團隊，那麼如何平衡這兩者之間的關係呢，即為此句，專案經理必須有原則與自信，他必須知道，自己即使因為頂撞領導而被離職，也一樣能找到更好的工作，如此才能保證自己的產品質量。然而可悲的是，現在大多數的專案經理，對上一味的承諾應承，以此來獲得領導的青睞獲得提拔，等到真正專案完成不了的時候，他已經升職不再對此負責了。

“在某些成員離開之後，民主式組織的開發團隊顯得更有能力經受住相應的影響，由於任務是由全體成員共同承擔的，同時他們之間存在很多交流，所以當某個人離開之後，其他的夥伴會根據需要填補他的空缺，並且運用在他們共同工作期間掌握的知識。但是反過來事實也證明，如果有一位新來者加入到一個民主式管理的團隊中，那麼由於其內部結構中不會專門為他留出一個明確的位置，所以這樣的團隊通常很難接受新成員。”

民主化團隊讓新成員很難融入，而一旦融入，對新成員來說也是極為舒服的，團隊整體的凝聚力高，效率和能力上限也高，也能讓其中的成員能夠更加全面和快速的發展。相信這是大家所期待的團隊，但是也是可遇而不可求的稀少團隊。

“因此我們明白了，對於程式開發團隊來說，為什麼民主式的——或許應該成為“崇尚技術式的”——組織形式更為自然。”

民主式團隊由於交流充分，成員的地位是由其他成員所瞭解到的其的技術水平所決定的，所以民主式團隊可以自行決定在專案開發的每一階段，由誰去做主導，由誰去定分工，等等，這就是崇尚技術式的體現，說到這裡博主其實認為，民主式團隊對成員的個人能力要求是極高的，換句話說，如果要組建民主化團隊，那麼吸納的每一位成員必須有一個較好的綜合水平才行。

專案的管理和績效

“如果某個程式設計師是不可或缺的，那麼還是越快請他走人越好。”

這句話題主持保留意見，每個公司都有自己的中流砥柱，一般是非常重度的參與業務，如果此人離職，想必極難找到完美替代的人。如果要做到每個人都是可以熱插拔的，除非要每個人都淺層次的參與公司業務，這樣感覺雖然可以做到專案抗災能力強，但是代價太大。而且恐怕會影響員工情緒。

“魔鬼異議者”

人們都有一種從眾心理，作者提到一個實驗：一個明顯的正確答案，如果會議內的其他成員都答錯成錯誤選項（在實驗中這些“其他成員”都是提前安排好的），那唯一的一個實驗物件也會選擇跟隨說出錯誤答案，但是隻要有一個人——哪怕就只有一個——說出正確的答案，實驗物件就會有勇氣也堅持正確的看法。所以許多管理者在管理團隊時會設定一個“魔鬼異議者”角色，在會議中專門提出不同的看法，在咱們現在看來可能就是槓精了，有時會收到奇效。

“你的好朋友沒有任何理由不能同時也是對你最為苛刻的批評家。”

樂交諍友，這個道理人人都懂，但是人人都很難真的做到，做別人的諍友很容易，接納自己的諍友很難，良藥苦口，與君共勉。

程式開發任務的差異

“業餘程式設計師需要學習的，只是其待解決的問題，對於他們來說，所謂“程式開發方法的學習”，不是漂亮的幌子，就是一樁令他們苦惱的麻煩事。與此相反，專業程式設計師確實要學習其專業——程式開發——而通過程式開發所解決的問題，不過是他們在水平提高過程中的一次偶然事件。”

作者在書中將程式設計師分成了“業餘程式設計師”和“專業程式設計師”兩類，其本質區別為：業餘程式設計師所書寫的系統只為其自己或某幾個人使用，而專業程式所寫的系統是給別人使用。如此劃分沒有問題，然而現在，有太多的程式設計師做著專業程式設計師的工作，抱著業餘程式設計師的心態。書中對業餘程式設計師的描述，與他們無不貼切。所以博主認為不能如此簡單的劃分，而應該明確的辨認，哪些人是專業程式設計師，哪些人是“業餘”程式設計師。而且，業餘程式設計師和專業程式設計師之間，互相不理解。

“一名專業程式設計師，如果堅持把一個供個人使用的微小程式，當成需要被成千上萬人使用5到10年的作業系統一樣來對待，難道不是更糟糕嗎？”

“每個程式都有其特定的細緻和複雜級別，這種級別取決於它的具體用途。從某種意義上講，如果付出的努力超出這種級別，要比低於這種級別更為不專業。”

博主有時就有些偏入這個錯誤，一個簡單的網路介面，或是一個小功能，博主總想把它們做的盡善盡美，即使可能是隻給自己使用，或是是從次數極少的小指令碼，也要把他們寫的提示周全，細節完善，這是強迫症吧，的確非常的愚蠢，浪費自己的時間精力。

“為了使程式設計師通過專案獲得的學習收穫最大，我們可以把他們指定到其不是最拿手的崗位上。”

注意這裡說的是“不是最拿手”，而不是“最不拿手”，博主認為，工作所用到的知識，個人已經掌握60%-70%的話，是最快最容易能夠獲得學習收穫的，既不至於掌握的太少而造成工作難以繼續，又不至於全部掌握而沒有獲得新知。

個人的性格因素和智力

“如果一個程式設計師缺乏在高壓力的環境中堅持一個多星期的能力，也許我們就可以肯定地說，他不是一塊程式設計師的材料。”
“由於程式開發的多樣性，所以一個人只要稍微有點不適應快速的變化，他就不能勝任專業程式設計師的工作。”
“在程式開發中需要一個最容易確定的性格特點，就是稍微講究一點整潔。”
“對於從事程式開發工作的人來說，應該多少具備一點的另一個重要性格特徵就是謙遜。”
“在對程式開發至關重要的各種性格因素中，最後一個應該是幽默感。”

以上是作者羅列出的對程式開發具有重要意義的性格特徵，書中明顯的分了等級，抗高壓和快速變化是不可或缺的，等級最高，而整潔只需要“稍微講究一點”，而謙遜在書中被辯證的看待，因為在某些情況下，“自負而武斷”比謙遜更能發揮作用，這取決於個體能力的高低。最後作者把幽默感，作為“至關重要的性格因素”放在了末尾，哈哈，的確，一個幽默的人可能不是一個好的程式設計師，但是一個好的程式設計師一定是個幽默的人~

“即使是對人類行為最不經意的觀察者，也可以明顯地看出，人的智力及其所受到的教育會影響到人的性格。”

“我們還是可以不過分的估計：程式設計師的平均智商甚至要超過大學研究生。大體上講，一個程式設計師群體越是成功，其平均智商就越高。”

“毫無疑問，對於一名程式設計師來說，記憶力是其智力中最重要的方面之一。”

雖然可能帶有一定的褒貶色彩，但是博主在最近一年也已經意識到，智力，的確是影響程式設計師職業生涯的一個重要因素。其實說是智力，可能更多的是邏輯思維能力，人都有一種推己及人的思想，即自己是什麼樣，就會認為大部分人都是什麼樣，所以博主在這一年中最初產生過許多的困惑，因為有很多很基礎，並沒有什麼難度的任務，在一些人看來和做來是如此的困難，以致於博主所設計的介面一度被很多人認為是難以使用的，後來博主漸漸的明白了每個人的智力因素不同，就像KISS原則和使用者認知成本一樣（可能以後會專門開博文來寫對產品的理解），程式設計師所寫的程式碼，應該充分考慮後續使用者的難易程度。

“在缺乏客觀測量標準的前提下，我們常常會通過程式設計師在一個程式上的出力程度，來判斷程式的難易程度。一旦採用了這種測量方法，我們就很容易陷入這樣一個悖論：最差勁的程式設計師往往是最優秀的——因為他們工作得最賣力。”

這真是一個可悲的事實，博主身邊就有許多例子，有些程式設計師，由於水平較低，往往會抱怨自己負責的工作太多和太難，耗時也會比專業程式設計師長很多，但是在領導眼中（即使是技術向的領導也是如此）他們反而是最棒的，每天做著“難”而“繁多”的工作，以至於一直都非常的忙碌和崩潰。再加上現在有許多公司都不是技術人做領導，有些朋友說自己的公司就是以“加班長短”來作為考核標準，所以領導要求他們“即使沒事做也晚點走”，殊為可悲。

“然而這並不是說，簡單的執行一組固定的規則，不是智力行為的一個重要的部分。恰恰相反，如果一位程式設計師即使是完成把兩個數相加這樣簡單的計算，都要費九牛二虎之力，那麼在設計最佳問題求解方案的角逐中，他肯定會掣肘於其差勁的算術能力。”

博主身邊有聽過這樣一些言論：“我學這些公司又用不上，有什麼意義啊”，“我們做的這個破系統就這麼點功能，還能怎麼發揮啊”，“做來做去就這點東西，都一樣啊”，說出這樣言論的童鞋，請你們看看書中這句話，請問，你們做的系統非常簡單，邏輯非常少，那麼你把它們做到盡善盡美了嗎，使用者體驗做到優秀了嗎，負載和效能做到最優了嗎。恕我直言，說出上述言論的人，大多都是系統做的半吊子，不勤於學習，以上述言論為藉口的人，說是工作太差無處發揮，其實根本就沒有發揮的能力。一個簡單的系統都做不好，談何進階呢。

積極性與學習

“只要允許程式設計師按照自己所偏好的方式進行工作，那麼程式開發這項工作本身就是對他們最大的激勵。”

如果說有什麼能和 高昂的工資，廣闊的平臺，具有同樣的吸引力的話，那一定是團隊的技術棧，氛圍，福利，和工作環境了，如果管理者具有遠見卓識，為開發團隊提供寬鬆和自主的工作環境，那麼他一定能得到專業程式設計師的青睞，如果再加上定期團建，健身房或者按摩椅，那他公司的競爭力怕是要直線飆升了。但是這些統統有一個前提，那就是：必須面對的是專業程式設計師。如此才能欣欣向榮的發展，如果是低要求的公司，招納前面提到的“業餘”程式設計師的話，這樣恐怕就不合適了。

“如果一名程式設計師想要不斷提高，他就不能僅僅依賴於正式的培訓，也不能指望主管某天大發慈悲，根據需要把他送去進修。同樣，他也不能依靠純粹的所謂“經驗”，因為經驗不見得一定會交給他所有東西。如果程式設計師需要發揮其經驗的作用，他首先就需要學會如何去學習。”

“有些人總是心甘情願的承認自己的不足，而不去嘗試學習任何新東西，其原因在於，他們總是想當然的認為，自己不可能取得成功。這種對失敗的畏懼心理，有的是缺乏自信心造成的，也有的是源自於先前此類努力過程中的失敗經歷。但更普遍的情形是，這類恐懼主要並不在於失敗本身，而在於失敗可能被周圍人看到。”

博主一直以來都不懂為什麼有人“心甘情願的承認自己的不足，而不去嘗試學習任何新東西”，閱讀這本書讀到這句話，有一種豁然開朗的感覺，原來如此啊，想想確實很對，於是找一個比較有內涵也懂一點心理學的朋友去印證，他也比較贊成，的確，有很多人甘於平凡，只想渾噩度日，對他們來說，學習新知是辛苦的，而承認不足對他們的生活並沒有什麼影響，博主倒是覺得這裡沒有褒貶，每個人有每個人的人生觀，接受平凡可能才是偉大。

總結

上面只是摘抄了一部分博主認為比較精彩的原文，具體本書的全貌還待讀者自己閱讀，書中絕大多數理論和博主以前的觀念想法相契合，彷彿說出了博主潛意識中的觀點，對從無法總結的離散觀點到形成系統的方法論，有重大的幫助。

本書也是博主看的第一本討論程式開發的環境和個體方向的書籍，覺得很是受用，另外書中最後一章還有軟體開發的工具和原則等等，由於博主在大學軟體工程專業中已然學過，看到覺得無感，故本文並未收錄其中語句，但對沒有了解過的人想必也是很有幫助的。

那麼讀完此書之後有什麼實際性的指導意義呢，博主認為是這樣的：

• 作為程式設計師，應該力求加入採用無私式開發的民主化團隊。這就要求作為程式設計師，需要個人綜合素養過關，技術實力過硬（畢竟民主式也可以稱作是崇尚技術式），懂的分辨團隊氛圍。作為管理者，應該力求將團隊文化構建成無私民主式的氛圍。這就要求管理者與時俱進，充分學習現代化的管理理念，坦誠，並且有以自己高超水平為基礎的強大自信。
• 在程式開發和專案管理中，充分的考慮到團體與個人的心理因素，如認知失調，忽略bug的傾向，魔鬼異議者的存在意義等，程式開發是以人為主體的，不能僅僅把它當做一項機器工作來看待。
• 懂的如何去做一個專業程式設計師，瞭解專業程式設計師的特徵和訴求，瞭解一個專業程式設計師需要具備哪些性格特徵和素養，補足自己。同時也要善於總結歸類，分辨哪些人是業餘程式設計師，哪些人是專業程式設計師，以此因材施教因地制宜，採取不同的策略。作為開發者則可以充分的理解周圍的同事，用辯證的眼光看待問題。
• 智力和記憶難以人為做出明顯的改善，但如果要讓博主回答“如何提高智力和記憶力？”這個問題的話，博主會說答案是“思考”，勤于思考，勇於挑戰，不斷學習，就是提高技術與智力的良性迴圈，其實博主說的輕巧，自己也經常很難剋制自己的享樂心理，但只要盡力去做便好，路遠，行則將至。

好了，文畢，推薦《程式開發心理學》（傑拉爾德·溫伯格），值得一讀。