Возьмите сборку (и ее рефакторинг) на себя Стив Берчук

Не столь уж редки случаи, когда команды, в целом дисциплинированно соблюдающие хорошие практики написания кода, пренебрежительно относятся к сценариям сборки. Их считают либо малозначительными, либо настолько сложными, что обслуживать их может только секта специалистов по выпуску продукта (release engineers). Если сценарии сборки сложны в сопровождении, содержат дублирование и ошибки, это приводит к проблемам того же масштаба, что и плохо спроектированный код.

Почему ответственные и грамотные разработчики считают сборку проекта некой второстепенной работой? Одно из объяснений — сценарии сборки часто пишут на ином языке, чем исходный код. Второе — сценарии сборки не являются «кодом». Такие объяснения противоречивы, ведь большинство разработчиков с удовольствием изучает новые языки, а именно в результате сборки появляются исполняемые модули, которые разработчики и конечные пользователи будут тестировать и запускать. Код бесполезен, если из него не собирается исполняемый модуль, а ведь именно сборка определяет компонентную архитектуру приложения. Сборка — важная часть процесса разработки, и решения в области сборки способны упрощать и сам код, и процесс его написания.

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

Традиционно тестирование всегда возлагалось на группу контроля качества. Сейчас мы понимаем, что тестирование в процессе написания кода — необходимое условие для получения предсказуемого результата. Аналогично и владельцем процесса сборки должна быть команда разработчиков.

Понимание процесса сборки может упростить весь жизненный цикл разработки и сократить издержки. Если процесс сборки легко осмыслить и применить, это дает возможность новому разработчику быстро и легко включиться в работу. Если конфигурацию приложения автоматизировать в рамках процесса сборки, это поможет гарантировать получение одинаковых результатов, когда над проектом работает несколько человек, и избежать реплик в духе «А у меня все работает». Многие инструменты сборки генерируют отчеты о качестве кода, заблаговременно вскрывающие потенциальные проблемы. Потратив время и научившись самостоятельно управлять процессом сборки, вы облегчите жизнь себе и всем остальным участникам вашей команды. Вы сможете сосредоточиться на разработке новой функциональности, что принесет пользу клиентам и сделает вашу работу более приятной.

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

Загрузка...