Всегда было любопытно узнать, что и как думают кодеры за океаном? Логично предположить, что техническое мышление и основные процессы должны быть схожими с российскими разработчиками. Под катом возможность сравнить наши походы с «тамошними». Если у вас все хорошо с английским, оригинал публикации и самого автора можно найти по ссылке.
Разработка веб-приложений — это молодой и малоизученный вид деятельности. Инструменты для генерирования и компилирования кода широкодоступны, используются относительно давно и всегда под рукой у программистов. Идея заключается в том (такова тенденция), чтобы брать по одному-два инструмента, запускаемых из командной строки, и отталкиваясь от их возможностей выполнять какую-то часть работы.
Git предоставляет способы решения любых мыслимых проблем со слиянием кода. Также там есть поддержка произвольных сложных схем ветвления и тэгирования. Многие обоснованно считают, что целесообразно всегда использовать эти функции.
Это заблуждение. Следует начать с процедур, которые возымеют эффект уже в процессе текущей работы, и двигаться в обратном направлении, к тому, что было сделано при разработке. Даже с учётом создания выгружаемых MVP (минимальных жизнеспособных продуктов), в конечном итоге в действующем бизнесе большую часть стоимости ПО составляют операционные расходы, а не затраты на разработку.
Приведу пример, который очень хорошо работает на практике с точки зрения операционной деятельности: код нужно развёртывать в production небольшими фрагментами (единицами кода). Полагаю, размер таких фрагментов должен измеряться в десятках строк, а не в сотнях. Вы увидите, что, приняв такой подход за основу, от вас лишь потребуется выполнять только относительно простой контроль изменений.
Ваш последний шанс избежать ошибок в разрабатываемом коде — как раз перед тем, как вы запушите его, поэтому многие команды разработчиков считают хорошей идеей проводить стандартные (как бы) проверки кода (code review). Это не ошибка, но эффект от затраченных усилий невысок.
Проверка сотен строк кода — это серьезная задача. Она требует серьёзных затрат рабочего времени и погружения в процесс. Просмотр больших изменений обычно заканчивается проставлением метки “lgtm” («Думаю, это неплохо»), при этом за суетой небольших исправлений можно не обратить внимание на проблемы более общего характера. Даже в командах с сильнейшей культурой разработки бывают проверки кода, которые превращаются в охоту на ведьм пробелы.
Просмотр сотен строк на наличие ошибок — это эффективная, необременительная процедура. Она не предотвращает всех проблем, и не создаёт новых. Этот процесс представляет собой разумный баланс между возможным и практичным.
Выкатывание больших измененных фрагментов приводит в ужас даже опытных разработчиков. И причина заключается в инстинктивном понимании простой взаимосвязи.
В каждой строке кода с какой-то вероятностью присутствует необнаруженная ошибка, которая всплывёт в процессе эксплуатации. Процесс исполнения кода может повлиять на величину этой вероятности, но не может свести её к нулю. В больших изменённых фрагментах содержится множество строк, и поэтому существует высокая вероятность сбоя при использовании реальных данных и реального трафика. В онлайн-системах код необходимо передавать в работу, чтобы проверить его работоспособность.
Невозможно предотвратить все проблемы в production. Они всё равно возникнут. И лучше пусть это случится, когда мы пушим небольшие изменения.
Многие серьёзные баги в production проявляют себя при выкатывании. Если отсутствует индекс в новом запросе к базе данных на вашей самой большой странице, то, скорее всего, вы быстро получите соответствующее предупреждение. При этом разумно полагать, что ошибка находится в последней версии кода.
В другом случае вы будете устранять небольшую, но вредную проблему, которая существует уже в течение какого-то времени. Ключевую информацию, необходимую для решения этой проблемы, можно получить при её первом возникновении, а также при анализе внесённых с того момента изменений.
В обоих описанных сценариях отладчик имеет дело с изменёнными фрагментами кода. Обнаружение ошибок в таких фрагментах аналогично проверке кода, но только хуже — это проверка, выполняемая по принуждению. Поэтому длительность устранения проблем в production будет стремиться к пропорциональной зависимости от размера изменяемых фрагментов.
Эффективность проверки кода с профилактической целью ограничивает человеческий фактор. Проблемы в релизах неизбежны и пропорциональны объёмам выпускаемого кода. Время, необходимое для отладки, является функцией (помимо прочего) объёма отлаживаемого кода.
Ниже приведён несложный список указаний. Но если отнестись к ним серьёзно, то можно сделать некоторые интересные выводы.
• Ветви кода инертны, и это плохо. Я говорю людям, что я не возражаю против работы в ветках, если им это помогает, и если я даже не могу сказать с уверенностью, что они это делают. Проще удвоить размер ветки, чем выполнить слияние и развернуть весь код, и разработчики постоянно попадаются в эту ловушку.
• Легкие манипуляции с исходным кодом — это нормально. GitHub-ветки замечательно распиарены, но git diff | gist -optdiff также неплохо работает, если речь идёт о десятках строк кода.
• Вам не нужны тщательно продуманные ритуалы Git-релизов. Церемонии, подобные тэгированию релизов, выглядят пустой тратой времени, если вы выпускаете релизы много раз в день.
• Ваша настоящая проблема заключается в частом выпуске релизов. Ограничение объёма выпускаемого кода может притормозить прогресс, если только вы не сможете одновременно увеличить частоту публикаций. Это не так просто сделать, и при этом ваш арсенал инструментов начнёт тяготеть к средствам, заточенным под решение этой задачи.
Это не исчерпывающий список. Если начать с повседневной операционной деятельности и двигаться в обратном направлении, в направлении разработки кода, то это позволит критически осмыслить весь свой процесс разработки. И это только пойдёт на пользу.
Комментарии (20)
kaftanati
10.03.2017 22:49+14Спасибо за перевод (без пометки перевода). Долго не мог понять, что меня отвлекает при прочтении. Картинки, текст, подписи, все не то. Оказалось курсивная «т» в цитатах, оформленных через картинку, — она имеет отличный от других букв наклон. Что это за шрифт?
HKA
17.03.2017 13:17Запускаю
$$('img, .sidebar_right').forEach(e => e.style.display = 'none')
в консоли Хрома — и никаких отвлечений ;)
fogone
11.03.2017 09:15Сокращать размер пулреквестов — это хороший совет, но временами просто нереализуемый, если дело касается какой-то сложной фичи. Однако, стараться максимально разбить задачу на изменения, которые можно независимо выкатить, это действительно помогает и хорошему ревью и лучшему пониманию изменений и более простому отслеживанию проблем.
fogone
11.03.2017 09:35+5Правда есть и обратная сторона. Из за желания сделать пулреквесты небольшими, можно начать избегать рефакторингов по ходу разработки или просто «лишних» изменений, которые были бы уместны, улучшали структуру, читабельность, но не были сделаны, потому что это лишние строки кода. Я уж не говорю про перемещение файла в другой пакет или вынос внутреннего класса наружу — это вообще может стать катастрофой для пр-а «в десяток строк».
VolCh
11.03.2017 11:14Для рефакторингов отдельные реквесты, нет? И это как раз явное исключение, когда реквесты могут быть большими — небольшое ядро рефакторинга вроде собственно перемещения файла, и куча однотипных изменений ссылок на этот файл.
fogone
11.03.2017 14:42+1Большой запланированный рефакторинг — да. А вот если ты добавляешь класс для реализации какой-то фичи и видишь, что хорошо было бы положить его вместе с некоторыми старыми классами в отдельный пакет, то тут ни о каком отдельном пр-е и говорить не приходится. И вот тут ты и думаешь: да, что-то много «лишних строк ревью — не буду в пакет выносить». И это только пример, таких ситуаций может быть много. Хотя, хочу заметить, что если рефакторинг можно продумать заранее, лучше конечно это сделать отдельным реквестом — я говорю лишь о том, что этот подход — палка о двух концах, где с другой стороны это бессознательное желание сократить количество измененных строк иногда даже в ущерб реальным потребностям разработки.
VolCh
11.03.2017 17:10Обычно в таких ситуациях или сначала доделываю фичу, а потом рефакторю, или стэшу текущие изменения, рефакторю и доделываю фичу уже в новом окружении.
fogone
12.03.2017 13:32Я не сказал, что способов обойти такие ситуации нет, я говорю лишь о том, что это может мешать разработке или тормозить её. Ведь если вы сделали рефакторинг до своих изменений, то их нужно отравить на ревью и вероятно от этой же ветки отпочковать и свой код, а возможно и еще какой-то код, который можно успеть сделать до прохождения ревью первого пр-а (по тому же принципу, что вы сами описали). А потом в ревью первого реквеста найдут нюанс, исправление которого повлечет за собой изменения во всех отпочкованных ветках, потому что по сути это всё были связанные изменения — а синхронизация и мердж этих веток это отдельные трудозатраты. Если же откладывать «на потом», то это с большой вероятностью может и вообще быть не сделано, да и нужно понимать, что отдельный реквест для рефакторинга тоже нужно посмотреть — это не бесплатно. И я описываю не какой-то придуманный кейз, а реальный случай из жизни. Еще раз хочу заметить, что я говорю лишь об «обратной стороне» этой практики. И о том, что в попытке сэкономить время и силы ревьювера, иногда бывает тратишь несравнимое количество своего времени и сил. Как и везде — нужно чувствовать грань.
reforms
11.03.2017 18:22Про обратную сторону ещё смело можно добавить самое главное — не видно всей картины изменений сразу, а это может привести в конечном счете к неверно выбранному пути решения основной задачи. В общем как всегда, Советы советами а жизнь диктует свои правила)
funca
11.03.2017 16:10Объем операционных расходов на единицу изменения содержит в себе нехилую константу, которая не зависит от размера ченжа. Менеджмент, QA, DevOps и т.п. Поэтому слишком мелкие изменения выливаются в конечном счёте в тонны операционных расходов не единицу изменения. Нужен какой-то баланс.
samizdam
11.03.2017 19:58Качество перевода удручает.
Мысль автора достаточно банальна — возможности человеческого восприятия весьма ограничены.
SAG2010
12.03.2017 13:21+1«Even the strongest cultures have reviews that devolve into Maoist struggle sessions about whitespace.» я бы перевел как-то так «Даже у самых сильных команд случаются код-ревью, которые превращаются в философские споры о пробелах».
«Даже в командах с сильнейшей культурой разработки бывают проверки кода, которые превращаются в охоту на ведьм пробелы.» — это вообще PROMTом попахивает, имхо :)
«Просмотр сотен строк на наличие ошибок — это эффективная, необременительная процедура. Она не предотвращает всех проблем, и не создаёт новых. Этот процесс представляет собой разумный баланс между возможным и практичным.» — здесь по-моему тоже исковеркан смысл оригинального текста. dozens — это дюжины, а не сотни.
Предлагаю заменить на «Просмотр нескольких десятков строк кода — довольно эффетивная практика, которая, к тому же, не так обременяет разработчиков. Она не спасет вас от всех имеющихся ошибок в коде и даже не исключит на 100% вероятность появления новых. Но „маленькие“ код ревью помогут достичь баланса между пользой и затраченными усилиями.»
sbnur
Хорошие картинки — веб-программирование всегда мне напоминало путешествия в горно-лесистой местности, где когда велись разработки