代碼交流會不是一個什么新概念，很多做開發的人都應該聽說過，但應該很少有公司把這個當作一個例行的事情來做，本文就從多個方面講講代碼交流會。

為什么要開代碼交流會

代碼交流會可以提升技術人員的溝通表達能力，而這是團隊協作的最基礎的技能。如果溝通能力不強，相互不能理解對方意圖，即使好像相互理解了，又出現”產品設計是A，開發做出來是B”的情況。

開發人員通過寫技術交流文檔，可以幫助自己梳理思路，發現自己思路當中的問題。而且文檔寫出來后，講給團隊成員聽，也可以讓團隊成員協助發現問題，所以寫交流文檔不光是給自己看的，也是給團隊成員看的。在公司的代碼交流實踐當中，程序員普遍有個思想，”到時候照著代碼講解好了”，這是一個非常錯誤的思想。因為團隊成員的技術領域是不同的，其他人不一定可以看懂你的代碼，但如果你能把自己的思路變成一種流程圖或者各種表格展現方式，然后再經過你的講解，其他人就相對畢竟容易理解你的思路，發現其中的問題。所以，文檔作為團隊交流中的一個公共語言，是必須要磨練熟練的，關于文檔的能力，請您參看"為啥開發的文檔能力是核心競爭力之一”。下圖是本人和一個團隊成員就這個文檔問題的交流溝通，通過代碼交流會這種培訓形式，提升他們的團隊協作意識和能力。

通過技術交流會，可以加強團隊成員之間的理解，是一個團隊成員之間相互教育的過程。比如UI和產品設計前端產品的時候，很多時候是不知道或者不理解技術上存在的困難的。通過技術交流分享，前端程序員可以講解一些前端設計為啥不能實現的原因，以及今后產品設計需要注意的地方，比如，為了提升前端性能，不能使用大圖片，最好使用文字按鈕，使用圖片自動拉伸功能等。開發和產品之間交惡的故事很多，根本上還是大家不能相互了解和理解對方工作的原因。

通過技術交流會，可以發現一些設計上的潛在問題，把問題扼殺在設計階段，而不是應用了以后才發現。當然有些問題是必須具備豐富的實戰經驗才能發現的，但發現一些總比沒有發現要好，而且這種能力也是需要時間來逐步鍛煉的，不是一下子就能實現的。下面結合2個實際案例，討論一下這個問題，一個是洗車機嵌入式編程問題，一個是消息隊列使用問題。嵌入式編程部分涉及到外包團隊，他們在協議設計階段，沒有考慮到模塊升級和IP地址遠程變更問題，導致后續真機測試和嵌入模塊升級都很麻煩，每次都需要人親自跑過去。

?

分布式系統在設計階段一定要考慮自動化升級和自動化測試問題，因為是外包團隊，所以他們設計協議之前也沒有跟我們仔細交流，導致沒有幫助他們發現這個致命的問題。

還有一個案例是公司后臺程序員的問題，居然不知道自動創建隊列，每次服務重啟，都需要手工創建消息隊列。該程序員表達思路一直不是很清晰，每次交流文檔思路也混亂，自己也缺少精益求精的態度，在本人看來，每次手工創建隊列，這個難道不麻煩嗎？自己操作幾次也該發現這個不方便了吧，如果當初他能夠提出這個問題，也就能幫他把這個問題消滅在設計階段了，也不至于其他后臺成員花半天時間來查找問題了。

上面兩個案例中，開發本身都缺乏測試思維，想當然的認為發生概率不高，就不重視，甚至沒有提出潛在問題的意識，最后導致后續開發，測試和維護成本的提高。因為技術領導不可能，也沒有時間去時時刻刻監控團隊每個人的工作，所以就需要培訓團隊提出問題的意識，通過技術交流會，不斷的去復盤之前出現的問題，讓大家去思考，怎么在今后的工作中，避免類似問題的出現。讓大家有質量的意識，不要想當然的自己認為是低概率事件，就去忽略，起碼應該把問題提出來，讓大家討論，讓技術領導幫助分析利弊后再決定。這樣，一方面可以大大降低團隊的開發成本，另一方面也可以鍛煉自己思維的嚴密性。

代碼交流會是發現人才的機會，讓每個人的思路經常暴露在團隊的眼光之下，哪些人思路縝密，思路活躍，做事態度積極，就一覽無余了，可以是技術人員晉升的一個非常客觀的指標，讓公司的績效評定更加公平合理。下面舉一些在代碼討論會期間發現的重大的隱性設計問題，這些問題被消滅在萌芽階段，大大節約了企業的開發成本和后續的維護成本。一個程序員在實現”可提現金額”需求上面使用了大SQL計算，導致每次查詢都需要重復計算，而且JOIN了多個表，雖然這些表現在數據量不大時，不能體現出來性能問題，但交易表是非常容易快速增長的表，后面會有明顯的性能瓶頸。如果后期發現再修改，不但影響正常業務，而且處理數據兼容問題也是比較棘手的。當時，為了讓該程序員心服口服，本人讓他制造幾百萬條虛假交易數據，測試一下效果，不但很好的培訓了后臺程序員，而且也為企業節約了成本，贏得了寶貴時間。

怎么開好代碼討論會

代碼交流會一定要解決實際問題，不能停留在形式上面，去討論團隊正在做的事情，存在什么問題，怎么樣可以做的更好，或者需要引進什么新技術來解決當前的問題。開了幾次代碼討論會以后，大家感覺到沒有東西可以講了，然后就去網上找了一些時髦的但不相關的技術來講，幾個甚至去大講Swift和Kotlin，和現在使用的技術和工作離得太遠太遠。本人及時制止了這種情況蔓延，這完全是形式主義，不需要對自己工作認真思考，到網上抄抄就可以完成任務，對大家都是浪費時間。經過幾次對優秀者進行表揚鼓勵，對敷衍者指出批評，形式扭轉了過來，大家開始學會去認真思考自己的工作。很多時候，我們沒有發現問題，是因為我們沒有提升自己的標準，沒有去仔細發現問題，如果沒有問題，豈不是說明已經非常非常優秀了嗎？但既然已經非常非常優秀了，為啥還總是出那么多問題呢？我告訴大家，去認真思考，去向做的好的人學習，把討論會當成提升自己的機會，而不是負擔。

開好交流會一定要持續鍛煉大家的表達能力和寫文檔的能力，否則開會都講不清楚問題，重點問題不知道講，非重要問題講個不停，浪費時間。多數開發技術人員在這個方面都非常差，所以這種能力是需要持續的有意識的培養的，不是講幾次課就能夠解決的，具體對這方面的論述，請您參看”為啥開發的文檔能力是核心競爭力之一”。

交流會需要有一個非常好的技術領頭人，能夠引導和激發大家，能夠及時發現問題解決問題，讓大家在交流會中感覺到持續成長，才會有持續的興趣投入到里面來。

總結

軟件開發是一個極其需要團隊協作的工作，交流就是提升大家協作的能力，讓團隊協作能夠持續提升，效率持續提升，所以，任何優秀的技術團隊都應該重視技術討論會。

總結

以上是生活随笔為你收集整理的怎么开好代码交流会的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。