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

為什么要開代碼交流會

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

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

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

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

?

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

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

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

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

怎么開好代碼討論會

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

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

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

總結(jié)

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。