Смелое заявление, да? На самом деле это очень вероятный сценарий развития событий и я расскажу как я пришел к этому выводу.
Немного предыстории
Я и моя команда занимаемся разработкой программного обеспечения уже более 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. Наша идея заключалась в том, что мы сможем создать платформу, которая генерирует серверные приложения, веб приложения и мобилки без необходимости найма разработчиков вообще. Тогда это звучало совсем бредово: «без разработчиков», но сейчас это будущее разработки.
Получится ли у нашей платформы отгрызть себе кусок рынка — покажет время. Но в одном я уверен точно: кодогенерация заменит программистов в большей части задач окончательно и бесповоротно.
кодогенерация- best practices, не потребует рефакторинга. Архитектура. Ахаха.
Ну да, рефакторинга действительно не надо, стоит заговорить про кастомизацию или серьезное обновление и окажется, что генератор не осиливает, а программисту эту кашу продолжать нет смысла, а быстрее сразу переписывать
Как раз таки обновление и умереннай кастомизация - легко. А вот когда нужно что нибудь в обход стандартов - то тоже будет велосипед, но уже сгенерированный (хоть и хорошо сгенерированный). В любом случае генераторы все лучше и лучше становятся.
Сейчас же разработчики сами тоже не пишут стандартный функционал - они берут готовый библиотеки и счастливы.
"умереннай"
"они берут готовый библиотеки и счастливы."
"велосипед, но уже сгенерированный (хоть и хорошо сгенерированный)"
Простите, но это автогенератор писал? ))))
Хз что за проекты, которые переписывали с нуля 4 раза, но можно так легко взять и генератором сделать.
Кстати, в вашем посте не хватает примеров. Что накодили то генераторами?
Программировать - не только текст писать. Я с 3мя визуальными языками работал плотно, и это по прежнему языки программирования. Собственно по долгу преподавания робототехники изучил вдоль и поперек scratch и ev3g, простые детские языки для игрушек и лего роботов. Сейчас вот в криейше проекты делаю, где квадраты на экране тоже можно скомпилить в код для быстродействия.
Весь минус таких "лоукод" визуальных языков - как раз их громоздкость. То, что делается в 10 строк на питоне/шарпе с максимальным контролем, превращается в огромную кашу из квадратиков, которые ещё и не на любой машине отрисовываются, как в случае с ev3g.
Слабо написать no-code решение без единого разработчика? Вот когда напишете, тогда и возвращайтесь.
Он уже ответил. Разработчики не нужны, потомучто либы всё равно халявные. С неба упали.
"Сейчас же разработчики сами тоже не пишут стандартный функционал - они берут готовый библиотеки и счастливы."
Либами как замок из Лего построит.
Ну, как бы, использовать и настроить либу - это тоже процесс разработки. Мы же не пользуемся для разработки перфокартами, не так ли?
Если рассуждать логично то да. Но логика закончилась еще на моменте откуда берутся либы. Их разве не пишут программисты?
Логика закончилась тогда, когда человек попытался выдать гуманитарную идею "избавиться от богомерзких программистов" за продукт "no-code". И я это дерьмо видел сотни раз: человек спутал желаемое с действительным, показал, что не знает свою целевую аудиторию, не знает продукт, за который заплатил. Ему сделали что-то, но для чего и для кого - он пояснить не может. В принципе, уже здесь его можно было слать лесом. Нет информации, какую проблему решает продукт, как он её решает, кто его купит? Просто банальная графомания. Пусть, сперва, поучится основам IT бизнеса, а потом строчит свои промо.
И, собственно, с этого же момента становится понятно, почему его продукт 4 раза переписывался, и почему его разраб кидает его в день релиза. Чел тупо не шарит в том, что делает. Плюс, он путает принцип DRY с коммерческим обоснованием no-code. Использование либ, паттернов, реализаций - это нормально, как и автогенерация кода. Но это не имеет никакого отношения к no-code концепции, которая предоставляет, по сути, code as service. То есть, есть код, который решает некие стандартные вопросы бизнеса, и он сдаётся в аренду, а владелец code as service, имеет свой отдел разработки и обслуживания. Это и есть современный no-code. Но никак не волшебное решение, которое пишет код за тебя. Если оно и появится, то появится в пресс-релизах амазона, гугла или майкрософта, но никак не в статье программистофоба Олега Сотникова.
У вас, элементарно, каша в голове, и вы нас ею кормите. Основная проблема разработки - это перевести customer-требования - в development-требования. То есть, выбрать путь реализации. Например, вам нужно показать сто товаров на web-странице. Наиболее удачное решение - использовать тот же wix. На нём же можно реализовать продажу этих товаров и подключить простую аналитику. Но, когда вам нужно начать интеграцию с вашим складом, либо, у вас есть потребность в более обширной аналитике, вы сталкиваетесь с потребностью изучения ваших потребностей и поиска более сложного технического решения. И здесь уже начинается процесс разработки. Тот же wix имеет потолок в части параметров ваших товаров и скорости фильтрации по большому числу параметров. Это уже вопрос оптимизации запросов и обработки big data.
Вы совершили много ошибок, написав своё промо. К нему много вопросов. Самые основные:
1. Какая ваша целевая аудитория?
2. Какие конкретные проблемы вы решаете, и как?
Люди, которые осознают важность этих вопросов, без труда поймут, почему от вас сваливает разработчик в день релиза, и почему вы 4 раза переписываете саой продукт. Ответ очевиден: вы не знаете ни возможностей своего продукта, ни своей целевой аудитории. А значит, вы продаёте ничто никому. Вполне очевидно, что ваш продукт позволяет создать некие простые приложения в формате no-code, и вы бы это сказали, если бы был диалог между вами, и вашими разработчиками. Но вы их не слушаете. Вы пытаетесь продать нам не реализованные, утопические customer-требования, выдавая их за project features. Вполне ясно, что вы не донесли эти требования до своих разработчиков, а те, в свою очередь, не сформировали из них development-требования. Если бы вы знали разницу между этими требованиями, а также, процесс превращения одного в другое, то не несли бы ту чушь, что несёте сейчас. Вы пытаетесь поменять процесс, который не понимаете. Это как если бы я нанял пару физиков из местного политена, и начал бы писать статейки на серьёзных ресурсах на тему "я изменил принципы базовой физики".