程式開發中匪夷所思的事情
最近看了一本名字叫《程式開發心理學》的閒書，收穫滿滿收穫滿滿，潤色一下分享給大家。
關於團隊的互相學習成長
我們經常都會說，要進入到一個高手比較多的地方去學習。一旦你身處一個高手遍地的地方，其實你會發現人跟人差距就是這麼大，而且高手做的事情你一點也插手不上，而且其實很多情況下也沒法學習到什麼東西，很多時候高手最牛逼的地方在於經驗和思維。如果你們只是在一個專案裡邊分工合作，而你除了幹好自己的事情以外沒什麼其他的目標了，那麼很抱歉，你可能壓根學不到什麼東西。
書中有一段是這麼說的。
如果一個集體的共同目標僅限於產品的層次，那並不見得會促使其中的程式設計師互相學習。而反過來，團隊內部的成員不僅目標一致，而且其目標與他們具體開發的產品毫無關係，正式這種目標的引導下，一隻團隊的成員才會通過互相學習共同提高。
因為就我的經驗來看，大部分程式設計師在一起工作並不會互相學習。如果是導師，那可能會有一些經驗的指導。如果是平級，那可能一年下來都不會互相學習。就算是經常有合作，很大可能性都只會在專案功能介面層面進行溝通。一方面是術業有專攻其他領域其實挺難去介入的，另外一方面可能思維上就壓根沒想能從 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。平時看到喜歡的東西，就去學就是了，就去練習就是了，管他什麼跨界什麼太難，當玩具去玩就是了，再把它總結出來分享給大家，讓大家挑刺，有一天你很可能也會成為很多人眼中的"天才"。
以上。