配對編程與評論

Question

多年來，我發現綠色程序員傾向於閱讀註釋而不是代碼來調試問題。

是否有一個人在代碼編寫者的批准下長期提高代碼質量時記錄其他人的代碼（反之亦然）？

這是一個好主意？

撇開：我正在尋找獨立編程和結對編程之間在預算方面的中間地帶。

Answer 1

人們傾向於尋找最簡單的問題解決方案。如果有可用的「人類」描述，它可能會在讀者深入研究深奧代碼之前被利用。 IOW，無論程序員是多麼綠色，這些評論通常都會首先考慮。

評論應該儘可能地保持。不幸的是，它們很容易變得陳舊（因爲它們不能被編譯器驗證）。因此，他們應該保持在合理的最低限度，因爲最終，代碼本身是唯一可以信任的真實評論。

至於誰應該寫評論，取決於評論的寫作水平。例如，在較高層次上，評論應該描述模塊的外部行爲，並且可以由更多人寫出。然而，在內部，評論應該解釋各種代碼塊的意圖。這樣，讀者就更容易收集代碼的風格。這些評論應該由編碼員編寫。

Answer 2

我發現，「一對編程」在一個人編寫代碼而另一個編寫單元測試（並排工作，以便他們可以看到彼此正在做什麼）時效果最好。你也可以偶爾交換角色。

Answer 3

如果原作者沒有記錄代碼，則運行錯誤解釋算法的風險較高。在我看來，唯一比沒有充分記錄的代碼更令人沮喪的是沒有正確記錄的代碼。

你不妨試試這個方法：

• 與沒有參與編程的工作量開發商進行代碼審查。
• 在沒有代碼作者的實際存在的情況下執行審閱。只是審閱者，來自源代碼控制的代碼副本和書面文檔。
• 如果審閱者在沒有外界幫助的情況下無法合理理解代碼，則沒有充分的文檔記錄，應該將其提供給作者。
• 根據需要重複。

Answer 4

我傾向於先寫評論，之後立即寫代碼或者在時間或者時間上並排。當我寫下我的評論時，代碼變得非常清晰（比寫作評論時口頭表達我的想法的事實）。我不喜歡評論我沒有寫的代碼。每當我回來修改代碼時，首先閱讀原始評論，然後思考新評論，編寫代碼並將代碼並排編寫。

Answer 5

當助手做廣泛的範圍思考（即我們試圖完成什麼）和鍵盤牛仔做細節範圍思考時，我發現它最有效。我不認爲評論與它有任何關係。