工程師問責制和代碼審查流程

Question

在您的「企業」工作環境中，工程師如何追究代碼檢查和單元測試責任？你遵循什麼流程（正式方法或定製流程）來確保軟件的質量？你或者你是否嘗試過實施一個開發人員「簽收」工作表的交付物？

在此先感謝！

更新：我忘了提及我們正在使用代碼協作者來執行我們的檢查。問題在於讓人們「得到它」並在一羣核心人羣之外購買。正如stalbot在下面指出的那樣，這是一種文化變革，但問題在於，您如何改變您的文化以促進評估/單元測試等質量舉措？

Answer 1

如果你想確保每一個變更表被審查，前籤，然後你可以有你的源代碼管理工具拒絕未經審覈的簽入。例如，觸發器可以在簽入評論中拒絕沒有「CodeReview：」的簽入。儘管人們仍然可以說謊，但他們也可以被追究責任。

如果你想確保每一個變更表被審查，後籤，那麼你可以看到，如果代碼合作者將很好地與你的源代碼控制系統中的每個籤（推後播放，並自動進行審覈任務或拉;無論什麼作品）。之後，使用代碼協作者具有的任何「禮貌煩惱」特徵，以確保評論實際上得到完成。

如果你希望人們在回顧只有一些籤，不所有簽入，然後運氣好這一點。

Answer 2

我們嚴重依賴於ITIL概念。儘管我們不需要ITIL提供的全面的ITSM，但我們已經實施了一些流程，這些流程從ITIL中的一些最佳實踐中吸取，特別是在變更管理和發佈管理領域。

代碼評論是我們RM策略的一部分。隨着更改或新代碼通過我們的RM流程，很多人的目光都在關注它。最終，發佈經理會對審批或返工進行調用，並記錄所有這些（我們使用TFS和SharePoint）。正式的代碼審查由發佈經理和他選擇的技術團隊來保存。對於發佈候選人的主要開發人員負責遵守標準，功能和已完成測試計劃的驗證。如果不符合質量標準，交付物將被拒絕，項目進度表會更新以反映返工情況。

是的，這是非常重的。我在政府工作，我們有複雜的法律要遵循，特別是在稅收，ADA合規等方面。

Answer 3

我們有一個很酷的設置。預計編碼人員將在簽入之前測試他們的代碼，以確保它不會破壞構建並在他們有意義的地方編寫測試，但是不需要高覆蓋率。

複雜的方法有望被評論。

在階段結束時，代碼由整個團隊審查。

Answer 4

•我們公司使用同行代碼審查。我們將它們作爲Over-The-Shoulder評論進行操作，並邀請團隊的測試人員參加會議，以更好地瞭解這些更改。我們使用需要簽入的源代碼管理軟件，簽署代碼審查規則。沒有什麼大的，只是另一個開發人員的名字，已經審查了代碼。

•代碼審查有一定的好處，因爲幾項研究已經能夠證明。對於我們公司來說，很明顯代碼質量隨着支持電話數量的減少以及報告的錯誤數量的減少而增加。注意：這裏的一些好處是實施Scrum和放棄瀑布的結果。更多關於Scrum的內容。

•代碼審查的好處可以是更穩定的產品，更適用於結構和編碼標準的可維護代碼，它允許開發人員更專注於新功能而不是「消防」錯誤和其他生產問題。如果代碼審查是「正確」的，那麼確實沒有任何缺點。更多關於下面的「正確方法」。

•在實施代碼審查時需要克服的一些障礙是「大哥」正在關注我的想法，而沒有完美代碼的想法意味着酷刑和痛苦。讓開發人員相互信任是很困難的，尤其是當它涉及「啄食順序」或「比你更神聖」的態度，並將你的努力工作放在顯微鏡下時。信任是解決這些問題的關鍵。開發人員必須相信他們不會因同行或管理層因代碼錯誤而受到懲罰。它發生在每個人身上。記下問題，解決問題並繼續。

Scrum 使用Scrum方法的好處之一是開發週期（「sprint」）很短。 「衝刺」的時間框架取決於什麼對您的組織最適合，並且需要一些試驗和錯誤，但實際上不應超過四周迭代。好處是它需要開發人員進行日常溝通，並在項目的早期進行溝通。這是最初由我們的開發部門採用的，由於scrum的好處非常深遠，已經擴展到了我們公司的所有領域。有關更多信息，請參閱：http://en.wikipedia.org/wiki/SCRUM或http://www.scrumalliance.org/。由於開發迭代更小，代碼審查過程會審查較小的代碼段，使得審查更可能發現問題，而不是幾個小時或幾天的正式審查。

「正確的方式」 代碼評論完成「正確的方式」是完全主觀的。不過，我個人認爲他們應該是非正式的，肩負式的評論。審查中的所有參與者都應避免以「爲什麼這樣做？」或「你在想什麼？」等陳述，親自攻擊被審查的人員等。這些類型的評論減少了同行之間的信任，導致以爭論最好/正確的方式來編碼解決方案。請記住，開發人員不認爲或編碼完全相同，並且有許多問題的解決方案。 只是在肩上評論的一點點澄清;這些可以通過遠程桌面共享（在此選擇風味）或親自進行。但是，它們不應僅限於開發人員。我們通常會邀請我們的整個scrum團隊，每個團隊由兩名開發人員組成，一個測試人員，一個文檔人員和產品負責人。所有非開發人員都可以更好地瞭解所做的更改或新功能。他們可以自由提問或提供意見，但不能作出編碼決定或評論。這是有效的，因爲某些問題會被要求，可能會改變項目的方向，因爲最初的需求可能已經錯過了一個場景，但這正是敏捷所關注的變化。

建議 我強烈建議研究Scrum和代碼審查，然後強制他們。爲每個人制定基本規則，並將其作爲文化的一部分來實現，以實現更高質量的產品。它必須成爲您的文化的一部分，因此它是自然過程的一部分，並在各個層面進行整合，因爲它是一種模式轉換，從質量差，錯過最後期限和挫敗感到更好的產品質量，更少的挫敗感和更多準時交付成果。

Answer 5

我們使用三種基本規則

1）當不存在單元測試的開發人員負責在代碼中修正錯誤。在進行測試的情況下，打破測試的人負責修復測試。

2）代碼評論。有一些代碼審查的氣味是一個很好的警告標誌，超過防禦性和責怪重定向是最常見的兩種。

3）沒有電子郵件代碼，JAR或配置文件。一切都在scm中。

Answer 6

配對編程。工作項目有一個合作伙伴的必填字段，您與工作人員配對

Answer 7

創建文化第一次嘗試定義您的標準和值，最重要的是讓他們知道。

然後僱用相信他們或能夠適應他們的人。不要僱用與公司價值觀毫無關聯的人。

確保那些尊重這些價值觀並表現出改進的人得到「回報」和「正確」認可並看作模特。不要忘記，許多人並不都是爲了錢。

不要猶豫，採取適當的措施再次對那些誰不履行職責，但確保他們知道他們。並讓他們對自己的行爲負責。 允許人們使用任何新的責任。

Answer 8

要改變文化是很重要的。仍然有一些方法可以改變。

1. 建立關於代碼審查和代碼審查工具重要性的意識。可以使用培訓課程來完成。

2. 激勵員工：給代碼審查帶來一些回報。

3. 更改過程：確保代碼審查應該發生並正確。可以使用清單和發佈過程的一部分來完成。

4. 不要試圖完全改變。慢慢地引入更新的更改。創建小組來觀察和討論代碼審查過程中的變化。

5. 提供解決方案而不是創建問題。過程不應該是開銷。它自動來。爲與這個過程有關的人們提供解決方案。