Есть простая привычка, которую я считаю очень эффективной для избежания ошибок при кодировании: проверять свои изменения перед фиксацией. После того, как я внес изменения и провел тесты в последний раз, и все кажется готовым, я делаю различие, делаю вдох и, с более рефлексивным мышлением, просматриваю то, что меняю. Нравится ли мне то, что я изменил? Чего-то не хватает? Есть ли что-то ненужное или это должно быть частью другого изменения?
Я также просматриваю свои изменения, возобновляя работу после перерыва. Что я делал до сих пор, что я упустил ... все это имеет смысл?
Визуальный инструмент, который показывает, что изменилось и как, который определяет переупорядочения, а не показывает их как удаления, вставки и т. Д., Может сделать эту задачу намного проще и эффективнее, но на самом деле, с некоторой практикой даже простые текстовые различия работают хорошо.
Это своего рода проверка кода, но это не то же самое, что проверка кода другими людьми или парное программирование - на самом деле, я люблю самостоятельно проверять подобные изменения и при парном программировании.
Обзор, сделанный другими, дает больше перспективы и служит лакмусовой бумажкой для ясности ... Самостоятельная проверка не даст мне этого, но помогает убедиться, что я намеренно внесены в свои изменения, и экономит время всех, потенциально повышая качество моих представлений .
Парное программирование постоянно приносит нам пользу от обзора кода, но два или более программиста все еще очень способны что-то упустить. Кроме того, во время кодирования люди более склонны сосредотачиваться на деталях, в то время как рецензирование имеет тенденцию расширять представление о более широкой картине.
Я мог бы, конечно, просмотреть свои изменения после фиксации, но это добавляет шума в процесс ... некоторые вещи говорят о «преждевременной фиксации», как серия фиксаций, исправляющих вещи, пропущенные в первой фиксации (из этой серии).
На самом деле для меня это сводится к тому, чтобы брать на себя ответственность за то, что я делаю с исходным кодом команды :)
