Будет ли важна чистота кода в ближайшем будущем

В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках. Это — с одной стороны. С другой стороны — ругают LLM, потому что код там не всегда чистый и, дескать, программирование с LLM — это не программирование вовсе, и навыки такого программиста ничего не стоят.

Мне приходит на ум то, что в принципе мы подобный слом уже видели лет 15–20 назад. Для программиста старой школы сутью программирования, собственно, было постановка задачи, её реализация с помощью алгоритма и оптимизация этого алгоритма по скорости. Сам инструмент — язык, а уж тем более чистота кода — считалась вторичной. Задачей программиста было написание в принципе работающей программы.

Что касается чистоты кода: использование отступов и понятных названий функций, переменных и классов уже считалось большой аккуратностью. Для первого поколения ПО, в общем-то, и не предполагалось, что можно эффективно и полноценно работать с чужим кодом. Появление специализированных библиотек считалось подспорьем, но предполагало, что программист и сам должен быть способен написать подобное с нуля. Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем».

Требования к программистам поменялись из-за изменения бизнес-требований. Если раньше задачей программиста было придумать и реализовать программу (он одновременно был и бизнес-аналитиком, и дизайнером, и архитектором, и алгоритмистом), то сейчас появилась возможность создавать ТЗ и интерфейс не программистам. Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.

Однако нужно понимать, что это не суть программирования. Программирование — это умение решать любые задачи с помощью ЭВМ, а поддержка кода лишь часть работы. Этот навык востребован лишь локально, исходя из конкретного пула задач (типизированные большие проекты, рассчитанные на конвейерное проектирование).

Сейчас, с появлением языковых моделей, мы видим очередную смену парадигмы: часть процессов кодирования стала беспрецедентно дешёвой. То же самое можно сказать про рефакторинг и анализ кода. Текущее поколение, считающее своим ключевым навыком не креатив и алгоритмизацию (в отличие от их предшественников), а аккуратность, стабильность и софт-скиллы, воспринимает создание ПО с помощью LLM как бы «ненастоящим» (так же, как в 90-х «системные программисты» презрительно относились к «прикладушкам»). Но всё будет решать требования бизнеса и, соответственно, бизнес-процессы.

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

В каком-то смысле 2020-е — это новые 90-е в IT, когда на сломе старых систем они становятся дорогостоящими, медленными и неэффективными, и снова становятся востребованными «хакеры», которые смогут быстро, дёшево и эффективно строить новые модели IT-систем, в том числе используя интуитивный, креативный подход. На передний план выйдут архитекторы и бизнес-аналитики, причём ключевым навыком будет именно построение самих моделей бизнес-процессов в разработке ПО.

Впрочем, пока не ясно, в какой степени можно будет доверять создание архитектуры LLM. Уже сейчас она справляется с базовыми шаблонами, но где границы — непонятно. С другой стороны, совершенно очевидно, что со снижением цены разработки коммерческое ПО станет в разы сложнее, а нынешние лидеры уйдут со сцены (пример — ABBYY, который резко потерял востребованность и перспективы после появления языковых моделей, особенно опенсорсных).

Можно также предположить, что появятся совершенно новые должности и профессии — что-то вроде совмещённого архитектора и архитектора бизнес-процессов: специалиста, который настраивает системы для автоматического создания и тестирования ПО с одновременным включением в процессы тестирования отделов продаж, дизайна, UI и так далее.

Данная публикация является личным мнением автора. Мнение владельца сайта может не совпадать с мнением автора.