Почему ответственные и грамотные разработчики считают сборку проекта некой второстепенной работой? Одно из объяснений — сценарии сборки часто пишут на ином языке, чем исходный код. Второе — сценарии сборки не являются «кодом». Такие объяснения противоречивы, ведь большинство разработчиков с удовольствием изучает новые языки, а именно в результате сборки появляются исполняемые модули, которые разработчики и конечные пользователи будут тестировать и запускать. Код бесполезен, если из него не собирается исполняемый модуль, а ведь именно сборка определяет компонентную архитектуру приложения. Сборка — важная часть процесса разработки, и решения в области сборки способны упрощать и сам код, и процесс его написания.
Если в сценариях сборки используются неверные идиомы, такие сценарии тяжело сопровождать и, что хуже, тяжело улучшать. Стоит потратить некоторое время, чтобы разобраться, как правильно вносить изменения. Если приложение собирается с неверными версиями зависимых библиотек или во время сборки заданы неверные параметры конфигурации, это может вызвать ошибки в самом приложении.
Традиционно тестирование всегда возлагалось на группу контроля качества. Сейчас мы понимаем, что тестирование в процессе написания кода — необходимое условие для получения предсказуемого результата. Аналогично и владельцем процесса сборки должна быть команда разработчиков.
Понимание процесса сборки может упростить весь жизненный цикл разработки и сократить издержки. Если процесс сборки легко осмыслить и применить, это дает возможность новому разработчику быстро и легко включиться в работу. Если конфигурацию приложения автоматизировать в рамках процесса сборки, это поможет гарантировать получение одинаковых результатов, когда над проектом работает несколько человек, и избежать реплик в духе «А у меня все работает». Многие инструменты сборки генерируют отчеты о качестве кода, заблаговременно вскрывающие потенциальные проблемы. Потратив время и научившись самостоятельно управлять процессом сборки, вы облегчите жизнь себе и всем остальным участникам вашей команды. Вы сможете сосредоточиться на разработке новой функциональности, что принесет пользу клиентам и сделает вашу работу более приятной.
Изучите процесс сборки достаточно хорошо, чтобы знать, когда и как изменять его. Сценарии сборки — это тоже код. Они слишком важны, чтобы доверить их кому-то другому, хотя бы по той причине, что приложение не закончено, пока оно не собрано. Задача программирования не завершена, пока мы не поставили работающее приложение пользователю.
Программируйте парами и входите в поток
Гудни Хаукнес, Кари Россланд и Анн Кэтрин Гэгнат
Представьте себе, что вы совершенно поглощены своей работой: сосредоточены, увлечены и заняты. Вы потеряли счет времени. Вы счастливы. Вы в состоянии потока. В масштабах всей команды разработчиков трудно достичь и поддерживать состояние потока из-за многочисленных помех, отвлечений и прочих препятствий, которые легко могут его нарушить.
Если вы уже участвовали в парном программировании, то, вероятно, знаете, как оно способствует достижению состояния потока. Если нет, то мы хотим поделиться своим опытом, чтобы побудить вас заняться парным программированием немедленно! Чтобы парное программирование было успешным, требуются некоторые усилия со стороны отдельных участников команды и всей команды в целом.
Будучи частью команды, проявляйте терпение по отношению к менее опытным разработчикам. Преодолейте свой страх перед более опытными разработчиками. Осознайте, что все люди разные, и научитесь это ценить. Помните о сильных и слабых качествах — как своих, так и других членов команды. Вас может удивить, сколь многому способны научить коллеги.
Применяйте парное программирование для распространения навыков и знаний среди всех участников проекта. Задачи нужно решать парами и часто производить ротацию участников пар и выполняемых каждой парой задач. Сообща установите правило для такой ротации. Если нужно, откажитесь от этого правила или подправьте его. Наш опыт показывает, что не обязательно доводить задачу до конца, прежде чем передать ее следующей паре. Может показаться, будто это неразумно, однако на практике мы обнаружили, что это эффективно.
Существует множество ситуаций, когда состояние потока может быть нарушено, но парное программирование позволяет его сохранить: