石騫

2016年3月17日

13124781413

現狀和建議概述

目前觀察到的情況是開發人員之間的技術交流較為欠缺、程式碼的自動化測試水平不高，這兩者又會影響開發人員產出的質量。

日常工作中開發人員之間的交流不多，即使有也多數是關於如何出成果的，關於出成果的方式，出的成果的質量，改進的方面、方式等方面的討論還比較少，積累下來的知識也非常少。交流無疑能幫助開發人員進步，如何促進交流是問題所在。

另一方面是目前開發人員的程式碼的測試的量少、自動化程度低。具體表現在程式碼邏輯測試不夠嚴謹、UI測試靠測試人員手點、效能測試較原始（使用的指標非常有限，可能多數都是計時和看工作管理員的記憶體佔用）。

促進開發人員之間的技術交流應當從從新人培養開始，通過引導團隊成員結對進行程式碼評審培養技術討論的氛圍，以小組內程式碼評審進一步活躍氣氛，再通過專題技術交流昇華。將此過程中的收穫整理進新人培訓的教材，亦可作為部門的知識庫，不斷積累，不斷深化，形成一個從新人到專家再反饋給新人培訓的良性迴圈。

提高測試覆蓋率主要考慮”用程式碼來測試程式碼”。其主要實現方式有：

l  鼓勵開發人員編寫單元測試並嘗試向測試驅動開發過渡

l  進行自動化UI測試方面的嘗試

l  探索效能測試工具

下面將展開討論如何促進交流。提高測試的自動化程度的內容瞭解得還比較少，將放到專題交流一節中簡要討論。

促進交流

活躍的技術討論氛圍不是一天就形成的，可以考慮以兩兩結對的程式碼評審為入口，多次結對評審有助於撒下交流與合作的種子，逐步擴大到小組內可以進一步鞏固、活躍已有的氛圍。討論的內容可從具體的程式碼評審開始，逐步擴大到大家關心的各種技術、思路。在這條逐步推進的路上，新人培訓是第一站。

新人培訓

對於每年的新入職開發人員的培訓的建議主要有：

1.        逐步優化講課的教材

2.        給新員工多一些時間去向自己的導師學習，尤其是如何寫程式碼。

逐步優化講課的教材

以下問題的存在會影響對開發人員進行集中培訓的效果：

l  在工作中要用到的知識種類繁多，要掌握的水平也各不一樣，

l  上課的新員工的基礎各不相同，對知識的接受能力各異

l  講師不清楚課上的學生的水平，即使知道了也還是難以選擇合理的講課深度

一份實用的教材能為日後新人的自學提供明確的指導。教材中應當提供：

l  集中培訓時講到過的內容：公司的部門組成及各自的職責與合作方式，公司的產品體系、相互之間的關係，部門內的開發流程、程式碼規範、常用工具、共享資源的儲存位置等

l  較合理的大綱，為新人們指出經過以後的學習，各門技術應該達到的水平（類似崗位定級標準）；

l  參考資料：部落格、論壇地址、書單（如：

n  《程式碼大全》

n  《重構:改善既有程式碼的設計》

n  《測試驅動開發的藝術 (圖靈程式設計叢書 59)》

n  《單元測試的藝術(第2版)》

n  公司裡相關領域的高手的名字等資訊

l  公司員工的知識積累

教材有多方面的作用：

1.        規範新人培訓工作，

2.        每年的講課內容都可以在去年的基礎上有所優化，可以穩步提高新人培訓的質量，

3.        教材中還可以加入員工們在平常工作中總結出來的技巧、發現的知識，經過長時間的積累後，教材不光可以給新人培訓用，還可以充當開發人員手冊，這樣我們不光有了ADF這樣的程式碼庫，還有了關於開發工作的知識庫。

跟導師一起評閱程式碼

新人的編碼習慣、編碼風格、技術能力等都有較大的塑性，有效的培訓能較大幅度地提高他們的能力，而新人能力水平、學習能力、學習方式的差異是對新人的培訓強調一對一或者”小班”教學的主要原因。因此，新人在集中培訓後跟導師學習的經歷十分重要。而且這意義不只體現在新人的進步上，對導師來說，最好的學習是講課，講清楚一杯水的內容需要一桶水的知識儲備，能帶好新人才是其真正具備相關能力的證明，用心帶新人的導師肯定也會有所斬獲的。

程式設計師最直接的產出就是程式碼，程式碼水平是其能力的直接證明就是其程式碼水平。新人嚮導師學習的最直接方式是新人與導師結對程式設計，具體地有3種做法：

1.        一起寫新的功能；

2.        一起評閱並修改新人自己的程式碼；

3.        一起評閱別人寫的程式碼

一起寫新程式碼的過程中新人可以看到高手是怎樣一步步展開並表達自己的思路的。

一起評閱自己的程式碼的過程中可以直觀地看到自己的問題，觀摩導師分析、修改程式碼的過程就是學習的過程。有效修改後的程式碼往往可讀性更好，程式碼邏輯更清晰，執行時也更流暢，這些方面的體驗的提升能讓新人直接感受到優秀的程式碼的威力，對於提高其追求優質程式碼的熱忱當有所助益。

一起評閱別人的程式碼則可以讓其學會分析、理解別人的程式碼，從中發現可借鑑之處、可改進之處。

結對評審

新人與其導師一起評審程式碼是結對評審的一種。另一種結對評審發生在能力相近的兩位同事之間，地點就在其中一位的工位上，評審的方式類似於新人與其導師一起評審。這兩位同事應當對程式碼重構、面向物件的設計等知識有所瞭解，並且也興趣進行這樣的實踐。找到一對或者多對這樣的同事並引導他們進行評審，需要管理層的配合。

對於評審時機的選擇：應當鼓勵開發人員多進行結對評審，磨刀不誤砍柴功，交流的過程能提高彼此的程式碼水平，編寫優秀的程式碼能節約時間。

只選2位同事是保持評審活動輕便可控。

要求兩者能力相近是希望在能力差距不大的情況下，參與評審的兩位都能暢所欲言而不用因為怕在對方面前出醜而不敢說話。

讓他們在工位進行討論，一方面是當兩人出現分歧時可以很容易地在周邊找到第三方加入以儘量解決分歧，另外，就在工位上進行討論，更容易帶動周圍的其他同事。

小組評審

在小組內的成員都多多少少地參與過結對評審，對程式碼評審的作用有了認識，對其認可度也提高了之後，可以考慮讓小組內經驗較為豐富的開發人員發起組內的程式碼評審。

小組評審的流程和時長、人數等問題可以留待開發人員自行探索。

一般來說，結對評審的程式碼選擇參評人自己的程式碼會比較有針對性。而小組評審的時候，考慮到如果程式碼被找出很多不好的地方，負責的開發人員可能會覺得不好意思所以評審程式碼時可以考慮匿名評審也就是說不讓參評人知道被評程式碼出自誰手。另外，為了提高大家的參與積極性選擇評審程式碼時可以考慮從小組成員用得較多的程式碼開始，比如系統的框架程式碼，甚至是ADF的程式碼，也歡迎開發人員主動提出要小組評審自己的程式碼。

評審過程中大家意見不統一很正常，如果主持會議的“專家”能提出較權威的解決方案是極好的，即使不能也很正常，重要的是這個過程中大家都在積極地思考與總結。

在小組評審的過程中，可能會出現一些”跑題”的情況，比如從對當前程式碼的評審跳躍到工具的選擇上或者某種新方法、新技術的適用性等。剛開始小組評審時，適當包容這些”技術性”的跑題，這樣的一些”題外話”能活躍氣氛，也能為以後開展專題技術討論蒐集議題。

可以請參評的某位成員將評審過程中用到的技術、方法記下來，在評審結束後，儘快將其更新到教材的相應章節中去。（教材的更新維護可能需要一位專家從整體上把控內容還需要普通員工完成日常維護，可能會花去不少精力，具體如何還沒什麼成形的想法）

專題討論

隨著技術交流的不斷深入，團隊內可能會出現集中討論某些問題的需要，這時可以在小組內舉行專題討論會，交流的內容不再侷限於程式碼，而是大家感興趣的某個技術點或者某種方法論等等，只要是技術類的討論就行。

前面提到的擴大測試覆蓋面的方法都還是隻有一個粗略的想法，相關的內容可以考慮作為交流的議題。

測試驅動開發

單元測試、測試驅動開發強調的是用單元測試來保證程式碼質量，先編寫單元測試，再編寫程式碼讓測試通過，再重構程式碼，”紅綠構“一個迴圈，不斷往復。”紅”是指編寫完單元測試還沒寫相關的實現程式碼之前單元測試執行會失敗，其進度條是紅色的，“綠”是指編寫相關的實現程式碼之後，單元測試能通過，進度條為綠色的，構則是指重構，有了單元測試做保障，可以放心地修改程式碼的內部實現而不修改程式碼的功能。

具體實施起來還是有許多細節要考慮的，如何用單元測試來測試原有的大量程式碼？編寫單元測試時可以做哪些取捨？哪些應該測哪些不需要測？使用存根或者模擬物件時有沒有比較好用的測試框架，具體用法是怎樣的？針對我們的業務情況，有沒有哪些地方要特殊注意的？諸多問題目前我都無法解答，希望在以後的技術交流中大家能提出好的方案，不斷實踐不斷優化。

自動UI測試

之前跟羅雨溝通過，測試人員想做UI的自動測試是很複雜的，他們基本只能通過滑鼠所在的畫素位置來定位UI，當解析度發生變化或者視窗大小變化時原有指令碼的有效性都打折扣。MSDN裡的資料（https://msdn.microsoft.com/zh-cn/library/dd286726(v=vs.110).aspx）能否更好地解決這個問題，有沒有別的更好的解決方法，甚至這樣的測試有無必要，都需要進一步的討論、嘗試。

效能測試

按照2/8法則，80%的情況下開發人員的程式碼基本只要能完成業務邏輯就能交差，對效能並不會有太多要求。然而，剩下的20%的情況正是開發人員核心能力的體現。對我們的程式，應該關注哪些指標（GC次數，，使用怎樣的流程和工具去進行效能測試，又有哪些調整的方法和思路，同樣的MSDN裡也有一部分資料（https://msdn.microsoft.com/zh-cn/library/z9z62c29(v=vs.110).aspx）也是值得一探的。