Intro
Невозможно ошибиться, если на вопрос о самых сложных программах - упомянуть прошивки FADEC и автопилот Бурана. Что между ними общего? Это ultra-reliable код, исполняемый в RTOS-условиях - то есть буквально апогей программирования с выверенным каждым тактом и несколькими уровнями отказоустойчивости программ. Тем удивительнее, что все программы такого уровня разрабатываются только по Low-Code методикам - и началось это задолго до текущего хайпа.
В данной статье предлагаю немного разобраться - где же проходят условные границы требуемых навыков и применимости подходов.
Retro
Давайте сразу уточним терминологию: "программировать" (programming) - это буквально декомпозировать и структурировать задачу в набор и последовательность конкретных действий. А "кодировать" (coding) - это превращать последовательности действий непосредственно в код.
Очевидно, практически не существует исключительно программирования или чистого кодинга, но суть обсуждаемой темы - именно в их процентном соотношении в различных задачах. На заре программирования, когда не существовало "библиотек" на каждый случай жизни и различного высокоуровнего инструментария (а также, что немаловажно, миллионов типовых задач а-ля "три в ряд") - основная работа программистов сводилась к глубокому анализу задач и хардкорной математике. И только после детального листинга формул начинался довольно рутинный низкоуровневый кодинг.
Однако, [с приходом интернета, мобильных приложений и цифровизации] за последние 10-15 лет всё диаметрально перевернулось - индустрия стала генерировать тысячи довольно идентичных проектов без необходимости тяжёлой математики, а соответствующее развитие высокоуровневых языков окончательно сместило акцент требуемых от SW-разработчиков навыков с программирования на кодинг. Здесь можно было бы резонно возразить, что даже ширпотребную современную программу сложно представить без навороченного фильтра, сортировки и/или FFT - но именно они в первую очередь и представлены в виде готовых кусков кода, а математически придуманы десятилетия назад.
И вот тут мы подошли к самой сути различий современных программирования и кодинга.
Разница постановки задач
Давайте для ясности картины возьмём две довольно типовые задачи с явным доминированием одного аспекта над другим.
Кодинг:
"Надо сделать онлайн банкинг с вот таким облачным бэкэндом, таком интерфейсом и с такими кнопками вызывающими такие опции. Нужен быстрый MVP и будем допиливать релизы."
Программирование:
"Есть вот такой реактивный двигатель с сотнями взаимосвязанных нелинейных переменных. По нажатию кнопки он должен автоматически поддерживать заданную скорость при любых допустимых условиях эксплуатации." (К слову - это и есть упомянутая выше прошивка FADEC).
Утрируя, современный кодинг - это когда в требуемой среде/языке реализуется конкретный функционал с любым доступным инструментарием и любым количеством костылей с возможностью последующей доработки. А чистое программирование... Ну вы поняли :)
Так и что же такое Low-Code программирование?
Задачи программирования становятся всё сложнее и требуют минимальной вероятности ошибки, а задачи кодирования таких программ становятся всё более стандартизованными. В итоге, уже как пару десятилетий назад были разработаны такие среды программирования, как SimuLink, VisSim и т.п. Именно они стали пионерами "Low-Code" философии задолго до появления устоявшегося термина.
В Low-Code средах программисту отводится самая ответственная роль - грамотно разработать прозрачную программу, используя заранее заготовленные куски идеального кода. Весь листинг компилируется автоматически, и может быть даже транслирован в готовый машинный код (исторически, компиляция шла преимущественно в языки группы С, но развитие LowCode-философии расширяет этот перечень).
Очевидно, такой подход полностью избавляет от ошибок на уровне синтаксиса и механической работоспособности кода.
Также, большим плюсом является удобство оптимизации программы для минимизации требуемых вычислительных ресурсов.
Фактически любое развитие и переработку проекта можно совершить без создания огромного теневого легаси и кучи костылей.
Но, конечно, есть и минусы:
Финальный скомпилированный листинг практически нечитаем человеком при необходимости. (Эта проблема известна давно, но особенно получила развитие в свете AI и нейросетей - нам далеко не всегда понятно как вообще работает этот сумбурный код).
Хотя процессорную часть можно гибко оптимизировать, работа с памятью в полученном листинге может быть далеко не лучшей.
Опять же, такие среды программирования совершенно не способствуют изучению современных методик кодирования.
Кодинг на высоком уровне абстракций
С другой стороны, к однозначным и крайне важным плюсам подхода собственноручного высокоуровневого кодирования (особенно на языках типа JS, Py, и тп) можно отнести следующее:
Крайне низкий порог входа в индустрию: фактически, уже лет с 5 можно начинать писать простой исполняемый код, а старшеклассники и студенты давно массово работают на фрилансе и в небольших проектах.
Быстро, понятно, результативно: когда нужен конкретный небольшой продукт, его намного проще написать "руками", чем корячиться через визуализацию.
Гипер-раздутая индустрия с приоритетом ручного кодинга имеет и свои негативные нюансы:
Низкая индивидуальная ответственность, особенно в корпоративном сегменте. Тут, конечно, ещё наложились злополучные вотерфолы и канбаны, которых в серьёзном программировании всё-же поменьше.
Огромное количество легаси, и весь функционал добавляется преимущественно "сверху". Низкая возможность фундаментальной переработки продукта.
Пара слов о рынке труда
Уровень зарплат - это безусловно отдельная огромная тема. Но если максимально кратко, то, как говорится в народе, "рыночек порешал": до недавнего времени даже ведущие инженеры-программисты в СНГ получали отсилы как джуны в типовом SW-кодинге - при чудовищной разнице в требуемом уровне квалификации совсем не в пользу последних.
С другой стороны, недавно выяснилось, что 60% рядовых IT-сотрудников США в лучшем случае не мешают работать остальным. (Об этом: помпезно на русском, грустно на английском, и немного сухих фактов от хабровчан).
Итого
В современном мире - программирование, очевидно, не является завершенной деятельностью без кодирования, но и кодирование является лишь малой частью огромного айсберга программирования.
На мой взгляд, развитие LowCode подходов для более широкого круга проектов позволит значительно оздоровить и перебалансировать рынок SoftWare-разработки (хотя и не без потерь), что, в конечном счёте, однозначно хорошо в средне-дальней перспективе.
Комментарии (25)
debagger
20.12.2022 05:27+4развитие LowCode подходов для более широкого круга проектов позволит значительно оздоровить и перебалансировать рынок SoftWare-разработки
Ничего подобного не случится и не надейтесь.
Сложность предметной области проекта никуда не денется, просто частично перенесется на уровень "заранее заготовленных кусков идеального кода", которые еще кто-то должен спроектировать, предусмотрев все краевые условия, ограничения и возможные сценарии использования (что требует гораздо большей квалификации).
Как вы сами отмечаете, low-code подход давно известен, но не получил широкого распространения, и это как бы намекает...
Dotarev
20.12.2022 07:27Это намекает на то, что у всякой задачи свои методы решения.
При написании программ для PLC я быстро пришел к необходимости использовать Sequential Function Chart (он же SFC). Участок программы, который при использовании "чистого" ST быстро превратился в "спагетти-код", был на удивление лаконичен и понятен в терминах SFC.
debagger
20.12.2022 08:28+8Это намекает на то, что у всякой задачи свои методы решения.
Так и есть. SFC хороший пример адекватного инструмента для своей предметной области. Для "широкого круга проектов" он не подходит.
А "спагетти" можно и с помощью визуальных языков наворотить. Только вот языки общего назначения обычно дают способы борьбы со спагетти-кодом, а low-code далеко не всегда...
MentalBlood
20.12.2022 10:31+5Вот это я понимаю визуальное программирование — "спагетти" выглядит как спагетти )
mianoki Автор
20.12.2022 21:48-2Именно так. Создание выверенных типовых паттернов всегда требует намного бОльшей квалификации, однако это делается условно один раз.
Думаю, расцвет LowCode настанет лет через 5, когда начнут массово взрослеть дети, родившиеся уже "в интернете" и "в приложениях", а не в командной строке с прописываемыми каждый раз вручную директориями файлов :)
shasoftX
20.12.2022 05:54+7В Low-Code средах программисту отводится самая ответственная роль - грамотно разработать прозрачную программу, используя заранее заготовленные куски идеального кода.
Всё становится печально когда оказывается что для вашего случая нет заранее "заготовленного куска идеального кода".
mianoki Автор
20.12.2022 21:40-1Да, соглашусь, это проблема. Более того, мой коллега однажды выловил даже ошибку в одном и заранее заготовленных кусков (справедливости ради, это был тулбокс с каким-то мега-специфическим именным дифуром).
Однако невероятная редкость таких случаев как раз указывает на высокую эффективность и стабильность подхода в целом.
klimkinMD
20.12.2022 09:13+5Мне кажется: noCoder, lowCoder, coder суть одно и тоже -- издержки индустрии.
Меня всегда учили, что "программиста на языке" не бывает... как и без языка (звучит, с моей точки зрения, как "кузнец, английским типом молотка, весом 530 грамм")
StjarnornasFred
20.12.2022 09:45+2Ну почему же. Есть middle водитель категории B, C, D, есть senior driver со всеми категориями, но это редкость. Кузнец бывает с ручным молотом, с электрическим станком. Из более высококвалифицированного - лётчик, который учится даже не под класс, а под конкретную модель самолёта, а под другие ему нужно переучиваться (хоть и, конечно, не с нуля - теория-то общая). Так и с программистами: общие базовые знания, но практические навыки под каждый рабочий инструмент свои.
Protos
20.12.2022 09:50+1Насколько усложнен code review такого low-code, относительно обычного кода?
sshikov
20.12.2022 12:41+3Как правило, описанный подход сильно усложняет сравнение двух версий этого «не кода». Соответственно, как вы представляете себе code review, когда не понимаете, в чем состоят изменения? Сложно сказать насколько, но как по мне — усложнен. Вообще, все эти рисовалки картинок, возможно упрощая первоначальную разработку, очень часто забывают про то, что продукт должен еще и развиваться. Что нужно хранить историю, видеть изменения, иметь возможность прислать патч почтой (ну это я утрирую).
mianoki Автор
20.12.2022 21:33-1Суть визуальной разработки (LowCode) как раз в прозрачности изменений. А в любом стандартном крупном корпоративном продукте есть целые серверы, годами гоняющие неизвестные уже никому из текущих сотрудников компании куски legacy-кода.
MentalBlood
20.12.2022 11:01+1такой подход полностью избавляет от ошибок на уровне синтаксиса и механической работоспособности кода
Подавляющее большинство ошибок, возникающих в ПО — логические, и обнаруживаются только дотошным тестированием
mianoki Автор
20.12.2022 21:35-2Совершенно верно! Отчасти поэтому ultra-relieble код почти всегда пишется именно в визуальных средах - чтобы логические ошибки были точно идентифицируемы со всеми взаимосвязями.
tzlom
20.12.2022 21:58Вот я знаю MISRA C, это как раз для ultra-reliable, какие стандарты и практики существуют для не-код решений?
Minyah
20.12.2022 21:30+1Не думал что где-то встречу VisSim после универа. Занимался Low-Code до того как это стало мейнстримом: учился на специальности "Управление в технических системах" (ТАУ, САУ, АСУТП и прочие динозавры), в процессе обучения использовали эти две программы (включая SimuLink) для построения матмоделей систем и их исследвания, всякие передаточные функции, П- И- Д- звенья и их комбинации, ЛАЧХ, ЛФЧХ и т.д.
F123456
20.12.2022 21:31+2Вопрос не в отображении элементов, а в формализуемости языка. Допустим, Haskell позволяет доказать корректность программы не выполняя саму программу. Есть еще Рефал, и суперкомпиляция, созданные как раз для формальных доказательств корректности. Вообще, для моделирования систем лучше использовать что-то типа Maude System или Coq.
tzlom
20.12.2022 22:02+4Весь no-code это одна большая подмена понятий.То, что код "пишется" на xml в визуальным инструменте не означает что код куда-то пропал. Просто теперь он непривычный, слабее документированный и без средст работы с кодом наработанными за последние 30 лет. Делает ли это его автоматически лучше? Как по мне ответ не будет однозначным
comerc
22.12.2022 13:59-2Вот почему мой канал в Ютубчике называется #кодеротбога )) Сложность технологий нарастает по экспоненте. Применение абстракций - профит, очевидно.
tzlom
Проблема: программисты не умеют программировать. Решение: они больше не пишут код.
PS
Вы не правильно используете слово "помпезный", подходящим словом будет "желчный", или даже кальный.
vg7
Вы неправильно используете слово "неправильно" - это одно слово, пишется слитно.
mianoki Автор
Возможно, я не смог ясно донести свою мысль, но проблема совсем в другом: львиная доля современных задач либо практически не требует серьёзного программирования (и закрывается условно любым фрилансером), либо требует настолько жёсткого программирования, что отвлекаться на код становится недопустимо. Вот где проходит деление оптимальных методик.