В любой сфере деятельности найдутся неоднозначные решения, время от времени заставляющие полыхнуть ту или иную часть интернета. Разумеется, такие «вечнозеленые споры» есть и в ИТ, и сегодня мы в Beeline Cloud решили вспомнить некоторые из них.
Разбираемся, почему даже сейчас находятся поводы для недовольства у сторонников разных регистров, о чем продолжают спорить сторонники и противники low-code и есть ли все-таки будущее у микросервисов.
camelCase против snake_case
В чем был хайп. И десять, и пятнадцать лет назад в ИТ-сообществе спорили Иван Иванович с Иваном Никифоровичем сторонники camelCase и snake_case — какой из регистров «лучше»? В 2011 году HCI-специалист Стивен Жёри провел опрос среди читателей своего блога, а также «прошерстил» интернет и собрал мнения разработчиков.
Сторонники верблюжьего регистра утверждали, что он удобнее при работе с длинными выражениями, растянутыми на несколько строк в редакторе кода; якобы он визуально компактнее, поэтому воспринимается легче, чем snake_case. Сторонники змеиного регистра говорили, что подчеркивания имитируют пробелы между словами, поэтому и читать такие имена переменных проще. Еще одним аргументом в пользу snake_case было удобство работы с аббревиатурами. В него случае не возникает ситуаций, когда непонятно, как корректно обозначить переменную, содержащую, например, название протокола. В camelCase имена вроде openTCPIPSocket или openTcpIpSocket выглядят неэстетично. Хотя и вариант open_TCP_IP_socket придется по душе далеко не всем.
Радикальные точки зрения встречались по обе стороны баррикад. Самые эмоциональные участники сообщества публиковали посты с заголовками «Почему camelCase — отстой» или «Подчеркивания — это глупость».
При этом дискуссии в них разворачивались не только вокруг читаемости двух регистров, но и их «эргономики». Например, веб-инженер Гарри Робертс в 2010 году писал, что camelCase усложняет сканирование кода, а разделители в snake_case, наоборот, упрощают навигацию: «Это немного странная претензия, но она определенно не дает мне покоя: я не могу использовать клавиши Ctrl+Shift+[стрелки], чтобы выделять отдельные слова внутри строки, записанной в camelCase». Разработчик Авди Гримм в 2012 парировал: «Я ненавижу подчеркивания. Они уродливые. Они как неоново-оранжевая поясная сумка в синтаксисе — устаревшая и неуместная в любую эпоху» (сторонники стритстайла из 2020-х встают на защиту поясных сумок).
Какие есть нюансы. Если говорить об удобстве чтения, то уже тогда исследования показывали, что на самом деле особой разницы в восприятии camelCase и snake_case нет. В 2009 году американские ученые из Колледжа Лойола (сегодня — Университет Лойола Мэримаунт) совместно с коллегами из Университета Джонса Хопкинса опросили 135 человек как с опытом программирования, так и без него. На экране демонстрировались движущиеся «облачка» с фразами из двух-трех слов, записанных в стилях camelCase или snake_case. Участники эксперимента должны были определить, в каком из них целевая фраза записана без ошибок (в остальных были перепутаны некоторые буквы или изменены целые слова). В итоге исследователи установили, что на именах переменных, записанных с помощью верблюжьего регистра, испытуемые ошибались реже, однако разница в точности оказалась совершенно незначительной — 68% против 65%.
В 2010 году американские ученые из Государственного университета Кента попытались воспроизвести эксперимент коллег из Колледжа Лойола и Университета Джонса Хопкинса, только для большей точности измерений использовали специальный монитор, способный отслеживать движение глаз [им был Tobii 1750]. Кроме того, на этот раз все участники эксперимента обладали практическим опытом программирования. В отличие от оригинального исследования, все испытуемые корректно идентифицировали переменные, записанные в обоих регистрах. Также специалисты пришли к заключению, что на скорость восприятия имен переменных влияет... опыт. Ничего удивительного, что специалисты, которые работали с конкретным предпочитаемым регистром, тратили меньше времени на его распознавание.
А что сегодня: Сегодня на тематических форумах все еще можно встретить дискуссии о регистрах. Многие из них крутятся вокруг стандартов, принятых в экосистемах языков программирования. Если в JavaScript нормой считается camelCase, то snake_case используется в Python (а Rust использует и snake_case, и UpperCamelCase). Тем не менее личные предпочтения продолжают играть значительную роль — а там, где начинается «вкусовщина», неизбежно вспыхивают споры. Стоит кому-то отойти от устоявшихся конвенций — поднимается шум, точатся вилы, зажигаются факелы. Один из ярких примеров — история с адаптацией книги Харольда Абельсона и Джеральда Сассмана «Структура и интерпретация компьютерных программ» для языка JavaScript. В примерах кода редакторы решили использовать snake_case вместо привычного camelCase. Предсказуемо, такое решение пришлось по вкусу далеко не всем.
Low-code (LLM, что-нибудь еще) заменит программистов
В чем был хайп. Еще несколько лет назад на рынке можно было услышать мнение, что low-code-платформы если не заменят разработчиков, то хотя бы позволят компаниям сократить ИТ-штат. Так, в 2021 году Microsoft продвигала идею Low-Code/No-Code и представила язык Power Fx, синтаксис которого основан на формулах Excel. В целом главным аргументом сторонников подхода было существенное ускорение разработки: ряд внутренних приложений и MVP, по их словам, можно было собрать за считаные месяцы.
Какие есть нюансы. Повышенный интерес к подходу мог быть вызван состоянием рынка труда. В 2018 году аналитики консалтинговой компании Korn Ferry прогнозировали нехватку более чем 4,3 млн специалистов в ИТ-индустрии к 2030 году. И в каком-то смысле этот тренд заставил участников рынка побеспокоиться. Бизнес пытался решить проблему за счет внедрения платформ, с которыми могут работать не самые технически подкованные специалисты. В 2021 году исследователи из Mendix опросили порядка 2 тыс. разработчиков и руководителей ИТ-отделов. И тогда сразу 75% респондентов назвали подход low-code «трендом, мимо которого они не могут пройти».
А что сегодня: Можно сказать, что первоначальный энтузиазм заметно поутих. И аналитики, и руководители компаний отмечают, что решения, спроектированные с помощью low-code- и no-code-инструментов, нередко приходится дорабатывать напильником. «Мне всегда казалась странной сама идея no-code — потому что любые приложения, за исключением совсем примитивных, все равно требуют существенного вовлечения инженеров, чтобы подключать базы данных, настраивать формы и разбираться, как все компоненты должны взаимодействовать друг с другом», — говорит Дэвид Майттон, директор компании, развивающей open source-инструменты для защиты веб-приложений. При этом часто бизнесу оказываются необходимы компоненты с уровнем кастомизации, превышающим возможности большинства low-code-платформ.
На первый план вышли системы ИИ и так называемый вайб-кодинг. В сети можно встретить категоричные мнения вроде: «Платформы low-code/no-code будут вымирать по мере развития LLM» или «Вайб-кодинг означает, что low-code мертв». На практике такой сценарий вряд ли реализуется, однако системы ИИ уже становятся частью самих low-code-платформ. Как говорят в компании, занимающейся цифровой трансформацией: «Грань между "гражданскими разработчиками" и профессиональными инженерами размывается, то, что раньше называли low-code, перерождается с ИИ в своей основе»
В то же время многие специалисты рекомендуют не завышать ожидания. Согласно свежему исследованию State of Web Dev AI, проведенному на основе опроса 4 тыс. веб-разработчиков, 76% респондентов считают, что за ИИ-системой нужно переписывать как минимум половину кода, прежде чем он становится пригодным для продакшена. По сути, работа с нейросетями до сих пор упирается в «проблему 70%». Большую часть кода пишет нейросеть, но результат по-прежнему зависит от оставшихся 30%, требующих опыта разработчика.
Микроплюсы микросервисов
В чем был хайп. В середине прошлого десятилетия ни одна дискуссия в ИТ-кругах не обходилась без микросервисов. В 2015 году автор книг по рефакторингу и методологиям разработки программного обеспечения Мартин Фаулер писал: «На последнем семинаре O’Reilly, посвященном архитектуре ПО, о микросервисах говорили на каждой сессии». Микросервисный хайп был настолько силен, что некоторые специалисты призывали без раздумий отказаться от монолитных приложений. Главными аргументами были: более высокая скорость разработки автономных компонентов, снижение количества ошибок благодаря меньшему объему кода в каждом модуле и улучшение производительности. Среди аналитиков и представителей консалтинговых фирм звучали радикальные мнения, что все подсистемы нужно выстраивать максимально независимыми друг от друга.
Какие есть нюансы. У тренда с самого начала были как сторонники, так и противники, которые обращали внимание на проблемы микросервисов. Все тот же Мартин Фаулер еще в 2015 году предупреждал, что микросервисная лихорадка — это проходящий тренд. Он подчеркивал, что такая архитектура создает нагрузку на инфраструктуру и команды, ее поддерживающие: «Мой главный совет — даже не рассматривайте микросервисы, пока не столкнетесь с системой, для которой монолитная архитектура действительно не подходит». Фаулер называл эти издержки «комиссией за пользование микросервисами».
Похожей позиции придерживался евангелист Kubernetes Келси Хайтауэр. Еще в 2020 году он писал, что переходить на микросервисы без должного планирования — это все равно, что менять шило на мыло, то есть плохой код на плохую инфраструктуру: «Мы собираемся "расколоть" монолит и волшебным образом обрести инженерную дисциплину, которой у нас никогда не было».
Он критиковал не только саму архитектуру, но и ажиотаж вокруг нее: «Микросервисы ведут к новым тратам, поиску новых специалистов... Компании "подсаживаются" на денежную иглу, иглу маркетинга, цепляются за хайп, который вовсе не помогает решить их реальные проблемы».
Инженер Шон Келли также отмечал, что переход к микросервисам требует опытной команды, а прирост производительности зачастую связан вовсе не с архитектурой: «Главным героем историй о росте производительности на самом деле оказываются возможности нового языка или технологического стека, а не микросервисы, — говорит Келли. — Если взять старое приложение на Ruby on Rails, Django или NodeJS, а затем переписать его на языке вроде Scala или Go (частый выбор для микросервисов), то можно получить прирост производительности просто за счет смены стека технологий».
А что сегодня: Давид Хейнемейер Ханссон — автор фреймворка Ruby on Rails и известный в сообществе как DHH — говорит о массовом разочаровании в микросервисах. В качестве примера он приводит компанию Amazon, которая в 2023 году решила отказаться от микросервисов и переписала мониторинг для своего видеосервиса в виде монолита [и это при том, что именно Amazon считались пионерами микросервисов]. Изначально система включала три компонента: конвертер медиапотока, алгоритм детектирования проблем при воспроизведении видео и управляющий инструмент. Передача данных между всеми ними приводила к появлению «бутылочных горлышек». Вместо того чтобы пытаться их чинить, команда решила кардинально пересмотреть архитектуру.
И в целом DHH поддерживает решение корпорации: «Я рад, что мы отбились от этой ужасной идеи [микросервисов], но нам все равно нужно быть начеку, чтобы не повторить ошибку». Хотя, возможно, Ханссон немного поторопился хоронить микросервисы, поскольку они все же находят применение в экосистеме интернета вещей — там, где сотни и тысячи устройств генерируют разнородные данные, и необходима возможность независимо обновлять компоненты. Так что этот тренд скорее жив, чем мертв.
Beeline Cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.
О чем еще мы пишем на Хабре:
