Смелое заявление, да? На самом деле это очень вероятный сценарий развития событий и я расскажу как я пришел к этому выводу.
Немного предыстории
Я и моя команда занимаемся разработкой программного обеспечения уже более 10 лет с переменным успехом: среди всех проектов, которые мы делали есть огромное количество откровенно проваленных проектов по самым разным причинам. Как правило, это весь букет типичных проблем любой софтовой компании — от неправильно поставленного ТЗ и плохого управления до неумения набирать в команду и удерживать «супер талантов».
За прошедшие 10 лет мы попробовали улучшаться везде где только могли: в 2015 перешли на scrum, внедрили пакет Atlassian и средства непрерывной интеграции, придумывали как переиспользовать код создавая библиотеки и шарить между проектами. Что бы не делали, все равно нашим слабым местом так и остались сотрудники.
Работать с людьми не выгодно и даже опасно
В разработке программного обеспечения 80% успеха зависит от квалификации и вовлеченности разработчиков в процесс создания продукта. От того, какой код напишет ваш разработчик зависит то, сколько вам еще придется заплатить за рефакторинг и возможно переписывания части продукта с нуля.
Те, кто занимается разработкой программного обеспечения наверняка не один раз слышали фразу «Шеф, это невозможно дальше поддерживать. Надо все переписывать с нуля.» И честно говоря, самый ужасный случай у меня произошел с одним нашим продуктом в 2014-2016 годах. Мы умудрились переписать 4 (!), четыре раза, а потом успешно похоронили этот продукт. Хоть какая то часть была успешной 😁.
А у вас так было, чтобы сотрудник сломал ваш продукт? У меня — да. Часто это проблема плохого (ну или никакого) контроля со стороны руководителя, техлида и всех кто должен следить за качеством разработки. Пару разу у меня случалось так, что плохо контролируя разработчиков мы обнаруживали как человек «отрефакторил обратно»: все что было написано с хорошим уровнем абстракции и применены подходящие паттерны было слито в один большой файл потому, что ему было так удобно. «Старый код был слишком сложный и навороченный.» Тут ярко проявляется достаточно неочевидная проблема, когда у участников команды очень сильно отличается профессиональный уровень — джуны и начинающие мидлы не могут понять почему код у сеньора написан именно так и зачем там, например фабричный метод (порождающий паттерн).
И вот, когда вы уже на самой финишной прямой чтобы зарелизить продукт ваш очень важный сотрудник исчезает. Завтра релиз, у вас пропал ключевой разработчик и не отвечает на звонки и сообщения. Фактор автобуса? С вероятностью 99,9% автобус его не сбивал, да и вообще с ним все в порядке, кроме одного: именно сегодня он решил, что работать в вашей компании он не хочет и не будет. А дальше вам нужно выкручиваться, как только сможете — пытаться понять кто вместо него может завершить работу, сдвигать сроки, просить заказчиков войти в положение.
«Да вы просто не умеете управлять командой. Не понимаете, не стимулируете, платите мало, просите сделать неизвестно что..» — вполне возможно, но далеко не все компании, кому нужны цифровые продукты умеют делать все правильно и тем более платить выше рынка.
NO-CODE изменит рынок разработки
Самый очевидное решение большинства проблем с разработчиками — заменить человеческий труд на автоматические системы разработки приложений без написания кода.
- Больше не зависим от языка программирования
- Все визуально и гораздо более понятнее
- Намного ниже порог входа
- Там где требовалась команда из 7 человек одного хватит
- В 10 раз быстрее построить решение на NO-CODE чем писать даже с самыми продвинутыми фреймворками
- Почти нет глупых ошибок из-за невнимательности
- Стоимость ниже в разы, а иногда на порядок. Ошибки теперь стоят дешевле.
Не каждый NO-CODE сможет изменить рынок
Несмотря на то, что популярные решения типа Bubble, WebFlow, Tilda и многие другие очень активно растут, они едва-ли смогут сделать революцию в самом сложном и емком сегменте рынка — корпоративных системах и приложениях. Вышеперечисленные платформы и еще тысячи менее известных платформ действительно хороши в создании сайтов, маркетплейсов, и простых вещей для массового рынка.
Gartner и другие аналитические агентства прогнозируют быстрый переход на NO-CODE/LOW-CODE в течении нескольких лет, да и рынок растет на 22-25% каждый код и только будет ускоряться (источник). Неужели NO-CODE может совершить революцию, создавая сайтики (иногда очень красивые!) и храня данные в Google Sheets и Air Table? Очень вряд ли.
Вот, что по настоящему взорвет рынок, так это NO-CODE с кодогенерацией. Сейчас это одна из самых недооцененных технологий на мой взгляд. Ты делаешь все то же самое, только на выходе генерируется полностью работающее приложение с исходным кодом которое можно сразу запускать в продакшен.
У кодогенерации есть множество неоспоримых преимуществ перед классическими NO-CODE:
- Наличие исходного кода с комментариями и best-practice
- Отличная производительность, а иногда и намного выше чем в приложениях, написанных разработчиками
- Вы можете перегенерировать приложение раз за разом (прощай технический долг и рефакторинг 😊)
- Можно запускать ваше приложение где угодно: хочешь тебе AWS, Digital Ocean, дешевенький VPS сервер или даже свой собственный комп. Хочешь хостить свой продукт офлайн потому, что он только для внутренних сотрудников — без проблем.
- Работа с вашими любимыми SQL и NOSQL базами
- Автоматическая генерация документации
В общем все то же самое, как если бы вам приложение разработала команда разработчиков в которой одни супер профессионалы.
А как же минусы? Без них тоже никак. Для кодогенерации намного сложнее дается живой предпросмотр (live preview) пока вы ведете разработку: приложение сначала нужно сгенерировать, потом собрать, запустить и только потом показывать результат. Пока не все штуки можно реализовать по сравнению с классическим программированием, но развитие платформ в будущем уберет эти ограничения.
Какое оно, будущее разработки софта?
На самом деле очень оптимистично-радостное. Активный переход на NO-CODE с кодогенерацией освободит огромное количество разработчиков от рутинных операций по написанию кода и повысит спрос работодателей на архитекторов приложений. Архитекторам приложений больше не нужно знать языков программирования и подходов, которые есть внутри языков и фреймворков. Компании смогут создавать гораздо больше приложений для пользователей, внутренней автоматизации и даже мелких сервисов, на которые раньше было жалко времени и денег.
Постоянное повышение себестоимости разработки будет и дальше толкать компании искать альтернативы найму программистов. Спасибо пандемии и онлайну — зарплаты разработчиков очень быстро растут вместе с ажиотажным спросом на специалистов. Иногда создается впечатление, что программистам уже можно и не стараться кодить: если работодатель настолько смел и попросит покинуть компанию, то у вас в почтовом ящике уже есть с десяток оферов с открытой датой ("приходите как только сможете, мы всегда вас возьмем").
Вместо заключения
Этим постом я ни в коем случае не хотел никого обидеть. Это то, как я вижу текущую ситуацию на рынке с моей стороны. Я набил огромное количество шишек, наступил на все грабли по дороге. Не зря говорят, что самый лучший учитель — опыт: берет дорого, но объясняет доходчиво.
Два года назад я закрыл все свои предыдущие проекты, собрал команду и мы начали разрабатывать NO-CODE платформу AppMaster.io. Наша идея заключалась в том, что мы сможем создать платформу, которая генерирует серверные приложения, веб приложения и мобилки без необходимости найма разработчиков вообще. Тогда это звучало совсем бредово: «без разработчиков», но сейчас это будущее разработки.
Получится ли у нашей платформы отгрызть себе кусок рынка — покажет время. Но в одном я уверен точно: кодогенерация заменит программистов в большей части задач окончательно и бесповоротно.
Это всё влажные мечты.
Ты явно не разобрался в положении дел в отрасли.
Всякие Kite и прочее сейчас скорее мешают чем помогают, мы это тестировали специально. Это похоже на джуна предлагающего ответы со SO, не разобравшись в вопросе толком.
Крутой кодогенерирующий инструмент сделать ещё сложнее, чем GPT-x генерирующую какой-то крутой осмысленный текст.
Потому что в случае художественного текста ты можешь выдумывать все что угодно.
В случае же программистского кода, ты уже не можешь фантазировать на тему жирафа гуляющего в парке, тебе надо четко прописывать алгоритм решения конкретной задачи, а не полурандомно подставлять слова.
Короче если что-то такое и появится, то ооооочень нескоро. Лет 30 мб или больше.
Нынешние нейросети даже художественный рассказ пока что написать не могут
Насчет того чтобы нейронки писали код - согласен что это будет ооочень нескоро.
Мы например задаем требования с помощью блоков бизнес-процесса. Вполне работает даже для сложной логики.
Потрясающе. Вы на одной картинке умудрились совместить кажется все существующие стили наименования сущностей. Почему половина в kebab case, половина в snake, в половине полностью слова написаны, а в половине они сокращены до одних согласных?
Потому что систему разрабатывал сеньор, который свалил, а рефакторили джун и миддл )
Интерпретатору похрен
И че блять на этой картинке написано? Нихуя же непонятно, любой код вкурить намного проще
На самом деле - это дело привычки. Тут я вижу и плюсы и минусы относительно криейшы, на которой мучаюсь я...
Но к слову, бизнес процессами все не ограничивается, и в бп действительно иногда проще засунуть один квадрат с кодом, если лоукод требования у заказчика нет.
Хуй знает. Я уверен код с этой картинки бы занял максимум строчек 5 и был бы очевиден даже джуну
Ну, не 5, а скорее 15, фетчи с условиями, форичи...
А так, код поймет даже тестер, если его совсем чуть-чуть поднатаскать. Больше того, тестер сможет сам написать такой код, ибо перетащить с панельки элемент проще, чем вспоминать слова.
Собственно преподавал детям аналогичное для роботов - ev3g, но там плюсом ещё иконки были для большей понятности - дети в восторге и все понимали, в отличии от текста.
Ща работаю прогером на криейше, тоже "лоукод", но нифига не лоукод (по ней и сужу), и опять же, тестеры и аналитики могут сами что-то простенькое написать квадратиками.
Охуеть разница.
Тестеры с аналитиками и код также могут набросать если их поднатаскать, если это не сложный язык.
Все эти ваши ноукод системы хороши до тех пор пока не начинаются эти квадратики со стрелочками. Потому что это тот же самый код, только картинками и ущербный. Это как если ты учишься читать книжки с картинами вместо книжек с текстом. Усилий надо столько же, только потом всеравно надо переучиваться чтобы код писать.
Я сто лет назад пробовал эти хуйни с квадратиками, в итоге плюнул и научился программировать.
Эмм. Если бы научится программировать тестерам и аналитикам было бы также просто, как научится кидать квадратики - тестеров и аналитиков бы не было, ибо зп у них ниже...
Все эти "наши"? Я просто пошел работать на хорошую зп, где используется конкурент софта из статьи, нацеленный на энтерпрайз.
А касательно "это тот же код" - не отрицаю, и даже написал аналогичное где-то тут автору. Больше того, для этого даже название есть - "визуальный язык программирования".
Минусы визуала: громоздкость (огромные квадраты вместо мелких строк), каша (если код сложный) и негибкость (не на любое действие есть кубик);
но плюсы - легкочитаемость (визуал для того и создавался) и понятность (зачастую 1 квадрат выполняет целую функцию, например по созданию и выполнению sql запроса с простой настройкой условий и выдачи).
Ну есть большая разница между "программировать" и пару строчек в готовой хуйне написать.
Да нету у визуала никаких плюсов, это как в первом классе яблочки складывать вместо чисел. Пока 2+2 считаешь все красиво, а когда хотябы 10 * 6 уже нормальные цифры пизже яблок.
Нет там никакой легкочитаемости и понятности по сравнению с простым кодом. Понятны эти квадратики только тем кто учился именно их понимать. Поэтому проще сразу учиться коду.
Чем эта пиздецома с картинки понятнее чем например
orderEvents.forEach { db.delete(it.id) }мне не ясно. Я даже не уверен что правильно это говно с картинки прочитал.
Визуальное программирование хорошо там, где оно уместно. Например формулу создать приличную с помощью диаграмм - неудобно, и неудобно читать.
А вот трансформацию потоков данных, где какие-то данные расщепляются, сливаются, анализируются и т.п. - это уже нагляднее (но автор не предоставил такой случай) - такие инструменты активно применяются в анализе данных. Что-то специфическое сделать всегда быстрее на питоне с tf, но для "быстро потыкать" нормально.
Для сложной логики сначала нужно логику собрать, упростить, оптимизировать - и только потом может быть, появится внятный алгоритм, который можно описать бизнес-процессом для автоматизации.
Специалисты SAP по несколько лет аудиты проводят и решение готовят даже для небольших производств. Напомню, что система существует куда дольше Bitrix и любых знакомых вам NON-CODE окружений. Стало ли у них меньше работы или программистов? Нет.
И даже текущие клиенты вынуждены, как и клиенты 1C, с регулярной периодичностью приглашать аутсорс-разработчиков.
Выглядит как визуальное программирование в котором задание алгоритма идет через DAG. Точно такое же, как например в Unreal Engine. Как его не назови, это все равно программирование.
Визуальное программирование на самом деле намного легче обычного. Собственно, робототехнику преподавал детям от 10 лет. Там где простое раздвоение стрелочки создаёт параллельный поток, в питоне приходилось расписывать кучу строк...
Но да, визуальное программирование - это все еще программирование.
О, а я программировал на подобном ) причем прям промышленную автоматику
За каждым из кубиков спрятан код, который тоже писался прям там, а ещё пришлось сделать генератор вот таких картинок на шарпе, потому что там нет циклов и надо делать много однотипных схем )
Стало даже интересно, кто в эту хрень сможет вкатиться. Уж точно не человек без базового опыта разработки БД и программирования. И для кого тогда продукт? Девочка-менеджер скажет: "Сложнааа".