Comments 20
Garamond вроде бы. Там и «а» тоже отличается)
$$('img, .sidebar_right').forEach(e => e.style.display = 'none')
в консоли Хрома — и никаких отвлечений ;)
Для рефакторингов отдельные реквесты, нет? И это как раз явное исключение, когда реквесты могут быть большими — небольшое ядро рефакторинга вроде собственно перемещения файла, и куча однотипных изменений ссылок на этот файл.
Обычно в таких ситуациях или сначала доделываю фичу, а потом рефакторю, или стэшу текущие изменения, рефакторю и доделываю фичу уже в новом окружении.
Про обратную сторону ещё смело можно добавить самое главное — не видно всей картины изменений сразу, а это может привести в конечном счете к неверно выбранному пути решения основной задачи. В общем как всегда, Советы советами а жизнь диктует свои правила)
ваши мучители будут требовать непомерных
Откуда цитата?
За ссылку на оригинал спасибо, но какая-то жесть с переводом, потому минусик.
Объем операционных расходов на единицу изменения содержит в себе нехилую константу, которая не зависит от размера ченжа. Менеджмент, QA, DevOps и т.п. Поэтому слишком мелкие изменения выливаются в конечном счёте в тонны операционных расходов не единицу изменения. Нужен какой-то баланс.
Качество перевода удручает.
Мысль автора достаточно банальна — возможности человеческого восприятия весьма ограничены.
«Даже в командах с сильнейшей культурой разработки бывают проверки кода, которые превращаются в охоту на ведьм пробелы.» — это вообще PROMTом попахивает, имхо :)
«Просмотр сотен строк на наличие ошибок — это эффективная, необременительная процедура. Она не предотвращает всех проблем, и не создаёт новых. Этот процесс представляет собой разумный баланс между возможным и практичным.» — здесь по-моему тоже исковеркан смысл оригинального текста. dozens — это дюжины, а не сотни.
Предлагаю заменить на «Просмотр нескольких десятков строк кода — довольно эффетивная практика, которая, к тому же, не так обременяет разработчиков. Она не спасет вас от всех имеющихся ошибок в коде и даже не исключит на 100% вероятность появления новых. Но „маленькие“ код ревью помогут достичь баланса между пользой и затраченными усилиями.»
Вносите изменения в код понемногу