Моё возвращение и выживание в IT после десятилетнего перерыва

Двадцать лет назад я работал в сфере технологий, спустя десять лет ушел в управленцы, а теперь вот снова вернулся к технологиям, уже в роли консультанта. Некоторые перемены меня сильно порадовали, а другие – не менее сильно удивили. Ниже я вкратце расскажу о тех основных вещах, которые меня чуть не доконали в цвете лет.

Сначала о приятном: Unix и разработчики воссоединились

На протяжении восьмидесятых и в начале девяностых профессиональная разработка ПО по большей части осуществлялась на дорогостоящих рабочих станциях Unix, например, на Sun Sparc или NeXT. В девяностые рынок захватил WinTel и все стали кодить на Windows при помощи инструментов от крупных поставщиков, вроде MS Visual Studio, либо немногочисленных свободных вариантов типа Eclipse. Linux на тот момент еще считался в мире десктопа чем-то больше для любителей.

В 2001 году я работал в стартапе. На всю нашу команду Linux использовал один-единственный разработчик, и ему приходилось тяжеловато с отрезанным доступом к инструментам для управления версиями и почтовому клиенту Outlook. Он обычно отправлял нам код письмами и просил залить за него. Припоминаю, что сам я тогда использовал XEmacs – эх, старые добрые времена.

Перенесемся в настоящее. Unix стал очень популярной платформой среди разработчиков, особенно тех, кто работает на Mac за счет того, что там используется ядро Unix. Кроме того, существует такое явление, как Linux в Windows. В этом отношении, в отличие от многих других, моё возвращение в IT не было сопряжено ни с какими трудностями. Забавно, что многие мои молодые коллеги сейчас едва управляются с Windows, а на Linux чувствуют себя гораздо увереннее.

Управление релизами больше не профессия

Когда-то давным-давно разветвление, слияние и устранение конфликтов были адской работенкой, которая нередко требовала вмешательства особого специалиста по релизам. Во времена, когда на рынке систем управления версиями царила ClearCase, работы по разветвлению, слиянию и релизам хватало на целую немаленькую команду – по крайней мере, если судить по моему опыту работы в HP в 2002 году.

Идея о том, что разработчик может и сам подавать запросы на принятие изменений, на самом деле, довольно молодая. По всей видимости, ей дали начало переход разработки на Linux и новая волна распределенных систем управления версиями: BitKeeper, Git и так далее. Возможности внести свои изменения так, чтобы они отобразились у всех задействованных в рабочем процессе, в старых системах типа ClearCase, CVS, SVN или PerForce как таковой и не было. Либо этим занимался владелец репозитория, либо человек, отвечающий за управление релизами, либо каждый разработчик сам себе всё организовывал. Сейчас процесс существенно упростился, и налаживать совместную работу в команде теперь можно без дополнительных участников.

А где QA-команды? Модульное тестирование и непрерывная интеграция

О модульном тестировании и непрерывной интеграции я впервые услышал от Кента Бека, одного из авторов Agile Manifesto и создателя методологии экстремального программирования. Двадцать лет назад его идеи были революционными, но того статуса стандарта в разработке, который имеют сейчас, они добились не сразу.

На мой взгляд, жаль, что в Agile и Scrum непрерывной интеграции не уделяется больше внимания. Но я уже и тому рад, что эта практика на сегодняшний день получила неплохое распространение. Я присутствовал на той конференции и помню, как Джошуа Блох, автор Java Collections, вышел на сцену с докладом о непрерывной интеграции, и его слова: «Спасибо (Agile или JUnit), что придали непрерывной интеграции шарма». И он был прав. В былые времена писать тесты считалось делом скучным, и мало кто этим занимался. Поэтому начальство нанимало специальных людей, QA-инженеров, которые искали за разработчиками ошибки! С ума сойти, вот лафа-то была…

Модульное тестирование и непрерывная интеграция практически устранили необходимость в таких людях – теперь разработчики сами несут ответственность за написание тестов, а инфраструктура непрерывной интеграции всё вовремя запускает и сообщает об ошибках. Благодаря этому программы стали надежнее, а цикл разработки сократился. Также нововведения помогли разработчикам обрести более цельный взгляд на вещи и научиться писать код так, чтобы его можно было без труда тестировать.

Docker: больше никаких помех на пути в прод

Контейнеры, а именно Docker, убрали всё лишнее из управления пакетами и свели к минимуму проблемы с окружением, возникающие по мере того, как код проходит тесты и уходит в прод. Предварительно, правда, придется обзавестись хорошим DevOps-инженером, чтобы настроил экосистему Docker.

В старые времена случалось такое, что система создавалась совсем не в том окружении, в котором ей предстояло развертываться (ну, то есть, например, писали код в Windows, а развертывали в Unix). Это неизбежно вызывало баги и нагромождало дополнительной работы в каждом цикле тест-релиз.

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

Docker упростил процедуру и создал условия для непрерывной интеграции и непрерывного развертывания за счет того, что, опять же, передал соответствующие функции в руки программистам.

Open Source: слишком много возможностей

В мире программ с открытым кодом выбора сейчас, прямо скажем, с избытком. Я тут настраивал Jenkins и захотел провести интеграцию с BitBucket. Поиск плагинов по запросу “bitbucket” дал четыреста с лишним результатов, многие из них – с открытым кодом.

Это создает две проблемы:

1. Из большого числа вариантов сложнее выбирать
2. При таком обилии часть инструментов точно отомрет и их поддержка прекратится

Но есть и плюсы: потребности самому делать базовую инфраструктуру и инструменты почти не возникает – находи, что нужно из готового, да пользуйся. Двадцать лет назад приходилось писать библиотеки и структуры данных для самых обычных операций, и это было где-то даже весело. Сегодня для каждого языка существует столько разных библиотек и фреймворков, что 99% разработчикам могут прожить, не написав ни одного B-дерева, или хэш-таблицы, или даже OAuth-коннектора.

Agile и Scrum захватили мир

Двадцать лет назад Agile уже жил и здравствовал (Agile Manifesto увидел свет в 2001 году), но рост популярности у него начался позже – в том числе и за пределами IT, причем иногда в искаженном виде. Он стал любимой присказкой в руководящих кругах: «Бизнес должен оставаться гибким (agile), иначе не выживет».

Я помню времена, когда цикл релиза тянулся довольно долго (три месяца, и это в стартапе). Вернувшись с собрания, на котором разобрал спецификации по строчке, разработчик мог засесть за стол и несколько недель спокойно гамать, не тревожась, что придется отчитываться о том, как идут дела. А теперь каждый день стендап-митинги, каждые две недели спринты – особо не расслабишься!

Также Agile перераспределил административные функции – сейчас разработчики напрямую общаются с пользователями или менеджерами продукта. Отсидеться молча уже не получится. Соответственно, умение общаться стало цениться значительно выше, чем раньше.

Наконец, с Agile ускорился темп разработки. Дело даже не в стендап-митингах и прочих Scrum-затеях. Сами инструменты стали экономить нам время: доски в Jira, запросы на внесение изменений, инструменты для непрерывной разработки и развертывания – всё это даёт возможность работать быстрее. С одной стороны, это прибавляет повседневных забот, а с другой – чувствуешь отдачу от того, что в короткие сроки выкатываешь продукты и комплексно выполняешь задачи.

В заключение

Если вы тоже уходили из IT и подумываете вернуться – поддерживаю и желаю удачи. Лично я с удовольствием обновлял навыки (хотя чуть не помер по ходу дела). Фундаментальные принципы программирования остались прежними, так что, думаю, пробьюсь как-нибудь. Но вот инструментарий сильно изменился, и это влияет на продуктивность.

Вы, наверное, уловили в статье повторяющийся мотив: у современного разработчика намного более широкий круг задач, чем двадцать лет назад. Он пишет код, занимается управлением версий, тестирует то, что написал, работает с контейнерами и так далее. Конечно, мозг иногда кипит, но зато больше не надо самому делать связные списки.