Речь не пойдет о пользе для лесов Бразилии перехода на электронный документооборот или выключении Num lock для экономии электроэнергии. Я хочу поговорить об «экологии» как более широком (или же наоборот, более специализированном) понятии, как взаимодействии разработчика со средой разработки в широком смысле этого слова.
Так уж случилось, что я, к своему стыду, очень ленив. Второе мое отрицательное качество — нетерпеливость. Мне лень сходить к компьютеру в комнате и расшарить папку — я лучше зайду на него по RDP и меня жутко раздражает ожидать, пока компьютер включится — я лучше оставлю его включенным на ночь. Однако, как выяснилось, оба этих качества весьма и весьма полезны для разработчика.
Первый проект, на котором я работал, всецело зависил от веб-сервисов на другом конце света. Приходилось каждый день начинать с подключения к медленному (потому что более быстрый был уже занят, когда я приходил на работу) VPN, который имел привычку отваливаться в самый неподходящий момент. Веб-сервисы были далеко, поэтому каждый запуск проекта для отладки мог занимать до пяти минут. Проект был немаленький — полная сборка занимала минуты три, плюс запуск минуты две (сервисы же далеко) — получалось, я ждал пять минут, чтобы проверить, правильно ли я изменил один символ в строчке…
Понятно, что мне было лень подключаться к VPN и меня раздражала скорость запуска проекта.
Самое неприятное из всего этого то, что окружающие относились к этому весьма терпимо, мол «что же тут поделать». Меня это буквально поражало — как так можно, даже не пытаться улучшить свою даже не ежедневную — ежеминутную работу. Я не смог так долго терпеть — в голову пришла идея написать «кэширующий прокси», который отвязал бы меня и от VPN, и от внешних сервисов, позволяя начать отладку так быстро, как только возможно. Итог — мой «прокси» продался заказчику и теперь используется чуть ли не в production, а к VPN теперь не надо подключаться – заказчики расщедрились на site-to-site VPN (хочется верить, что мое еженедельное нытье по поводу VPN тоже имело к этому отношение). Нужно отметить, что от идеи до реализации прошло, увы, очень много времени, да и «прокси» так и не был доведен до ума…
Следующим моим большим заданием было собирать билды и ставить их на удаленные машины приблизительно на том же краю света, где и сервисы. Опять-таки, занятие было нудное и долгое — все приходилось делать руками. За полный рабочий день я успевал собрать и поставить четыре билда — два часа на билд. И опять, руководство не видело (или не подавало виду), что это плохо — видимо, это обходилось дешевле, нежели наладить нормальный билд-процесс. Мне все-такие удалось уговорить свое начальство дать мне время на создание билд скрипта. Как итог — скрипт, в случае, если с исходниками все хорошо, собирал билд за 20 минут, мне оставалось лишь запустить установку на удаленной машине. Сейчас этот скрипт является основой билд-процесса уже как минимум двух проектов…
Еще я могу вспомнить приведение в порядок репозитория — до этого коммиты в проект приходилось делать в пять веток и не дай бог кто-то будет коммитать одновременно с тобой. И маленький фикс в девелоперской тулзе, который позволял не вводить каждый раз имя пользователя. И возможность смотреть XML в отформатированном виде вместо raw text, и макрос для студии, облегчающий поиск специфических проектных ресурсов, и еще много всего.
И меня, честно говоря, всегда удивляли две вещи. Первая — это покорность моих коллег, не пытавшихся, в своем большинстве, ничего изменить в надоедливых, неудобных и медленных рутинах своих ежедневных действий. Вот уж правда — разработчик должен быть ленивым. Мне лень делать изо дня в день то, что легко поддается механизации и упрощению.
Вторая непонятная вещь — как же сложно «продать» изменения в экологии проекта заказчикам и менеджерам. С другой стороны, конечно, их очень просто понять: вклад в экологию — это очень долгосрочные инвестиции, сопряженные с рисками «ничего-не-вышло». Однако из своего опыта я могу сказать, что эти изменения обычно бывают очень дешевы, по сравнению с теми ежедневными затратами времени и сил каждого разработчика в команде.
Сейчас я перешел на новый проект, где опять вижу кучу «экологических» проблем — и script-hell для поддержки баз данных в рабочем состоянии, и отсутствие выделенного сервера для тестов производительности, и кучу конфигов и магических пассов для запуска сервреа, и разброд в репозитории, и отсутствия kick-off для новых людей в команде. И опять — на все мои возгласы «Да как же так» я слышу лишь «Так тут было всегда» и вижу, что даже если мой непосредственный начальник очень хочет что-то поменять, придется опять и опять биться головой о стену, пытаясь доказать заказчикам, что это все нужно и можно изменить.
Так уж случилось, что я, к своему стыду, очень ленив. Второе мое отрицательное качество — нетерпеливость. Мне лень сходить к компьютеру в комнате и расшарить папку — я лучше зайду на него по RDP и меня жутко раздражает ожидать, пока компьютер включится — я лучше оставлю его включенным на ночь. Однако, как выяснилось, оба этих качества весьма и весьма полезны для разработчика.
Первый проект, на котором я работал, всецело зависил от веб-сервисов на другом конце света. Приходилось каждый день начинать с подключения к медленному (потому что более быстрый был уже занят, когда я приходил на работу) VPN, который имел привычку отваливаться в самый неподходящий момент. Веб-сервисы были далеко, поэтому каждый запуск проекта для отладки мог занимать до пяти минут. Проект был немаленький — полная сборка занимала минуты три, плюс запуск минуты две (сервисы же далеко) — получалось, я ждал пять минут, чтобы проверить, правильно ли я изменил один символ в строчке…
Понятно, что мне было лень подключаться к VPN и меня раздражала скорость запуска проекта.
Самое неприятное из всего этого то, что окружающие относились к этому весьма терпимо, мол «что же тут поделать». Меня это буквально поражало — как так можно, даже не пытаться улучшить свою даже не ежедневную — ежеминутную работу. Я не смог так долго терпеть — в голову пришла идея написать «кэширующий прокси», который отвязал бы меня и от VPN, и от внешних сервисов, позволяя начать отладку так быстро, как только возможно. Итог — мой «прокси» продался заказчику и теперь используется чуть ли не в production, а к VPN теперь не надо подключаться – заказчики расщедрились на site-to-site VPN (хочется верить, что мое еженедельное нытье по поводу VPN тоже имело к этому отношение). Нужно отметить, что от идеи до реализации прошло, увы, очень много времени, да и «прокси» так и не был доведен до ума…
Следующим моим большим заданием было собирать билды и ставить их на удаленные машины приблизительно на том же краю света, где и сервисы. Опять-таки, занятие было нудное и долгое — все приходилось делать руками. За полный рабочий день я успевал собрать и поставить четыре билда — два часа на билд. И опять, руководство не видело (или не подавало виду), что это плохо — видимо, это обходилось дешевле, нежели наладить нормальный билд-процесс. Мне все-такие удалось уговорить свое начальство дать мне время на создание билд скрипта. Как итог — скрипт, в случае, если с исходниками все хорошо, собирал билд за 20 минут, мне оставалось лишь запустить установку на удаленной машине. Сейчас этот скрипт является основой билд-процесса уже как минимум двух проектов…
Еще я могу вспомнить приведение в порядок репозитория — до этого коммиты в проект приходилось делать в пять веток и не дай бог кто-то будет коммитать одновременно с тобой. И маленький фикс в девелоперской тулзе, который позволял не вводить каждый раз имя пользователя. И возможность смотреть XML в отформатированном виде вместо raw text, и макрос для студии, облегчающий поиск специфических проектных ресурсов, и еще много всего.
И меня, честно говоря, всегда удивляли две вещи. Первая — это покорность моих коллег, не пытавшихся, в своем большинстве, ничего изменить в надоедливых, неудобных и медленных рутинах своих ежедневных действий. Вот уж правда — разработчик должен быть ленивым. Мне лень делать изо дня в день то, что легко поддается механизации и упрощению.
Вторая непонятная вещь — как же сложно «продать» изменения в экологии проекта заказчикам и менеджерам. С другой стороны, конечно, их очень просто понять: вклад в экологию — это очень долгосрочные инвестиции, сопряженные с рисками «ничего-не-вышло». Однако из своего опыта я могу сказать, что эти изменения обычно бывают очень дешевы, по сравнению с теми ежедневными затратами времени и сил каждого разработчика в команде.
Сейчас я перешел на новый проект, где опять вижу кучу «экологических» проблем — и script-hell для поддержки баз данных в рабочем состоянии, и отсутствие выделенного сервера для тестов производительности, и кучу конфигов и магических пассов для запуска сервреа, и разброд в репозитории, и отсутствия kick-off для новых людей в команде. И опять — на все мои возгласы «Да как же так» я слышу лишь «Так тут было всегда» и вижу, что даже если мой непосредственный начальник очень хочет что-то поменять, придется опять и опять биться головой о стену, пытаясь доказать заказчикам, что это все нужно и можно изменить.
