{"id":6456,"title":"\u041f\u043e\u0447\u0435\u043c\u0443 \u0434\u043b\u044f \u0441\u043e\u0445\u0440\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0438\u0445 \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c","url":"\/redirect?component=advertising&id=6456&url=https:\/\/vc.ru\/promo\/281058-pochemu-vazhno-zashchishchat-dannye-vo-vremya-obrabotki&placeBit=1&hash=dc7f2bae2bc390fd70ec9b439b852fb5901b27f8537bbae69b6bbdceddf340ad","isPaidAndBannersEnabled":false}
Будущее
Oleg Sotnikov

Через 10 лет большинство программистов уйдет из профессии

Смелое заявление, да? На самом деле это очень вероятный сценарий развития событий и я расскажу как я пришел к этому выводу.

Немного предыстории

Я и моя команда занимаемся разработкой программного обеспечения уже более 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. Наша идея заключалась в том, что мы сможем создать платформу, которая генерирует серверные приложения, веб приложения и мобилки без необходимости найма разработчиков вообще. Тогда это звучало совсем бредово: «без разработчиков», но сейчас это будущее разработки.

Получится ли у нашей платформы отгрызть себе кусок рынка — покажет время. Но в одном я уверен точно: кодогенерация заменит программистов в большей части задач окончательно и бесповоротно.

{ "author_name": "Oleg Sotnikov", "author_type": "self", "tags": [], "comments": 194, "likes": -44, "favorites": 71, "is_advertisement": false, "subsite_label": "future", "id": 277821, "is_wide": true, "is_ugc": true, "date": "Thu, 05 Aug 2021 03:23:32 +0300", "is_special": false }
0
194 комментария
Популярные
По порядку
Написать комментарий...
97

что-то подобное я уже слышал когда учился в институте на программиста, 25 лет назад. бгггггггг.
какие-нибудь однотипные интернет-магазины - да, пожалуйста. все это сейчас есть. но ничего более. вам "кодогенератор" новую ОС напишет? или может быть новый драйвер? как? или придумает новый протокол и его реализацию?

Ответить

Сельскохозяйственный

bzzztomas77
52

Да это со времен Битрикса началось. Простенький и тяжеленький магазин - Эврика! программисты больше не нужны. 

А может со времен 1С? Бухгалтеры больше не нужны, программисты тоже. Всё еще нужны? пля...

Ответить
0

Бухгалтеров действительно из-за 1С стало меньше требоваться. 

Ответить
–20

А как часто требуется разработать новую ОС? 

Ответить

Сельскохозяйственный

Oleg
35

Для роботов каждый год по нескольку, для телефонов армия Linux подкрадывается уже в этом году. Tizen от Самсунг, Ubuntu mobile от Ubuntu - одного из лидеров на серверах, в том числе в "автогенерированных" облаках типа Azure или Aws. Кстати об облаках. Это порой немногим уступает ОС. Часто требуется.
А еще для автомобилей, ракет, самолетов, спутников, холодильников, утюгов, кофемашин и всяких Iot. 

Ах да про ОС. Google тоже новую ОС задумали ;-)

Ответить
30

Ноукод решения требуют постоянно доработки кода внутри самих себя. Это, на самом деле, замкнутый круг.

прогнозируют быстрый переход на NO-CODE/LOW-CODE

Логично, если не путать слона с гитарой. Зерокод удобен, чтобы запустить МВП как можно быстрее и валидировать спрос на продукт. Если гипотезы жизнеспособны, то уже пишут своё решение. Вы же кликбейтите о каком-то чуть ли не вымирании программистов. 

Зерокод – отличный пьедестал для снижения порога входа в разработку. Это не искореняет профессию, а развивает её. Как Фигма, например, развивает дизайн. 

Ответить
–12

Или как Тильда, WebFlow и Wix позволили в одиночку делать сайты? Не нужны больше верстальщики, фронтендеры, бэкендеры. И даже сисадмины которые настроят SSL, nginx и прочие радости тоже больше не требуются в таких проектах. Было 5 человек в команде на проект, с этими инструментами одного достаточно.

Ответить
18

 Не нужны больше верстальщики

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

Не нужны больше верстальщики, фронтендеры, бэкендеры

В вашем продукте тоже, надеюсь, нет этих ненужных фронтов и бэков? 

Упрощение входа для малого бизнеса и стартапов не отражает весь рынок. Тем более, что у них часто даже нет денег на девов.  Несмотря на изобилие ноукода, спрос на программистов только растёт. Это, в данном случае, взаимосвязанные причины. 

Ответить
10

И даже сисадмины которые настроят SSL, nginx и прочие радости тоже больше не требуются в таких проектах.

Они лет 20 как "не нужны", просто тогда всем нужны были доски сообщений, гостевые книги и порталы с погодой.
Напоминаю про юкоз, народ, TemplateMonster и тысячи их аналогов. Практически каждый регистратор и хостер такое предлагал "купи, выбери шаблон, поменяй заголовок и фоновую картинку, готово."

Ответить
6

Но ведь все еще нужны. И вакансий все больше становится. 

Ответить
5

Сайты это одностаничники про себя, любимую кошку и инстаграм для продаж чего-то из Китая ?

Ответить

Сельскохозяйстве

Vladimir
1

Хах, так легко не поймаете! 
Лендинги, воронки продаж, диджитал, инвестментс, солюшнс, промоушн.  

Какие еще одностраничные сайты?  Обижаете!

Ответить
4

В одиночку делать сайты можно было и в 2007-м. Как сейчас помню платформы uCoz, XenForo и маркетплейсы с плагинами к ним. Oh no it's habbening again.

Ответить
3

Читал и ужасался. Но этот коммент расставил всё по своим местам. Викс и тильда нежизнеспособны в seo. То есть лиды с них всегда будут дорогими. Значит предыдущий комментатор прав. Зерокод решения в программировании - то же самое, что конструкторы сайтов. Сделать быстро, кастомизировать долго, дорого и всё что хочешь сделать всё равно не получится. А идею протестировать ок.

Ответить

Цивилизованный

Oleg
0

делать сайты

А причём тут Web-приложения? 

Ответить
0

Если решение может жить и продавать на wix, то мне, как программисту, оно, тем более, не нужно.

Ответить
18

достаточно часто вносятся серьезные изменения в ОС, на уровне алгоритмов. так как старые перестают работать в новых условиях. навскидку: multicore, ssd, потом nvme, новые требования по энергопотреблению и проч. все это тянет за собой серьезные изменения в алгоритмы. это для обычного пользователя новая версия ОС - только иконки и баги. а под капотом все может быть гораздо серьезнее.
ps. я занимаю разработкой файловых систем,  c 2001 года.
pps. кол-во так называемых программистов, которые кодогенерят новые магазины - да, их вполне можно и нужно уменить. но не нужно путать их с настоящими программистами.

Ответить
0

Кабаныч, твое дело - клиентам лапшу на уши вешать да маржу с задротиков стричь; думать и делать выводы о будущем - это не твоё. Так что лучше и не пытайся, только минусов нахватаешь. 

Ответить
9

С языка снял :) 17 лет в профессии и каждый год слышу о мечтах в No-Code and etc.

Ответить
2

И 10 лет назад то же самое было. Только там ещё был Ucoz. А потом ещё был битрикс, на котором "вообще всё из коробки работает, Вась, отвечаем"! Объективно, пока роботы учатся ходить, а ИИ имитирует работу ботов для квипа и джаббера, нам бояться нечего. Когда робот впервые реализует небольшое ПО по ТЗ заказчика, используя качественные паттерны и готовые реализации алгоритмов, и это будет дешевле реализации человеком, вот тогда и будем сухари сушить.

Ответить
0

по ТЗ заказчика

Вот уже на этом этапе любой ИИ уйдёт курить в сторонку от неадекватного ТЗ =) 

Ответить
0

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

Ответить

Передовой ихтиандр

53

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

Ответить

Сельскохозяйственный

Передовой
18

Ага, в данном случае даже не скрывается.

Автор или его пиарщики начали с пиздобольства, а закончили фееричным - а у нас есть ноукоде солюшн фор ю! Покупай - лопухай! 

P s. Теранос и Nikola inc, это самые масштабные, но не самые впечатляющие зомби нынешнего пузыря. Изощреных на выдумки умельцев куда больше.

Ответить

Сельскохозяйственный

46

кодогенерация- best practices, не потребует рефакторинга. Архитектура. Ахаха. 

Ну да, рефакторинга действительно не надо, стоит заговорить про кастомизацию или серьезное обновление и окажется, что генератор не осиливает, а программисту эту кашу продолжать нет смысла, а быстрее сразу переписывать
 

Ответить
–12

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

Сейчас же разработчики сами тоже не пишут стандартный функционал - они берут готовый библиотеки и счастливы.

Ответить

Сельскохозяйственный

Oleg
32

"умереннай"
"они берут готовый библиотеки и счастливы."
"велосипед, но уже сгенерированный (хоть и хорошо сгенерированный)"
Простите, но это автогенератор писал? ))))

 Хз что за проекты, которые переписывали с нуля 4 раза, но можно так легко взять и генератором сделать. 

Кстати, в вашем посте не хватает примеров. Что накодили то генераторами?  

Ответить
6

Программировать - не только текст писать. Я с 3мя визуальными языками работал плотно, и это по прежнему языки программирования. Собственно по долгу преподавания робототехники изучил вдоль и поперек scratch и ev3g, простые детские языки для игрушек и лего роботов. Сейчас вот в криейше проекты делаю, где квадраты на экране тоже можно скомпилить в код для быстродействия. 
Весь минус таких "лоукод" визуальных языков - как раз их громоздкость. То, что делается в 10 строк на питоне/шарпе с максимальным контролем, превращается в огромную кашу из квадратиков, которые ещё и не на любой машине отрисовываются, как в случае с ev3g. 

Ответить
4

Слабо написать no-code решение без единого разработчика? Вот когда напишете, тогда и возвращайтесь.

Ответить

Сельскохозяйстве

Николай
1

Он уже ответил. Разработчики не нужны, потомучто либы всё равно халявные. С неба упали. 

"Сейчас же разработчики сами тоже не пишут стандартный функционал - они берут готовый библиотеки и счастливы."

Либами как замок из Лего построит. 

Ответить
1

Ну, как бы, использовать и настроить либу - это тоже процесс разработки. Мы же не пользуемся для разработки перфокартами, не так ли?

Ответить

Сельскохозяйстве

Николай
0

Если рассуждать логично то да. Но логика закончилась еще на моменте откуда берутся либы. Их разве не пишут программисты? 

Ответить
4

Логика закончилась тогда, когда человек попытался выдать гуманитарную идею "избавиться от богомерзких программистов" за продукт "no-code". И я это дерьмо видел сотни раз: человек спутал желаемое с действительным, показал, что не знает свою целевую аудиторию, не знает продукт, за который заплатил. Ему сделали что-то, но для чего и для кого - он пояснить не может. В принципе, уже здесь его можно было слать лесом. Нет информации, какую проблему решает продукт, как он её решает, кто его купит? Просто банальная графомания. Пусть, сперва, поучится основам IT бизнеса, а потом строчит свои промо.
И, собственно, с этого же момента становится понятно, почему его продукт 4 раза переписывался, и почему его разраб кидает его в день релиза. Чел тупо не шарит в том, что делает. Плюс, он путает принцип DRY с коммерческим обоснованием no-code. Использование либ, паттернов, реализаций - это нормально, как и автогенерация кода. Но это не имеет никакого отношения к no-code концепции, которая предоставляет, по сути, code as service. То есть, есть код, который решает некие стандартные вопросы бизнеса, и он сдаётся в аренду, а владелец code as service, имеет свой отдел разработки и обслуживания. Это и есть современный no-code. Но никак не волшебное решение, которое пишет код за тебя. Если оно и появится, то появится в пресс-релизах амазона, гугла или майкрософта, но никак не в статье программистофоба Олега Сотникова.

Ответить
1

У вас, элементарно, каша в голове, и вы нас ею кормите. Основная проблема разработки - это перевести customer-требования - в development-требования. То есть, выбрать путь реализации. Например, вам нужно показать сто товаров на web-странице. Наиболее удачное решение - использовать тот же wix. На нём же можно реализовать продажу этих товаров и подключить простую аналитику. Но, когда вам нужно начать интеграцию с вашим складом, либо, у вас есть потребность в более обширной аналитике, вы сталкиваетесь с потребностью изучения ваших потребностей и поиска более сложного технического решения. И здесь уже начинается процесс разработки. Тот же wix имеет потолок в части параметров ваших товаров и скорости фильтрации по большому числу параметров. Это уже вопрос оптимизации запросов и обработки big data.

Вы совершили много ошибок, написав своё промо. К нему много вопросов. Самые основные:

1. Какая ваша целевая аудитория?
2. Какие конкретные проблемы вы решаете, и как?

Люди, которые осознают важность этих вопросов, без труда поймут, почему от вас сваливает разработчик в день релиза, и почему вы 4 раза переписываете саой продукт. Ответ очевиден: вы не знаете ни возможностей своего продукта, ни своей целевой аудитории. А значит, вы продаёте ничто никому. Вполне очевидно, что ваш продукт позволяет создать некие простые приложения в формате no-code, и вы бы это сказали, если бы был диалог между вами, и вашими разработчиками. Но вы их не слушаете. Вы пытаетесь продать нам не реализованные, утопические customer-требования, выдавая их за project features. Вполне ясно, что вы не донесли эти требования до своих разработчиков, а те, в свою очередь, не сформировали из них development-требования. Если бы вы знали разницу между этими требованиями, а также, процесс превращения одного в другое, то не несли бы ту чушь, что несёте сейчас. Вы пытаетесь поменять процесс, который не понимаете. Это как если бы я нанял пару физиков из местного политена, и начал бы писать статейки на серьёзных ресурсах на тему "я изменил принципы базовой физики".

Ответить
35

Сайт сказал что у меня слишком маленький...

Ответить
6

очень странное решение, учитывая что уже половина аудитории интернета на мобилках))

Ответить
7

Я бы понял предупреждение, но не заглушку

Ответить

Сельскохозяйственный

Rezon
0

Тихо, не подсказывайте за бесплатно. 
Демо версия фримиум:
Надо вот так:
Сайт сказал, что у меня слишком...
 ***Купите подписку на тестирование багов - 30 долларов в месяц,
распродажа - 150 долларов в год. ***
Всего несколько чашечек кофе. 

Для тестирования будут использоваться  опенсорс либы, программисты и тестеры отвыкли работать, берут всё готовое( программистами) из бесплатной вселенной, где платить программистам не нужно.  Но можно брать бесплатно не программистами, а автогенераторами хомячить. 
Дальше берете автогенератор текста, написанный автогенератором кода и фигачите отчеты. 

Ответить
33

Через 10 лет Олег Сотников уйдет из профессии. А программисты останутся. Помяните мое слово

Ответить

Сельскохозяйственный

greg
0

Олег уйдет когда за опен сорс библиотеки станут брать деньги. А прогеры этих библиотек доработают в свои продукты. Впрочем этом уже все чаще встречается, по нарастающей. Фримиум, с частью бесплатных функций и платными доп. фичами.

А что будет с гугловской Funcia которая выйдет в этом году и полностью заменит Андроид к 2023, и либами под неё уже можно представить. Windows тоже наверняка преподнесет сюрприз. Нужно будет что то новое, но уже менее бесплатное.

Ответить
29

Суть статьи.
"мы начали разрабатывать NO-CODE платформу AppMaster.io."

Ответить
26

Сначала думал что он ошибается. Потом понял что это реклама.

Ответить
23

а no-code генераторы кто пишет ? правильно, те самые джуны и начинающие мидлы, которые вчера уволились из вашей компании lol

Ответить
–12

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

Ответить

Сельскохозяйственный

Oleg
13

Вообще то многие продукты и плагины пишут как open source, либо используют open source и это "бизнесменами" воспринимается как нагенерили. Только вот такая халява была потомучто программистам платили. А теперь не платят и нафига им бесплатно либы кому то писать? 

Хоть один большой коммерсант тут написал пост про то донатил разработчикам библиотек? Или что приветствует открывать полезные участки кода, дорабатывать и публиковать в открытое сообщество в рабочее время? 

Ответить
2

Микрософт этим занимается. Инвестирует время своих разрабов в линух, и ещё донатит 50кк в год.

Ответить

Сельскохозяйстве

contiv
2

Да это понятно, что на корпорациях это тоже держится.

Но где вот такие красавчики, которые потреблители и рады поделиться своим потребительством, но не деньгами донатов? Где посты об этом от них. 

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

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

Ответить
3

"Ну так гораздо проще сделать хорошим один продукт и чтобы он нагенерил много качественных продуктов, чем каждый раз биться за нормальный код и адекватную архитектуру." Нет, не проще. Если вы безуспешно бьетесь  за нормальный код и адекватную архитектуру конечного продукта, то генератор таких продуктов вам не по зубам, это другой уровень. Другой как написать "блокнот" и операционную систему.

Ответить
2

Зачем биться за нормальный код и адекватную архитектуру, все проблемы современной разработки уже давно описаны в профильных книжках.

С чем согласен, это уровень современных разработчиков значительно упал, а так же вечная гонка за свежими фичами и расширением функционала не смотря ни на что - большая проблема не только it гигантов, но и маленьких компаний тоже. Но это другая тема для размышления.

Ответить
0

Насчет фичей согласен. Не продающийся продукт с ограниченным функционалом и отличной кодовой базой никому не нужен. Конкуренция требует новых фичей практически любой ценой.

Ответить
0

Уровень упал или технологии и требования выросли?

Ответить
0

Или расширился стэк

Ответить
0

С вашим бэкграундом это точно не светит.

Ответить
15

 NO-CODE с кодогенерацией

Это всё влажные мечты.
Ты явно не разобрался в положении дел в отрасли.
Всякие Kite и прочее сейчас скорее мешают чем помогают, мы это тестировали специально. Это похоже на джуна предлагающего ответы со SO, не разобравшись в вопросе толком. 
Крутой кодогенерирующий инструмент сделать ещё сложнее, чем GPT-x генерирующую какой-то крутой осмысленный текст.
Потому что в случае художественного текста ты можешь выдумывать все что угодно.
В случае же программистского кода, ты уже не можешь фантазировать на тему жирафа гуляющего в парке, тебе надо четко прописывать алгоритм решения конкретной задачи, а не полурандомно подставлять слова.
Короче если что-то такое и появится, то ооооочень нескоро. Лет 30 мб или больше.
Нынешние нейросети даже художественный рассказ пока что написать не могут

Ответить
–1

Насчет того чтобы нейронки писали код - согласен что это будет ооочень нескоро.
Мы например задаем требования с помощью блоков бизнес-процесса. Вполне работает даже для сложной логики.

Ответить
6

Потрясающе. Вы на одной картинке умудрились совместить кажется все существующие стили наименования сущностей. Почему половина в kebab case, половина в snake, в половине полностью слова написаны, а в половине они сокращены до одних согласных? 

Ответить
2

Потому что систему разрабатывал сеньор, который свалил, а рефакторили джун и миддл )

Ответить
–1

Интерпретатору похрен

Ответить
4

И че блять на этой картинке написано? Нихуя же непонятно, любой код вкурить намного проще

Ответить
0

На самом деле - это дело привычки. Тут я вижу и плюсы и минусы относительно криейшы, на которой мучаюсь я... 
Но к слову, бизнес процессами все не ограничивается, и в бп действительно иногда проще засунуть один квадрат с кодом, если лоукод требования у заказчика нет. 

Ответить
1

Хуй знает. Я уверен код с этой картинки бы занял максимум строчек 5 и был бы очевиден даже джуну

Ответить
0

Ну, не 5, а скорее 15, фетчи с условиями, форичи... 
А так, код поймет даже тестер, если его совсем чуть-чуть поднатаскать. Больше того, тестер сможет сам написать такой код, ибо перетащить с панельки элемент проще, чем вспоминать слова. 
Собственно преподавал детям аналогичное для роботов - ev3g, но там плюсом ещё иконки были для большей понятности - дети в восторге и все понимали, в отличии от текста.
Ща работаю прогером на криейше, тоже "лоукод", но нифига не лоукод (по ней и сужу), и опять же, тестеры и аналитики могут сами что-то простенькое написать квадратиками. 

Ответить
2

Ну, не 5, а скорее 15, фетчи, форичи...

Охуеть разница.

Тестеры с аналитиками и код также могут набросать если их поднатаскать, если это не сложный язык. 

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

Я сто лет назад пробовал эти хуйни с квадратиками, в итоге плюнул и научился программировать.

Ответить
0

Эмм. Если бы научится программировать тестерам и аналитикам было бы также просто, как научится кидать квадратики - тестеров и аналитиков бы не было, ибо зп у них ниже... 

Все эти "наши"? Я просто пошел работать на хорошую зп, где используется конкурент софта из статьи, нацеленный на энтерпрайз. 

А касательно "это тот же код" - не отрицаю, и даже написал аналогичное где-то тут автору. Больше того, для этого даже название есть - "визуальный язык программирования". 
Минусы визуала: громоздкость (огромные квадраты вместо мелких строк), каша (если код сложный) и негибкость (не на любое действие есть кубик);
но плюсы - легкочитаемость (визуал для того и создавался) и понятность (зачастую 1 квадрат выполняет целую функцию, например по созданию и выполнению sql запроса с простой настройкой условий и выдачи). 

Ответить
2

Если бы научится программировать тестерам и аналитикам было бы также просто, как научится кидать квадратики

Ну есть большая разница между "программировать" и пару строчек в готовой хуйне написать.

Да нету у визуала никаких плюсов, это как в первом классе яблочки складывать вместо чисел. Пока 2+2 считаешь все красиво, а когда хотябы 10 * 6 уже нормальные цифры пизже яблок.

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

Чем эта пиздецома с картинки понятнее чем например
orderEvents.forEach { db.delete(it.id) }

мне не ясно. Я даже не уверен что правильно это говно с картинки прочитал.

Ответить
0

Визуальное программирование хорошо там, где оно уместно. Например формулу создать приличную с помощью диаграмм - неудобно, и неудобно читать.

А вот трансформацию потоков данных, где какие-то данные расщепляются, сливаются, анализируются и т.п. - это уже нагляднее (но автор не предоставил такой случай) - такие инструменты активно применяются в анализе данных. Что-то специфическое сделать всегда быстрее на питоне с tf, но для "быстро потыкать" нормально.

Ответить
2

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

Специалисты SAP по несколько лет аудиты проводят и решение готовят даже для небольших производств. Напомню, что система существует куда дольше Bitrix и любых знакомых вам NON-CODE окружений. Стало ли у них меньше работы или программистов? Нет.

И даже текущие клиенты вынуждены, как и клиенты 1C, с регулярной периодичностью приглашать аутсорс-разработчиков. 

Ответить
1

Выглядит как визуальное программирование в котором задание алгоритма идет через DAG. Точно такое же, как например в Unreal Engine. Как его не назови, это все равно программирование.

Ответить
0

Визуальное программирование на самом деле намного легче обычного. Собственно, робототехнику преподавал детям от 10 лет. Там где простое раздвоение стрелочки создаёт параллельный поток, в питоне приходилось расписывать кучу строк... 
Но да, визуальное программирование - это все еще программирование. 

Ответить
0

О, а я программировал на подобном ) причем прям промышленную автоматику
За каждым из кубиков спрятан код, который тоже писался прям там, а ещё пришлось сделать генератор вот таких картинок на шарпе, потому что там нет циклов и надо делать много однотипных схем )

Ответить
0

Стало даже интересно, кто в эту хрень сможет вкатиться. Уж точно не человек без базового опыта разработки БД и программирования. И для кого тогда продукт? Девочка-менеджер скажет: "Сложнааа". 

Ответить
14

Лучше было бы начать продвижение продукта с продукта, а не с такого вот партизанского маркетинга. Ну или в данной статье вообще не упоминать свой продукт.

Ответить
0

Должна же быть причина почему я так двигаю no-code. Я верю, что даже если мы не сможем сделать действительно крутой продукт - то сделают другие. Это неизбежно.

Ответить
6

Причина одна - деньги.

Ответить

Сельскохозяйстве

Alexand…
2

Есть и другая - большие деньги. И новенький порш. 

Ответить
0

За no-code нет будущего. То что можно быстро заменить - заменят сервисы (соц. сети, онлайн маркет плэйсы и т.п )

То что надо писать и держать штат разработки, будет писаться. А как это будет делаться, с ассистентом программиста - нейронкой кодогениратором, или армией джунов/мидлов во главе с продвинутыми лидами отдельный вопрос.

Вы лучше запилите систему тестирования с нейронкой и no-code, это было может интересно. Которая написанный код разберёт и тестами покроет, да ещё что то сложное сможет сделать

Ответить
12

Проблема написания кода это проблема формулирования мысли.
 Любой код есть сформулированная мысль.

Вообщем-то неважно в какой именно форме этот код представлен: визуальные блоки, текст или набор звуков - cуть не поменяется.

Так вот самая большая проблема любого 'визуального' программирования - его невыразительность. 
Например визуальное представление  банального цикла выглядит как говно везде, начиная от BPMN и до любых новомодных nocode решений. Везде это выглядит непонятно и не очевидно. 

Идея кодогенерации тоже мягко говоря не нова,  более того - в ряде случаев она является стандартным решением: генерация клиентов вебсервисов по метаданным, как пример.

Но из-за того что стадия кодогенерации разовая, весь жизненный цикл приложения ей закрыть нельзя: доработки, исправления ошибок, обновление API и тд. 

Т.е ваш сервис превратится в тыкву в течение 3-6 месяцев в текущих реалиях, где всем покласть на обратную совместимость.

Ответить
0

По кодогенерации с вами согласен, по поводу визуального представления позвольте не согласиться - есть ведь промышленная автоматизация и управление лабораторные экспериментом, где, соответственно, в основном используются как раз графические языки программирования (LD/FBD и LabView). Для решаемых там задач все получается очень наглядно, видно, как и куда идут сигналы и данные, в том числе и в циклах; проблемы, скорее, возникают, когда нужно не просто меняться данными с приборами, а решать другие задачи, например, проводить математические расчёты - и рисовать замучаешься, и исторически есть уже хорошо написанные заточенные под эти задачи инструменты.

Ответить
11

все программисты станут архитекторами

Ответить

Сельскохозяйственный

алекс
1

Все архитекторы станут бизнесменами.

Ответить
2

все бизнесмены полетят на марс

Ответить
3

все полетевшие на марс выживут

Ответить

Сельскохозяйстве

Basil
4

Кто не выжил тот не бизнесмен. Кто выжил - тот "ошибка выжившего".

Ответить
3

Кто "ошибка выжившего", тот начнет вести бизнес-тренинги "Как добиться успеха", "Как стать миллионером".

Ответить

Сельскохозяйстве

Виктор
3

Кто начнет вести бизнс-тренинги "как добиться успеха" того депортируют с Марса. 

Ответить
2

Кого депортируют с Марса, тот станет программистом.

Ответить

Сельскохоз

Alex
3

Все кто станет программистами станут рекурсионными архитекторами.

Ответить
9

Хм...до этого поста я считал самой большой бедой IT индусов с их страшной любовью к копи-пастам, любителей включить в энтерпрайз код непроверенного х...на с публичных ресурсов. И всяких адептов-экстремистов паттернов и "книги четырех". Ан нет, новенькое вот подвезли...

Ответить
6

"я считал самой большой бедой IT индусов с их страшной любовью к копи-пастам"

В чем беда? Хотел дешево - получил дешево.

Программирование мне не близко, но думаю это рядом с написанием текста.
Если ты платишь человеку 30-60 руб. за страницу А4 3000 знаков. То как можно ожидать, что человек хотя бы прочитает то , что он накопипастил?

Ответить

Сельскохозяйственный

Alex
1

Что не так с ООП, паттернами и книгой четырех?

 Паттерны базируются на принципах ООП. 
А ООП пришло в PHP, частично в javascript. Ну и то что Андроид, iOS использует ООП и паттерны в большом количестве вы наверное тоже в курсе? 

Ответить
5

С ними все прекрасно. Если понимать что это лишь инструмент (и далеко не единственный) и использовать его исключительно по назначению. Я именно поэтому включил слово "экстремисты" в их описание. 

Ответить

Сельскохозяйстве

Alex
1

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

Про адептов- экстремистов паттернов честно говоря не слышал. Ну разве что в рамках антипаттернов. Так это ж неправильное применение. Всего чего угодно, проблема не в паттернах, а в кривых руках. 

Ответить
1

использовать его исключительно по назначению

Даже HelloWorld надо писать с использованием паттернов, если код вообще в принципе собираются поддерживать, а не СДАТЬ ВСРОК, РЯЯЯ.

Ответить
8

Идея программирования без программистов витает в воздухе больше чем автору лет. 
А программистов все больше и больше требуется

Ответить
2

Примерно с 70х и появления первых промышленных типа NO-CODE систем от SAP и Siemence? 

Ответить
4

Когда в 50-60-х придумывали языки высокого уровня, то тоже думали, что они настолько простые, что программисты будут не нужны, а специалисты в других областях сами себе будут писать прикладные программы.

Ответить

Сельскохозяйстве

Artem
1

А еще конструкторы персональных компьютеров, которые нужно было собирать самим в доэплловские времена. Юзеры и ИТ бизнесмены были куда прошареннее. 

Ответить
0

Ну ты сравнил. Хотелки с 70х тоже выросли, а языки действительно простенькими стали, что даже школьники могут писать приложухи для себя в 14. 

Ответить
8

Это светлое будущее нам IBM обещал причем не 20 лет назад, а 30 :) Все еще его не наблюдаю. 

Ответить
8

Так и не смог посмотреть как это у вас работает.
Можно ли за месяц быстренько сделать себе приложение за 250 баксов и уйти от вас?

Ответить
7

очередной пиздобол

Ответить
7

Одна из основных причин падения уровня разработчиков сокрыта в корпоративной этики. Раньше чувак шел за помощью на форум и получал шквал негатива за свой говнокод, от чего становился лучше. Сегодня ревью принято проводить, так скажем "мягко", по принципу - работает и ладно, что не развивает уровень разработчиков.
И ещё не понятно, почему у вас Джуны лезут в код синьоров.
Не понятно на чем вы разрабатываете, о каком языке говорите, какой фраймворк используете?

Ответить
2

Нууу. У нас в фирме постоянно задачка возвращается на доработку, если ревьюеру не понравился код... Пишет что как и где. Прекрасно "дрессирует" такой подход. 

Ответить
0

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

Ответить

Животный завод

Game
1

Спасибо, но именно поэтому спрашиваю на английском сегменте SO.

Ответить
7

Прочитав пост, я понял почему у вас не получилось в разработке

Ответить
6

Желаю вам успехов, но дев и ноукод не противопоставление скорее, а этапность. Пока продукт молод / нет целей усложнять - ноукод хорош. Если переросло во что-то серьезное - от нормальной разработки не деться - это как консоль на кнопочки пытаться заменять. До поры до времени ок, и то - не всегда целесообразно

Ответить
5

Интернет большой, всем места хватит.

Ответить

Цивилизованный ГОСТ

5

Глупость какая-то)) 

Ответить
5

Хорошая попытка прорекламировать свой продукт, но нет. Этой сказке уже больше десятка лет, даже Греф повёлся, потом, правда, отмазывался, что, мол его не так поняли, когда не взлетело. BPM, NO-CODE - все это хорошо работает на типовых моделях, которые, внезапно, уже малоприбыльны для бизнеса (ну, за исключением магазинов в даркнете). Весь цимес и конкурентные преимущества именно в особенных фишках, а вот они требуют разработки.

Ответить
4

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

Ответить
4

готов поспорить на ящик хорошего коньяка, что это не так... :)
то, что кто-то считает программистов 1С недопрограммистами - это его проблема..
ну появится новая профессия ноукод-программер.. :)

Ответить
4

Плохое руководство и сейчас думает, что ему никчемных сотрудников заменит автомат. 
Не заменит. Потому что на поддержку автомата надо будет в два раза больше сотрудников. 
А при таком руководстве и в три раза . 

Ответить
3

Это простор упрощение труда сотрудника, а не его замена

Ответить
3

Приходится поддерживать лоукод решение. Я активно ненавижу его разработчиков. Фичи, которые не предусмотрены, приходится внедрять костылями. Каждый отдельный модуль - это костыль. Все решение - один большой костыль. Его разрабы все пихают в сессию и борются с интерфейсом, чтобы не открывались одинаковые окна, это сбивает состояние сессии в другом окне. Попытки привести свой модуль к нормальной реализации приводят к мучительной интеграции с другими модулями. Т.е. без досконального знания архитектуры этого "продукта", его поддержка и расширение невозможны.

При этом, реализация из коробки работает, если не предъявлять требований.

Ответить
3

Yii2 Gii 😄

Ответить
2

Интересно, кто, по мнению автора, будет заниматься разработкой и интеграцией всех этих no code систем. Программисты ему видите ли не нужны...

Ответить
2

Греф, перелогинься

Ответить
2

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

Ответить
2

В общем, судя по статье, человек, который это писал  работает в айти индустрии не так долго ( от силы лет 5-7). Отсюда и выводы вполне очевидные у него. Только вот если вот вспомнить что было до начала его деятельности, то мы увидим те же самые попытки сделать кодогенераторы чуть не со времн основания IBM. Только вот за 30-40лет, это так и остаётся утопией.

Моё мнение: не буду утверждать  что это совсем невозможно, но все универсальнальные решения, типа кодагенератора, сталкиваются всегда с одной и той же проблемой. Если делать его простым, то получаешь маленькие возможности и многое все равно допиливать руками (т.е. сам смысл генератора теряется). Если делаешь крутую систему, с большим функционалом, то это приводит к написанию или настройкам  намного более сложным чем написание программы, а так же к крайней тормознутости системы, т.к. кейсов становится много.

В общем, не вы первый, не вы последний.

Ответить
2

Определенно, нет. Во-первых, нокоду уже сто лет в обед (возьми любой конструктор сайтов , интернет-магазинов итп). Во-вторых, нокод решает только примитивные задачи примитивного в целом общества ( создать приложение или сайт для заказа пиццы, товара, и прочего). Покажите мне нокод, который сможет создать игру уровня Skyrim. Или напишет автопилот для Теслы. И тогда я поверю всему. Но пока, определенно нокоду до программистов- как до Китая крабом.

Ответить
0

Добрый день. Олег, может специально или нарошно Вы игнорируете очевидную вещь... Человечество всю свою историю пытается автоматизировать всё и вся на сколько это возможно от копья до чпу станка... Проблема в том, что нужен человек обладающий соответвующими навыками и прямыми руками , и no-code ну ни как не решает эту проблему, а иначе зачем нужны Вы ?))

Ответить
1

Максим, я совершенно согласен с вами! Просто раньше требовалось гораздо больше людей чтобы выполнять операции. Больше нет телефонисток, лифтеров и других профессий - они больше не нужны, их труд заменил прогресс. Почему прогресс невозможен для разработчиков?

Ответить
7

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

Никакого вытеснения профессии разработчика в ближайшем будущем не случится. Автоматизация вытесняет только рутинные операции. Телефонистки, лифтеры и машинистки могут работать тупо скриптам, особо не включая голову. А вот разработчики - не могут. У них работа интеллектуальная, ни к каким скриптам ее не свести. Иначе зачем бы вам нужна была вся эта свистопляска с делением на джунов, миддлов, синьоров и прочих архитекторов?

Вот, например, всякие кады и скады отнюдь не вытеснили профессию инженера (хотя чертежников - да). Ровно наоборот, инженеров стало только больше и они делают все более амбициозные проекты.

Электронные словари и системы автоматического перевода не вытеснили профессию переводчика. Наоборот, переводчиков сейчас столько, сколько не было никогда.

И почти со всеми творческими или интеллектуальными видами деятельности так: юристами, маркетологами, дизайнерами. Автоматизация там позволяет убрать рутину, тем самым снижая стоимость. А это, в свою очередь, делает их услуги все более доступными, в результате спрос растет, особенно в сторону реализации все более амбициозных проектов, которые раньше казались невозможными и которым нужны все более квалифицированные специалисты.

Вот точно так же будет и с разработчиками.

Лоукод и ноукод далеко не вчера появились. Хоть последняя волна хайпа вокруг них началась только пару лет назад, мэйнстримом такие системы стали еще лет 25 назад. Вспомните те же Access, FileMaker, или продукты Борланда. Они все вполне успешно решали самые актуальные задачи своего времени.

И главных проблем у всех лоукод систем три. Первое - они позволяют быстро создать работающий прототип, но с ними невозможно сделать конкурентоспособный продукт. За счёт большей гибкости конкуренты вас всегда обойдут. Второе - они не позволяют создавать сильно сложные системы, что делает их мало пригодными для задач автоматизации в крупных компаниях. Получается много странным образом связанных маленьких систем, которые потом все равно придется интегрировать. Что в случае с лоукод гораздо сложнее. Третье - проблемы с масштабируемостью, обычно начинаются когда проектировщиков в этом лоукод становится два, а если хотя бы 5-10 - все, тушите свет (вот именно поэтому главный пользователь таких систем - архитектор). 

В целом, у лоукод систем есть своя ниша и довольно светлое будущее. Автоматизация тривиальных задач для мелкого бизнеса, которому заказная разработка не по карману. Ну там учёт клиентов или управление закупками продуктов на кухню. А для большего придется изобрести что-то радикально новое. Что-то, что позволит эффективно бороться со сложностью создаваемых систем.

Ответить
0

Очень даже прогресс переводчиков вытеснил. Они сейчас готовы работать за еду

Ответить
0

Их труд прогресс заменил, породив другие профессии с другим набором обязанностей. На месте одной вахтерши появился электрик, монтажник, разработчик софта, разработчик железа, цепочка изготавливающих видеокамеры людей, ещё одна - добывающих для этого ресурсы. И, конечно, масса продавцов и менеджеров. 

Вроде бы все они почти не участвуют, вроде бы сильно дешевле и проще поставить камеры. Но тут все как с примером об урнах в "Ководстве" - все зависит от задачи. А если вы ничего не видите, это не значит что этого нет. 

Ответить
0

Комментарий удален по просьбе пользователя

Ответить
1

Не сократится. У них будут другие задачи. 

Ответить
1

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

А зачем и кому нужна ваша платформа и похожие конструкторы?

Ответить
1

Я не понял. А кто no-code писать будет? Высший инопланетный разум?

Ответить
1

Напоминает 1С.
Ноукод.

Вот только программисты все ещё нужны.
Но да, потихоньку гиганты будут заполнять ниши в самых востребованных решениях 

Ответить
1

А потом будет ии который все напишет сам, просто каждый месяц будет приходить смс о зачислении шестизначной суммы на счет. Единственный напряг - выбор вина в ресторане. 

Ответить
1

Уважаемые коллеги. Будьте добрее и человечнее. Да, человек захотел попиарить свой продукт. А разве это здесь запрещено? Нет. Наоборот поощряется. Да, захотел похвалиться своим продуктом. И это нормальное желание. Зачем столько срача? Возможно вы все не со зла, но со стороны выглядит это так. Вспомните себя, когда ваши "гениальные" идеи опускали друзья и близкие. Как вы доказывали свою правоту. И как падал энтузиазм после этого. Не у всех так, но у большинства точно. А человек пробует, развивается, что-то делает. Да, возможно сейчас это пока сырой продукт, но если он его нё забросит, возможно лет через несколько появится большая группа поклонников. А может и мы с вами. Но не надо сразу негатив разбрызгивать. Не нравится, не пользуйтесь. И всё. Или напишите что бы вам хотелось видеть в проектах такого рода. Обратная связь дорогого стоит. А в данной ситуации автору пришлось откровенно защищаться. Будьте мягче. И возможно наш технический прогресс начнё-развиваться быстрее. Всем успеха!

Ответить
0

Когда автор этих строк потратит 100500 денег, создаст "решение", которое вряд ли переплюнет по функционалу ту же тильду и он начнет рвать волосы далеко не на голове, вот тогда пусть вспомнит, почему я не послушал людей, которые много лет в профессии, и знают, что в большинстве случаев кодогенерация - это антипаттерн, а кол-во кода, которое надо написать, что бы генерировать логику и закрыть хотя бы малую часть функциональности той же тильды, далеко превышает возможности его кошелька. Далее, на поддержку и кастомизацию nocode решений все равно будут нужны программисты, но уже со знанием, причем углубленным знанием, авторского продукта. И именно такие продукты создают дополнительный спрос на программистов, потому что никому не будет достаточно той шаблонной логики, что сгенерирует ваша система.

Ответить
1

Это все влажные мечты менеджеров. По факту такого не будет. Менеджеры всегда возбуждаются от подобных систем. Сейчас мы выгоним всех этих дурацких разработчиков и будем делать все на изи. А в результате, чтобы удовлетворить запросы бизнеса, все равно идут к разработчикам т.к. нет абсолютно гибких и эффективных систем. Или она гибкая, но, чтобы ей пользоваться, требуется по факту тот же разработчик (типа 1С).

Ну и, в любом случае, инженерных задач хватит на всех

Ответить
1

На мой взгляд у подобных "No Code" решений, есть ниши, где они точно будут востребованы.
С учетом, что стоимость разработчиков стремится вверх, а работодатель стремится снижать расходы, спрос на подобные решения будет стимулироваться со стороны топ-менеджмента. 
Видел в своей практике, как используются подобные решения, в том числе, для построения MVP, когда нужно быстро набросать приложение, что бы показать его, и получить одобрение на полномасштабный проект. 
Что касается "ухода программистов из профессии", то тут я бы сказал по другому, скорее произойдет переток программистов из одной сферы в другую. Кто-то же должен писать эти No Code платформы ))

Ответить
1

Читать я, конечно, не буду, потому что заголовок - бред. 
Чтобы около подобное произошло нужно продумать не просто структуру кода и машинное обучение, а создать самый настоящий ИИ, как в фильмах.

Ответить
1

Это как разговоры о беспилотниках, помню, когда Убер еще был "на коне" в 2015 году, сколько идиотов спорило со мной, что со дня на день появятся беспилотники и таксисты будут не нужны, люди прям в истерике бились разбрызгивая слюни на киллометр, что год-два и всё.
 А в производственной сфере? Вот-вот с минуты-на-минуту, всех заменят роботы, эти крики с 90-х годов у особо одаренных идут. А в результате "прогресса", уже не стало самих заводов и территории застроили бетонными коробками-человейниками.
А помните, с каким пафосом и помпой рассказывали на каждом углу о кафе с роботами-поварами и роботами-официантами? Каждый мальчик-девочка со смузи в подвернутых штанишках, аж оргазмической дрожью исходил от этих новостей, и с прерывистым дыханием вещали о новой эре без официантов и поваров... потом правда выяснилось, что почти все так же готовили люди, а роботы просто смешивали ингредиенты и разогревали, да и вообще имели очень ограниченный функционал, ну да это ж мелочи..
Про "искусственный интелект" и говорить нечего, все это, в лучшем случае, работает криво и навряд ли когда-нибудь заработает так как должно - относительно адекватно и без сбоев. Зачем фантазировать о роботах и ИИ, есть же, например, Яндекс.Навигатор (ну или любой другой сервис Яндекса), уже 10 лет существует, а все так же водит через перекрытые улицы, закрытые дворы, разведенные мосты, дороги которых нет и т.д., а ведь это просто приложение, а не сложный ИИ или беспилотник или NO CODE. Все эти проекты (ну хорошо, не надо кидаться тапками, не все, но многие) - ИИ, NO CODE, беспилотники, Big Data существуют только для одной цели - получить гранты, насс..ть в уши инвесторам, поднять цену акций, красиво отчитаться о "народном достоянии" и "гордости отчественной IT индустрии" и т.д.
Ну а результат всего этого не тот о чем нам рассказывают и рисуют розовые картины счастливого будущего, а такие уродливые вещи как OZONы Маркеты разные, чат-боты поддержки, "экосистемы" различных сберов, рейтинги всего и вся, поисковые выдачи в которые невозможно уже пробится сколь-либо нужному и интересному сайту, поскольку вся первая и вторая страница забита маркетами, рекламой, "колдунщиками" и википедией с ютубом и дзеном в обнимку. Вот он истинный результат прогресса.

Ответить
1

Я сначала подумал что через 10 лет большинство программистов будет жить на пассивный доход и заниматься своим хобби... А тут эта статья, нас всех заменят роботы! Это будет чудесно, если мне больше не придется фиксить какие-то критические баги в многопоточном embedded приложении прямо перед дедлайном, когда наличие этого бага может привести к простою множества заводов по всему миру... зачем такой стресс вообще человеку нужен, если можно просто внедрить no-code.

А как на счет уже написанного ПО? Если каждый год выпускается множество проектов и они часто прямо или опосредовано связаны с софтом. Куча нового софта пишется, кто этот софт будет поддерживать? По мне, так все будет наоборот, как раз ключевой фразой этой статьи является
> Что бы не делали, все равно нашим слабым местом так и остались сотрудники.

Скорее всего через 10 лет вам будет сложнее найти хорошего программиста чем сейчас. И No-code станет для вас решением, если у вас типовый проект.

Ответить