Вносите изменения в код понемногу

[sbnur]

Хорошие картинки — веб-программирование всегда мне напоминало путешествия в горно-лесистой местности, где когда велись разработки

[kaftanati]

Спасибо за перевод (без пометки перевода). Долго не мог понять, что меня отвлекает при прочтении. Картинки, текст, подписи, все не то. Оказалось курсивная «т» в цитатах, оформленных через картинку, — она имеет отличный от других букв наклон. Что это за шрифт?

[raveclassic]

Господи, я ж теперь спать не буду. Вы зачем это сказали?

[franzose]

Garamond вроде бы. Там и «а» тоже отличается)

[splav_asv]

И «п». Но вроде бы всё дело именно в том, что наклон основных вертикальных штрихов тот же, а визуально из-за наклона соединяющих частей он кажется другим.

[SoulAge]

Меня больше волнует, это баг или фича..)

[HKA]

Запускаю

$$('img, .sidebar_right').forEach(e => e.style.display = 'none')

в консоли Хрома — и никаких отвлечений ;)

[fogone]

Сокращать размер пулреквестов — это хороший совет, но временами просто нереализуемый, если дело касается какой-то сложной фичи. Однако, стараться максимально разбить задачу на изменения, которые можно независимо выкатить, это действительно помогает и хорошему ревью и лучшему пониманию изменений и более простому отслеживанию проблем.

[fogone]

Правда есть и обратная сторона. Из за желания сделать пулреквесты небольшими, можно начать избегать рефакторингов по ходу разработки или просто «лишних» изменений, которые были бы уместны, улучшали структуру, читабельность, но не были сделаны, потому что это лишние строки кода. Я уж не говорю про перемещение файла в другой пакет или вынос внутреннего класса наружу — это вообще может стать катастрофой для пр-а «в десяток строк».

[VolCh]

Для рефакторингов отдельные реквесты, нет? И это как раз явное исключение, когда реквесты могут быть большими — небольшое ядро рефакторинга вроде собственно перемещения файла, и куча однотипных изменений ссылок на этот файл.

[fogone]

Большой запланированный рефакторинг — да. А вот если ты добавляешь класс для реализации какой-то фичи и видишь, что хорошо было бы положить его вместе с некоторыми старыми классами в отдельный пакет, то тут ни о каком отдельном пр-е и говорить не приходится. И вот тут ты и думаешь: да, что-то много «лишних строк ревью — не буду в пакет выносить». И это только пример, таких ситуаций может быть много. Хотя, хочу заметить, что если рефакторинг можно продумать заранее, лучше конечно это сделать отдельным реквестом — я говорю лишь о том, что этот подход — палка о двух концах, где с другой стороны это бессознательное желание сократить количество измененных строк иногда даже в ущерб реальным потребностям разработки.

[VolCh]

Обычно в таких ситуациях или сначала доделываю фичу, а потом рефакторю, или стэшу текущие изменения, рефакторю и доделываю фичу уже в новом окружении.

[fogone]

Я не сказал, что способов обойти такие ситуации нет, я говорю лишь о том, что это может мешать разработке или тормозить её. Ведь если вы сделали рефакторинг до своих изменений, то их нужно отравить на ревью и вероятно от этой же ветки отпочковать и свой код, а возможно и еще какой-то код, который можно успеть сделать до прохождения ревью первого пр-а (по тому же принципу, что вы сами описали). А потом в ревью первого реквеста найдут нюанс, исправление которого повлечет за собой изменения во всех отпочкованных ветках, потому что по сути это всё были связанные изменения — а синхронизация и мердж этих веток это отдельные трудозатраты. Если же откладывать «на потом», то это с большой вероятностью может и вообще быть не сделано, да и нужно понимать, что отдельный реквест для рефакторинга тоже нужно посмотреть — это не бесплатно. И я описываю не какой-то придуманный кейз, а реальный случай из жизни. Еще раз хочу заметить, что я говорю лишь об «обратной стороне» этой практики. И о том, что в попытке сэкономить время и силы ревьювера, иногда бывает тратишь несравнимое количество своего времени и сил. Как и везде — нужно чувствовать грань.

[reforms]

Про обратную сторону ещё смело можно добавить самое главное — не видно всей картины изменений сразу, а это может привести в конечном счете к неверно выбранному пути решения основной задачи. В общем как всегда, Советы советами а жизнь диктует свои правила)

[reiser]

ваши мучители будут требовать непомерных

Откуда цитата?

[funca]

Your tormentors will demand baffling, seemingly-trivial concessions

Причем, в оригинале подписи к картинкам — текстом.

[tagir_valeev]

За ссылку на оригинал спасибо, но какая-то жесть с переводом, потому минусик.

[funca]

Объем операционных расходов на единицу изменения содержит в себе нехилую константу, которая не зависит от размера ченжа. Менеджмент, QA, DevOps и т.п. Поэтому слишком мелкие изменения выливаются в конечном счёте в тонны операционных расходов не единицу изменения. Нужен какой-то баланс.

[samizdam]

Качество перевода удручает.
Мысль автора достаточно банальна — возможности человеческого восприятия весьма ограничены.

[SAG2010]

«Even the strongest cultures have reviews that devolve into Maoist struggle sessions about whitespace.» я бы перевел как-то так «Даже у самых сильных команд случаются код-ревью, которые превращаются в философские споры о пробелах».
«Даже в командах с сильнейшей культурой разработки бывают проверки кода, которые превращаются в охоту на ведьм пробелы.» — это вообще PROMTом попахивает, имхо :)

«Просмотр сотен строк на наличие ошибок — это эффективная, необременительная процедура. Она не предотвращает всех проблем, и не создаёт новых. Этот процесс представляет собой разумный баланс между возможным и практичным.» — здесь по-моему тоже исковеркан смысл оригинального текста. dozens — это дюжины, а не сотни.

Предлагаю заменить на «Просмотр нескольких десятков строк кода — довольно эффетивная практика, которая, к тому же, не так обременяет разработчиков. Она не спасет вас от всех имеющихся ошибок в коде и даже не исключит на 100% вероятность появления новых. Но „маленькие“ код ревью помогут достичь баланса между пользой и затраченными усилиями.»