石騫
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）也是值得一探的。