Какие языки программирования и фреймворки актуальны сегодня, какие выходят из моды, а какие будут необходимы каждому разработчику уже завтра? Как оптимально выстроить работу команды разработки, выбрать стратегию, проводить ревью кода и бороться с техническим долгом? На эти и другие важные для разработчиков вопросы отвечает Герман Урих, старший разработчик компании Apple с более чем десятилетним опытом работы в индустрии. Опыт Германа включает разработку комплексных бэкенд-сервисов для Apple TV, а также успешные проекты в компаниях Booking.com, Deutsche Bank и T-Systems. Он много работал с языком Java, накопив опыт, подтвержденный многочисленными сертификатами Oracle, а также с такими технологиями, как Spring, Kafka и Docker. Как практик с опытом работы в крупнейших технологических компаниях, он делится своим опытом и раскрывает все тонкости разработки, актуальные на 2024 год.
1. Вы много работали с Java. Какие преимущества определили популярность этого языка программирования? Насколько он востребован сейчас и в каких нишах разработки?
Изначально одним из основных преимуществ Java была пресловутая концепция Write Once, Run Anywhere — кроссплатформенность. То есть код нужно было написать всего один раз (на Java), и дальше его можно было исполнять на самых разных машинах, под которые есть виртуальная машина (JVM). Это даже повлияло на один из рекламных слоганов Oracle, который появлялся при установке Java локально: `3 billion devices run Java`. Наверное, это определило популярность языка с точки зрения различных бизнесов, которые были заинтересованы в снижении затрат на разработку. Программисты тратили меньше времени на написание кода, а значит, тот же самый продукт можно было создать с меньшей себестоимостью. Ведь если код вашего продукта нужно исполнять на разных устройствах, можно было написать его всего один раз (при условии, конечно, что на них есть JVM).
С точки зрения порога вхождения, Java представлялся более простым и усовершенствованным языком по сравнению с популярным на тот момент C/C++, а значит, потенциально разработчики могли быстрее научиться на нем программировать. Опять-таки, с точки зрения бизнеса это преимущество — чем проще выучить язык программирования, тем больше потенциальных разработчиков на рынке, и тем проще их нанять. А с точки зрения разработчиков они получали возможность писать код более безопасно — например, автоматический сборщик мусора избавляет от большинства проблем, связанных с необходимостью вручную контролировать память в C/C++, — и более просто — например, концепция ссылок (references) в Java гораздо проще и делает программирование более приятным и понятным. Получался такой win-win, который способствовал развитию популярности языка.Глава Минцифры Максут Шадаев – о запретах, стимулах и новых подходах к развитию ИТ-отрасли. Интервью TAdviser 
Что касается востребованности Java, с тех пор, как началась моя карьера программиста (в 2014), я постоянно слышу, что Java умирает, но это не соответствует тому, что я вижу. С точки зрения компаний, в которых я работаю, с точки зрения онлайн-сообществ, проводимых конференций, поддержки языка со стороны разработчиков — все эти признаки указывают на то, что язык жив и успешно продолжает развиваться, и его закат не предвидится. А с новым циклом обновлений (ровно один раз в полгода) он стал еще более предсказуемым и стабильным, что не может не радовать разработчиков и бизнесы, которые на него опираются.
Если говорить про эти самые бизнесы, то Java больше всего используется как язык для бэкенда (разработка UI на нем, судя по всему, все-таки умерла). Он используется в больших, распределенных бэкенд-системах, в которых важна стабильность работы (аптайм), удобство поддержки и добавления новых фич. Это, например, банковские системы, телеком, самые различные сервисы — музыкальные, телевизионные, шоппинг — и даже базы данных (например, очень популярная NoSQL база данных Cassandra написана именно на Java). В целом, я бы сказал, Java может использоваться и успешно используется для решения практически любых бэкенд-задач.
2. Какие языки программирования являются наиболее перспективными сейчас?
В первую очередь, я бы хотел отметить Kotlin. Я немного его фанат в силу того, насколько он похож на Java и, в то же время, выглядит значительно усовершенствованной, современной версией. Но и с объективной точки зрения хочу сказать, что он стремительно набирает популярность. В Google он уже является официальным языком программирования для Android, и все больше бэкенд-систем переписывают свой код с Java на Kotlin.
В целом Kotlin очень хорош благодаря своей совместимости с Java (вы можете вызывать Java-код из Kotlin и наоборот), безопасности (null-safety — один из основных акцентов языка), а также потому, что создавался с упором на простоту и усовершенствование Java. Поэтому мне, как человеку с подавляющим большинством профессионального опыта на Java, Kotlin особенно близок.
Помимо Kotlin, я бы отметил Rust и Go. Первый делает акцент на безопасность и производительность, в то время как второй известен своей скоростью и эффективностью в облачных приложениях и микросервисах. Я сам с ними практически не работал, поэтому не могу сказать, что предпочитаю один или другой, но разговоры о них и заинтересованность среди разработчиков в последние годы точно присутствуют.
3. Ревью кода является ключевым в разработке. Какие у вас стратегии по поддержанию высокого качества кода и как вы боретесь с техническим долгом?
Тут, наверное, имеет смысл ответить отдельно на две части вопроса.
Про поддержание высокого качества кода — здесь скажу несколько вещей.
Во-первых, как вы уже сами отметили, код-ревью. Без него, в идеале, никакой код не должен попадать в основную ветку, и таким образом у разработчиков есть шанс дать фидбэк на предлагаемый код (тем самым повысив его качество) или даже наоборот — научиться чему-то, прочитав чужой код на ревью. Обычно люди концентрируются на первой части и совсем забывают про вторую: если опытный разработчик выставляет свой код на ревью, то, вероятно, он написан в соответствии с высокими критериями качества, интересными паттернами, и там есть чему поучиться.
Помимо этого, я вижу смысл устраивать knowledge-sharing встречи. Это может быть в формате получаса раз в неделю или часа раз в две недели, или в любом другом формате — в зависимости от того, что подходит команде. Во время этих встреч разработчики могут делиться друг с другом интересными вещами, с которыми им довелось поработать за последний период. Например, я мог бы пофиксить какой-то интересный неочевидный баг и хочу поделиться тем, как я это сделал. Или испробовал какую-то новую технологию или интеграцию, или даже прочитал что-то интересное и просто хочу поделиться с командой. Все это позволяет распространять ваши личные знания и навыки на команду и тем самым повышать средний уровень хард-скиллов и качества кода.
Теперь о борьбе с техническим долгом.
Технический долг всегда будет, это надо просто принять и смириться с этим. Другой вопрос — как сделать так, чтобы его не накопилось так много, чтобы (как и в реальной жизни, если набрать слишком много долгов) вы не оказались банкротом. Банкрот в случае технического долга — это команда или проект, которые больше не могут поддерживать систему или фиксить в ней баги из-за огромного количества технического долга. Например, такое может быть, если фреймворк, на котором написана система, безнадежно устарел, и прикрутить к нему новую фичу технически невозможно без полного переписывания приложения. Или у вас настолько неотрефакторенный `спагетти` код, что сделать новую фичу или багфикс займет несколько месяцев.
Как сделать так, чтобы его не накопилось слишком много?
Во-первых, фиксировать весь предполагаемый технический долг. Наткнулись на кусок кода, который не очень читаемый и явно можно сделать лучше — заведите техническую задачу в баг-трекере на рефакторинг. Увидели, что используемая версия библиотеки устарела и пора бы её обновить — техническая задача. Логи заспамлены NullPointerException, но вроде всё работает как надо? Техническая задача!
Ну и следующий этап — сделать решение этих технических задач частью вашего рабочего процесса. Например, если вы работаете по спринтам и в начале каждого спринта набираете новые задачи, которые «влезут» по предполагаемому объему работы, заложите время на то, чтобы раздать по одной-две технических задач каждому из разработчиков. Таким образом, их объем не будет бесконечно расти, а если вам повезет, то будет даже уменьшаться, и вы никогда не окажетесь в ситуации «банкротства». Для разработчиков это тоже может быть полезно — не только фиксироваться на новых фичах и продуктовых задачах, но и помнить про качество кода и чувствовать себя причастными к его постоянному улучшению. Это может даже привести к тому, что они будут стараться изначально писать самую лучшую версию кода — ведь иначе потом всё равно кому-то придется переписывать!
4. Насколько востребованы agile-стратегии на сегодняшний день? Появляются ли новые методологии, которые могут составить им конкуренцию?
Тут я могу сказать из своего опыта, что во всех компаниях, в которых я работал, применялись те или иные agile-стратегии, при этом каждая компания адаптировала их под себя. Например, в зависимости от проекта мы могли работать по спринтам или без них; спринты могли быть длиной как в неделю, так и в два месяца; оценки могли производиться как в стори-пойнтах, так и в часах. В некоторых проектах был проджект-менеджер или скрам-мастер, в некоторых нет. Где-то мы пользовались досками для тикетов, где-то просто тикетами, а где-то держали все в голове. QA могли как участвовать на каждом этапе разработки, так и вообще отсутствовать как должность, и все фичи тестировались разработчиками самостоятельно.
Наверное, что я этим всем хочу сказать, так это то, что, на мой взгляд, с момента возникновения agile-стратегий прошло достаточно времени, чтобы компании поняли их потенциальные сильные стороны, но при этом осознали, что слепо следовать той или иной методологии бессмысленно, и нужно адаптировать их под себя. Поэтому я думаю, что в целом такие стратегии очень востребованы, при этом большая часть команд берут из них только то, что им подходит, и отбрасывают остальное. С точки зрения методологий, которые могут составить конкуренцию... С учетом моего ответа выше, я думаю, что различные команды и компании таким образом постоянно создают новые методологии из текущих, модифицируя их под себя. Поэтому я бы сказал, что да, они безусловно появляются, но с какой-то точки зрения это все те же agile-стратегии (адаптировать существующую стратегию — чем не гибкость?), и что-то кардинально новое в ближайшем будущем вряд ли предвидится.
5. Вы руководили командами разработки. Какие ключевые качества важны для этой профессии в целом и какие фреймворки, языки и инструменты нужно знать, чтобы состояться в этой сфере сегодня?
Отвечу, наверное, двумя частями.
С точки зрения ключевых качеств, во-первых, это внимание к деталям. Я бы сказал, что это критически важное качество для любого разработчика. С чисто логической точки зрения в программировании почти каждая мелочь имеет значение, будь то правильно расставленные скобки или учтённые граничные случаи. Внимание к деталям помогает избежать множества ошибок и багов, которые могут возникнуть в процессе разработки. Но и с точки зрения работы в команде мне, как разработчику или руководителю, намного приятнее иметь коллегу, который подумал о том `наследии`, которое он оставит после себя в коде, и о нас, кто будет его поддерживать, и сделал то лишнее усилие, чтобы сделать код еще более чистым, опрятным и приятным для чтения.
Во-вторых, это понимание, что технологии меняются, и открытость к комментариям от коллег и новому опыту. Мир технологий постоянно развивается, и единственная постоянная — это изменения. Очень хорошо, если разработчик в курсе последних трендов и инструментов — не обязательно на профессиональном уровне, но хотя бы ознакомлен. Это позволяет быть более гибким в принятии решений и выбирать наиболее подходящий инструмент для решения конкретной задачи. Также, мне кажется, более гибкие разработчики обычно более открыты к обратной связи от команды, с помощью которой мы все можем постоянно помогать друг другу становиться лучше.
Желание сделать чуть больше, чем ожидается — surprise and delight. Помимо выполнения поставленных задач от и до, можно сделать буквально чуточку больше: переименовать неудачно названный класс, проапгрейдить устаревшую версию или даже просто удалить неактуальный комментарий в коде. Тем, кто с вами работает, будет очевидно, что вы постоянно стремитесь улучшать ваш продукт и то, с чем вы работаете. Это не может не радовать и, скорее всего, не раз поможет вам в карьере. Такие мелочи запоминаются коллегами и оказываются кстати в момент, когда приходит performance review.
Открытость в ходе своей работы. Если у моего коллеги проблема с задачей, и он не может совершить прогресс, я бы хотел знать об этом как можно раньше, чтобы можно было помочь разблокировать его, а также скорректировать ожидаемые сроки. В этом нет абсолютно ничего плохого, мы все периодически можем зависать и ощущать себя не в силах продвинуться дальше, но то, насколько спокойно мы можем донести это до команды и обратиться за помощью, может определить успешность нашего проекта.
Наконец, я бы отметил умение решить проблему каким бы то ни было способом. Довольно часто бывает, что в ходе выполнения задачи становится понятно, что изначальный план не работает и предвидятся дополнительные трудности. То, насколько спокойно мы можем подойти к таким препятствиям и как творчески мы найдем из них выход, зачастую определяет успех или неудачу в выполнении таких задач.
Теперь отвечу про фреймворки, языки и инструменты. Мой ответ будет чуть более сфокусирован на Java-разработке, так как это основной мой профиль.
Для Java-разработчика я бы предложил знание, очевидно, Java, а также либо Kotlin (как практически смежный язык с Java — см. ответ выше), либо какого-то языка с другой парадигмой для расширения кругозора. Python всегда неплохой вариант — он относительно простой и все еще очень широко используемый, и даже классический JavaScript для большего знакомства с UI-разработкой подойдет.
По фреймворкам крайне рекомендую освоение Spring/Spring Boot. Это был и остается один из самых популярных фреймворков для разработки на Java. Он универсален и предлагает из коробки множество вещей для быстрого создания микросервисов и веб-приложений за счет предварительно настроенных конфигураций. Во многих компаниях это де-факто стандарт для новых приложений. И, даже если в компании вместо Spring используется что-то другое, почти наверняка оно будет иметь множество сходств со Spring, и его освоение будет более простым, если Spring уже в вашем арсенале.
С точки зрения баз данных хорошо было бы иметь опыт работы с хотя бы одной SQL/NoSQL-базой. И те, и другие очень широко используются в индустрии, и знакомство с ними является чуть ли не обязательным для современного разработчика. Для SQL можно поработать с MySQL или Oracle, а в качестве NoSQL можно рассмотреть все ту же крайне популярную Cassandra.
Также стоит отметить различные другие сверхпопулярные инструменты, такие как Kafka для асинхронного взаимодействия систем — он использовался почти на каждом проекте, над которым я работал. Docker и Kubernetes для контейнеризации — тоже являются стандартом. Ну и различные базовые инструменты программиста, такие как Git и IntelliJ IDEA, без которых сейчас никуда.
6. Какие тренды в индустрии разработки программного обеспечения вам кажутся самыми важными в ближайшие годы?
В первую очередь, не могу не сказать, конечно же, про AI. В последнее время вокруг него огромное количество шума, и чуть ли не каждая вторая компания интегрирует AI в свою функциональность (поисковики, генераторы контента и даже Duolingo). Apple также недавно сообщила, что последние версии гаджетов и операционных систем будут сильно опираться на искусственный интеллект. В этом плане мы сейчас переживаем очередную техническую революцию (как было с появлением интернета и айфонов), и при этом находимся еще в самом ее начале. Нас ожидают интересные времена впереди!
Во-вторых, стоит упомянуть облачные технологии. За последние пять лет создание приложений в облаке стало практически стандартом разработки, и на это есть причины. Облако предоставляет гибкость и масштабируемость, которые сложно достичь с традиционными серверами. Компании могут легко увеличивать или уменьшать ресурсы в зависимости от нагрузки, что особенно важно для стартапов и быстрорастущих проектов.
Кроме того, современные облачные провайдеры предлагают множество встроенных сервисов, от баз данных и аналитики до машинного обучения и AI, что значительно ускоряет разработку и позволяет сосредоточиться на бизнес-логике, а не на инфраструктуре. Это тоже тренд последних лет, ведь десять лет назад облако предоставляло исключительно мощности для развертки приложений и практически ничего больше.
Плюс, глобальная доступность и надежность облачных платформ делают их идеальными для создания приложений с глобальной аудиторией. Поэтому в целом облачные технологии сейчас популярны как никогда и, как тренд, скорее всего, останутся с нами на ближайшие годы.
Ну и в-третьих, если говорить про тренды, стоит упомянуть мультиплатформенную разработку. В последние годы она набрала особую популярность, позволяя разработчикам создавать приложения на разных платформах, используя одну и ту же кодовую базу. Это быстро (код пишется один раз), удобно (баг-фиксы и фичи нужно вносить только в одну кодовую базу) и обеспечивает консистентность функциональности вашего приложения между разными платформами.
В качестве примера могу привести Kotlin Multiplatform. Этот фреймворк позволяет использовать Kotlin для написания бизнес-логики, которая будет работать на различных платформах, включая Android, iOS, веб и сервер. Это крайне удобно для тех, кто уже знаком с экосистемой Kotlin и хочет сократить время разработки, избегая дублирования кода.
В целом, использование мультиплатформенных технологий позволяет компаниям быть более гибкими и оперативными, тратить меньше средств на разработку, а значит, иметь конкурентные преимущества перед компаниями, которые все еще по старинке разрабатывают отдельный проект для каждой платформы.
Мнения и взгляды, изложенные в статье, являются исключительно точкой зрения автора и не отражают официальную позицию компании Apple.
