點選上方“中興開發者社群”，關注我們

每天讀一篇一線開發者原創好文

作者簡介

作者王輝，程式設計師、敏捷教練，最近致力於TDD、Clean Code、DDD等實踐的落實實施，是軟體設計和軟體架構方法的積極學習者和實踐者。這篇文章從人的認知出發，探索如何制定更加有效的措施，促進個人和團隊的成長。

1.成長的焦慮 

物聯網、AI、區塊鏈、數字化轉型…… 在當前的這個時代，新技術、新工具、新語言層出不同，微信、微博、 公開課、專欄等各種渠道的資訊撲面而來；

IT 從業人員尤其是軟體開發 人員，面臨著比以往所有時代更加豐富的資源；

但是，這個群體中也彌 漫著越來越嚴重的焦慮感，個人、團隊和組織在思考如何才能在快速發 展的背景中維持競爭力，如何在這個競爭日趨激烈的時代“倖存”下來。 

幾乎不約而同地，大家認為學習是活下去的唯一方式；“進化”、“賦能” 等提法成為了各種大會的關鍵詞，各種基於知識分享和變現的創新層出 不窮。

比如，羅胖就有效地販賣了我們的“知識焦慮”，它提出了“一起建 設一所終身大學”的口號。

 關於“學習”和“成長”，這是一個很巨集大、也很專業的話題。在本次分享 中，我將從一個軟體工程師和教練的角度，通過幾個小的案例，來分享 幾點自己關於個人、團隊和組織學習和成長的心得。

2.認識大腦，高效學習

不同人的學習效率差之甚遠。

有人能在很短的時間內完成學習任務，從 而留出更多的時間去幹更多的事情，這種能力體現為高效的學習力。在 知識爆炸、資訊傳播高效的背景下，這種學習力將給個人的成長帶來極 大的分化。直接體現在有些人懂得多、學得快，而有些人花了很多時間 和精力卻收效甚微。 認知科學的知識，可以幫助我們認識大腦的學習規律，從而使得我們可 以更好地設計自己的學習方法，提升學習效率。

從表層知識到深層知識，構建知識體系

學習的最終目的，是需要形成抽象知識。當我們面對一個複雜的問題時， 經過層層分析，抽絲剝繭，去除掉其中不重要的細節，最終將問題對映 到我們既有的抽象知識上，從而找到問題的解決方案。

這是一種能力，是需要經過不斷練習、積累才能習得的能力，也是從新 手邁向專家的必經階段。學習的有效過程是，獲取各種表層知識，經過 消化、積累、抽象等階段，形成自己大腦中的深層知識。經過抽象的知 識，在大腦中佔用的容量更小，從而為學習更多的東西騰出空間。 在《程式設計師思維修煉》這本書中，作者從認識人的大腦出發，講述瞭如 何認識大腦所固有的生物性缺陷，克服個人的認知偏見，積極學習，提 高創造力和問題解決能力；並且提出了一系列實用的方法，幫助新手不斷成長為專家。

幾點個人心得 

具體地，在過去幾年中我個人採用了以下手段和方法，幫助自己更好地 消化知識，構建自己的知識樹： 

•  有所為，有所不為 結合個人發展和組織需要，制定個人成長的計劃，將有限的精力投入 到關鍵的 2-3 個點上；構建個人在某幾個領域內的競爭力，避免廣撒 網帶來的低效。 每個月、季度、年度進行定期的回顧，檢查目前前進的方向是否偏離 了預定軌道。

• 勤於練習 一萬小時定律已經廣為人知，對於軟體程式設計來說也不例外。沒有足夠的練習，就無法積累足夠的表層知識，也就無法轉化為大腦 中的深層知識，建立更高層次的抽象。 

• 做筆記、寫部落格、做分享 在讀書、學習的過程中，通過思維導圖、塗鴉等各種方式對知識進行 總結、提煉，方便自己回顧，建立知識點之間的連線。做筆記的過程 就是重新對知識進行梳理和總結的過程，有效避免了書讀完之後已經 把前面的內容忘掉的問題。

此外，將自己的心得寫成部落格對外發布，爭取各種機會進行分享，也 是促進知識抽象、建立個人自信心和成就感的好方法。 過去的一兩年，我平均每年在“簡書”上輸出 10 篇左右的總結文章， 並積極爭取 TiD 等各種外部交流學習的機會。

• 授人以漁（教練他人） 在過去的幾年中，我有幸作為教練參與到團隊的轉型中，進行軟體設 計和基礎能力提升相關的實踐推廣。比如，過去幾年對於 TDD、重 構和抽象等實踐的輔導，弄清楚了一些之前感覺已經懂了、但實際上 並不理解的知識點。 同時，我還先後進行了超過 300 小時的專題培訓和工作坊，有效提 升了個人對技術的理解和公眾表達的能力。 教練的過程是個人不斷將知識內化，形成抽象知識的過程，也是這樣 一個過程：感覺自己懂了 -> 真的懂了 -> 還有更多東西不懂。

  
  

3.從做中學，一種更有效的學習方式 關於學習的兩個案例

關於學習的兩個案例 

• 學習古典音樂

在得到的專欄《雪楓音樂會》中，雪楓老師曾經提到，在專欄開始的初 期階段很多聽眾希望能先介紹一些管絃樂隊的樂器；但是他認為，對 於古典音樂的學習，應該堅持“先聽後學，先愛後懂”。 

• 學習攀巖

在學習攀巖的現場，教練走過來，確保所有人都繫好了安全帶。我們都全副武裝地接受檢查，檢查完畢之後，他走到人群的前面，我們屏住呼 吸，準備聆聽教誨。

但是，根本沒有什麼教誨。他只是告訴我們現在開始攀巖，30 分鐘後 我們再回來集合。

教練揚長而去，去喝咖啡了。

我們胡亂地在岩石上爬了一會，事實上都不知道自己在幹什麼。半小時 之後，教練出現了，開始講課，告訴我們如何攀巖。

現在因為我們有一 些經驗，所以他的講解更加有意義。

這比他一開始直接講課要清楚的多。

首先我們經歷了多感官、親身實踐的情景，幫助我們有了初步瞭解。

然 後，他再進行一次傳統的、充滿針對性的授課。

在正式的應用或動手實踐之前，我們更傾向於先接受所謂的“基礎”理論 知識。例如，在英語的學習中，我們會接受系統的語法知識；

在學習古 典音樂時，我們期望首先弄明白管絃樂隊中的各種樂器，瞭解諸如協奏、變奏等術語的涵義；

在程式設計時，往往會優先學習這門語言的語法和各種 特性。

我們往往希望前期學習的這些基本知識，能夠以為後續的實踐做好準備。

不幸的是，我們在真地嘗試學習語言時，語法知識很可能已經忘記了；

 當我聽到一首曲子的時候，之前學習的那些術語已經對不上號了；

當我 們在程式設計的時候，卻發現還是有很多特性不會用，還得回頭再翻開書本 學習。 我們在前期所花掉的大段的學習時間，並沒有發揮出應有的作用。 

相反地，如果我們先了解一小部分知識，然後直接投入實踐，完成一些 簡單的任務，讓自己先“存活”下來；

然後，以此為基礎，再製定下一步 的學習目標，進行更多的實踐。按照這個模式不斷迭代前進，學習效果會更好。 

也就是在做中學，通過“做”為“學”提供更好的反饋。 

一個軟體設計工作坊的改進案例 基於同樣的思路，在過去的幾年中，我們不斷摸索和改進內部的軟體能 力提升專案。

 在傳統的培訓課程中，講師和學員之間是單向的資訊流動方式：講師說， 學員聽。課程的效果往往很差，尤其是實踐性很強的軟體設計類課程。

針對這些問題，我們將軟體設計類課程做成了開放式的 workshop 形式。

 我們將課程內容按照內在關係進行拆分，將拆分出來的內容做成一個個 相對獨立的模組。 

在實施過程中，我們先針對每個模組丟擲一個小問題，由學員在個人的 開發環境中進行嘗試，教練在這個過程中僅提供支援性的輔導作用。

個人嘗試環節結束後，學員們就個人完成的情況進行分享和交流；

這個環 節之後，教練再帶領大家按照課程設計的方法繼續進行實際操練，並根 據前面環節中學員反饋的資訊進行有的放矢。

依此不斷迴圈。 先嚐試完成一個小目標，再投入學習，不斷迭代完成大目標。通過這個 方法，學員反饋的滿意度大幅提升，學員和講師之間的互動和信任得到 了極大的改善。

4.影響與激勵他人

承擔管理或者教練角色的人，如果想在團隊中推行某一件措施，往往並 不容易。《影響力》這本書中提到了一些具體的策略，可以幫助我們更 好地說服別人，提升個人做決策時的影響力。Linda Rising 在 TiD 2017 上的培訓課程《Influence Strategies for Practitioners》，也著重介紹了 如何利用影響力的策略說服他人接受一件事情。 

•  Liking. 我們喜歡有吸引力的人，以及跟我們相近的人。

•   Reciprocity. 互惠，人往往會投之以桃，報之以李。

•  Social proof/Consensus. 我們會跟隨類似的或者有地位的人，比如人們曾經對慶豐包子的追捧。 

• Commitment/Consistency. 人往往會努力做到兌現之前的承諾。哪怕這件事不是自己原本想做的， 但一旦做出承諾，就會盡力實現。

•   Authority. 人往往會尊重權威或者專家。

•  Scarcity/Exclusivity. 當我們受到限制獲得某些東西時，我們卻更想得到它。 這些技巧可能已經被很多營銷高手運用得得心應手，我們也可以將其加 入自己的工具箱中，更好地發揮自己的影響力。它讓我想起了幾年前我 們在內部實施 Code Review 的故事

一個實施 Code Review 的案例 Code Review 作為一項軟體開發中廣泛採用的實踐，其有效性已經得到 了認同；左耳朵耗子在《從 CODE REVIEW 談如何做技術》這篇文章 中已經有了討論。但是，在我周圍的團隊中並沒有得到很好的落實。 如何在團隊中落地這麼一件看似很簡單、卻長期被忽視的實踐，不是一 件太容易的事；尤其是一線團隊和開發人員，經常因為時間緊任務急、 耽誤時間、沒有用處等原因而忽略這個環節。 在後來的實踐中，我們借鑑了上述有關影響力的模型，幫助我們逐步走 上正軌。具體來說包括以下幾個方面。

•  開啟眼界，看看外面的世界

在相對封閉的通訊行業中，給予大家瞭解其他行業和公司的機會，尤 其是類似於 Google 這樣的明星公司。在瞭解到這些成功的網際網路公 司裡也在做程式碼評審這件事情的時候，大家更有可能相信這個方法是 可行的，至少願意去嘗試一把。

•  邀請權威人士獻身說法

在敏捷轉型的幾年中，公司投入資源，邀請了來自外部的諮詢師和顧 問，給組織和團隊做輔導，其中包含一些軟體設計水平很高的牛人。 我們趁此機會，請他們幫助我們在團隊內進行 Code Review 實踐的 匯入。 諮詢師的影響力往往勝過內部的這些教練，團隊成員顯然也更願意相 信他們頭頂上的光環、以及過去的成功經驗。從最開始帶著大家做 daily review，到最後團隊逐步養成定期程式碼評審的習慣，這些高手 的帶動作用不可小視。

• 為開發人員解決燃眉之急，贏得信任

作為教練，平時積極地幫助開發人員解決問題，尤其是一些刁鑽古怪 的 bug，可以幫助我們逐步樹立個人的品牌，贏得他們的信任。 當我們再給他們“推銷”一件東西的時候，他們會更容易接受，尤其是 在發現一些 bug 是可以通過程式碼評審消除的情況下。 人與人之間的互利互惠會讓他們更容易接受我們。

•  建立正向的激勵機制

程式碼評審穩定進行一段時間後，我們在組織內設立了“show me the code”活動。這個活動每月舉行一次，大家可以把通過程式碼評審發現 的典型程式碼，提交到一個公共論壇供所有人點評和討論。然後通過投 票的方式選出最有價值的幾份程式碼，在內部給予相應的物質和精神獎 勵。 通過這種方式，引導大家不斷將程式碼評審的習慣保持下去，並形成穩 定的節奏。

5.總結

人的大腦來源於人類千百年來的進化和基因的遺傳，這也決定了我們的 思考方式和行為方式在很長一段時間內保持基本穩定，其中包含了一些 與生俱來的弱點或者缺陷。 一切問題歸根到底都是“人”的問題。從人的特點出發，可以幫助我們更 好地認識自己和團隊，順應人性，從而制定更加有效的措施，促進個人 和團隊的成長和進步