程序開發中匪夷所思的事情
最近看了一本名字叫《程序開發心理學》的閑書，收獲滿滿收獲滿滿，潤色一下分享給大家。
關于團隊的互相學習成長
我們經常都會說，要進入到一個高手比較多的地方去學習。一旦你身處一個高手遍地的地方，其實你會發現人跟人差距就是這么大，而且高手做的事情你一點也插手不上，而且其實很多情況下也沒法學習到什么東西，很多時候高手最牛逼的地方在于經驗和思維。如果你們只是在一個項目里邊分工合作，而你除了干好自己的事情以外沒什么其他的目標了，那么很抱歉，你可能壓根學不到什么東西。
書中有一段是這么說的。
如果一個集體的共同目標僅限于產品的層次，那并不見得會促使其中的程序員互相學習。而反過來，團隊內部的成員不僅目標一致，而且其目標與他們具體開發的產品毫無關系，正式這種目標的引導下，一只團隊的成員才會通過互相學習共同提高。
因為就我的經驗來看，大部分程序員在一起工作并不會互相學習。如果是導師，那可能會有一些經驗的指導。如果是平級，那可能一年下來都不會互相學習。就算是經常有合作，很大可能性都只會在項目功能接口層面進行溝通。一方面是術業有專攻其他領域其實挺難去介入的，另外一方面可能思維上就壓根沒想能從 A項目、B項目 別人的產出上面學到什么東西。
但是如果，僅僅是如果，如果所有人都有一個評判標準，以及都有一顆想提高自己代碼質量的心，我們會進行代碼 review。代碼 review 過程其實是能產生很多東西的，同時也能學習到很多東西，但是有個大前提，就是大家的對這個事情本身也感興趣，而不是為了具體的產品。根據以往的經驗，這種事情很快就流于形式，也就是隨便看一看，就算是精心準備的分享基本也都會被聽眾忽略掉，這就沒什么意思了。但是如果整個團隊對分享和代碼 review 這個事情本身很感興趣，還是能從中進行查漏補缺得到非常多的信息的。
把一群程序員放在一起他們很多時候他們并不會互相學習，只有平時有共同理想，愿意嘮嗑，愿意一起解決難題，愿意聽對方的意見和分享的的一群小伙伴才會在不知不覺中互相學習互相指導。
人類總會本能性地，反對別人對自己的負面評價。
即使面對來自自然地，難以接受的反面證據，人們也往往會認定自己的程序完全正確。
“這不是 bug ， 重啟一下試試”
“這不是 bug ， 絕對是使用方式有問題”
我發現很多時候人類都是會逃避對自己的任何負面評價的，無論這個評價是不是從很多人看來都是無可辯駁的，畢竟計算機不會騙人，它只會做我們告訴他要去做的事情，但是人對它結果的解讀是可以有主觀性的。一個很好的功能，到了另外的場景可能就是 bug 。一個很難解決的bug，到了另外一個場景可能就是一個很好的功能。
有這么一個小故事，很久很久以前，我們的程序有一個 bug 總是找不出來，就是有一段內存總是會隨機性丟失。我們就開始查，拼命查，沒日沒夜地查，程序員走了一波又一波。但是依然都找不到這個問題所在，很是苦惱。突然有一天，咦，有一個地方需要模擬一個場景，就是 內存隨機性丟失的場景下對程序進行測試。喔吼!!!這個帶 "bug" 的程序比任何人為構造出來的內存丟失更加隨機更加可以反映事實，而且在很長一段時間里都非常"穩定"。
現在你還覺得這是一個 bug 嗎?
關于團隊的高效
有些主管依然會與高效的程序開發團隊發生沖突，并進而又以各種毫不相干的借口，將這些團隊解散。而有些主管雖然還是搞不懂這些團隊的運行方式，但是他們卻至少懂得應該容忍這些團隊的存在。
在很多的職場，都會出現這么一個現象就是有其中一個團隊效率非常非常高，而且交代的事情也能完成得非常非常好，但是主管看不懂啊。很不明白為什么這幫人就行，另外一幫人就不行，也不是能力上的問題啊大家都是同樣的標準招進來的。
有的主管能很好處理，不理解就不理解，這些事情交給他們就穩了，我對他們也愛護有加就行了。而有的主管則不能，就是希望掌控全局，任何一個小細節都不放過，對于這些超出認知范圍的事情很是扎心，一定要插一手，所以就出現了上邊的情況了。
程序開發的社會效應
關于程序開發的社會性。比如程序開發中有其中一個環節就是程序員A口頭將信息告訴程序員B，這在以往的運行過程中得到了非常好的效果，這時候你換掉程序員A或者程序員B，都將帶來效率的降低。
很多時候我們都以為我們的程序運行都是靠我們***的產品設計，穩定的系統流程，全鏈路能 Cover 住。很遺憾不是這樣的，我們處在的是人類社會，是人類在使用這些東西。只要有人類介入，那絕對存在一些很迷的東西。
比如，有一個功能開發好了，開發的***反應不是去系統上點一下完成，而是大吼一聲："測試大佬，我那個bug修好了你驗收一下"。
又比如，很多程序員都會去找架構師聊事情，但是我們又發現有很多程序員坐在架構師旁邊的咖啡小屋那嘰嘰喳喳，所以老板決定把這個咖啡小屋干掉。好了事情來了，架構師開始忙不過來，大大小小的事情都找架構師解決。原來有這么一個咖啡小屋，大家看起來嘰嘰喳喳的很吵，但是其實大家在等架構師空閑的時候，已經在咖啡小屋把很多小事情討論完了，或者梳理出了一個比較可行的方案，這樣會節省架構師的時間，也會節省程序員的時間。
關于程序員的作息
一個老板看到程序員王鐵蛋早上十點才到，很是不爽，就跟程序員說啊我不管你明天要早點來。
(其實程序員昨天晚上才把某個比較緊急的東西加班弄完到深夜)
王鐵蛋的反映非常簡單，無非是嚴格按照工作時間正常地上下班。
我還是希望小伙伴們，多去健身房，晚上確實要加班也可以，吃完飯健身完再繼續加，盡量十二點前睡下，過幾年你會回來感謝我的。
希望你們要克服人類的通病，假裝自己很努力。
關于民主和集權的領導模式
民主性集體，由于任務是全體成員共同承擔的，同時他們之間存在很多交流，所以當某個人離開后，其他的伙伴會根據需要填補它的空缺。但是反過來也證明，如果有一個新來的，由于組織中并不會給他留出一個特定的位置，所以這樣的團隊很難接受新成員。
集權式集體。任何成員離開后自然就會暴露出任務分工上的空缺，只有其***才擁有必要的信息能夠在剩余的成員中重新進行任務分配。但是如果有新成員加入了，手續會非常簡單，直接去找領導人分配任務，然后交接就好了。
關于給項目潑冷水的人
會議上一片和諧，大家都對于接下來要完成的事情胸有成竹，開始笑聲慶祝除了小喬，嘴上有一點點抿嘴。然而尖銳的項目經驗還是察覺到了這個細節，問小喬:你還有什么問題嗎?
"一切都正常，但還是有一點點小問題"。
"有多小?"。
“我的任務可能需要延遲一點點”。
"多久?"。
"六周"。
"我想。。。我的小組也需要這么久"，大喬說道。
"我也需要..."孫尚香、曹丕都順著說道。。
這就是剛剛和諧開會的結果??我們剛剛浪費了一個小時在討論什么??!!!!!
也許，需要有這么一個提出不同聲音的人，來質疑這個計劃以及那虛假的和諧，來保證這個項目的正常進行，很多開發對于程序開發中需要消耗的時間還是過于樂觀，覺得代碼寫完就完事了，又或者是對于項目本身不了解的盲目樂觀，這就是非常非常多情況下項目延期的原因。如果有一個人，指出這些方案的不合理性，又或者是項目時間的不合理性，可能就不會在項目延期的時候互相推諉了。
然而在現實中，這個人經常被當成噴子，被認為是來破壞和諧的人。。。
關于天才程序員
優秀的程序員是培養出來的，不是天生的。
程序員其實現在都已經是一個門檻非常非常低的職業了，但是也存在跟數學一樣循序漸進的過程。你要知道A定理，才會覺得B推論理所當然。如果你不知道A定理，那么大佬在說顯然可得B推論的時候，你就會覺得很痛苦，這就是先驗知識所能產生的壁壘。
程序員也是一樣，你要知道足夠多、足夠底層的東西，你會發現現在所有的技術都只是在上層上有一些封裝、拓展、易用上的改進，所玩的花樣基本都還是幾十年前的理論，沒什么大的變化。所以你要像一個正常學習節奏的人，去學習，去深究，去交流。當然無論是玩耍還是游戲還是學習，只要你覺得開心你都可以去做，能在學習上覺得開心的肯定是少數，畢竟學習很多時候都是一件逆人性的事情。萬一你要是克服了，恭喜你你已經比很多人厲害了。
所以你需要更多的 practice、practice、practice。平時看到喜歡的東西，就去學就是了，就去練習就是了，管他什么跨界什么太難，當玩具去玩就是了，再把它總結出來分享給大家，讓大家挑刺，有一天你很可能也會成為很多人眼中的"天才"。
【本文為51CTO專欄作者“大蕉”的原創稿件，轉載請通過作者微信公眾號“一名叫大蕉的程序員”獲取授權】
