Комментарии 14
Упрощение разработки
Это обещают со времён появления индустрии. Но пока сложность ни куда не девается, а лишь перераспределяется между вендорами пропорционально все время растущим бюджетам.
Соглашусь, что это скорей западные тренды. У нас более традиционный подход, даже если это не заказная разработка с "утилизацией" бюджетов, где проект не так важен как сумма, в других компаниях с собственной разработкой, очень не охотно переходят на что то новое, а средний срок работы систем (это только мой личный опыт, с кем то может не совпадать) 7+ лет с вытекающим устаревшим стеком и такими же людскими ресурсами к этому стеку, которым не нужен low-code и компания не готова вкладывать в изменение подхода.
Ну почему же, ведь и достижений много.
Удобные IDE, инфраструктуры готовых компонентов.
Зря что ли софт такими решительными темпами пухнет в размерах? (Конечно зря)
Другое дело, что это компенсируется таким же радикальным ростом потребностей и падением квалификации (в смысле больше людей)
Мечтать не вредно, конечно... Но текущее развитие событий в мире - делает куда более вероятным сценарий ядерной катастрофы, в которой если и выживет человечество, то будет отброшено в каменный век.
"Всё, что нельзя написать на ассемблере - можно спаять". Если не удастся раздобыть паяльник, канифольку и припой, то можно прибегнуть к лайфхакам дедов и виде замечательного способа монтажа в виде накруток. Опасность ядерной катастрофы сильно преувеличена, кто-то да выживет в любом случае. Плохо то, что навыки сборки простейших радиостанций давно утеряны по обеим сторонам океана, а интернет на лампах не работал отродясь
Опасность ядерной катастрофы сильно преувеличена, кто-то да выживет в любом случае.
Хахаха, прекрасная фраза, прекрасная логика. Уверен, что автор давно в окопах, потому что опасность гибели от взрыва ракеты сильно преувеличена, что-то да останется в любом случае (от человека).
Сколько лет про эту ядерную катастрофу говорят, уже смысл фразы давно потерян.
Общие компоненты будут составлять до 90% программного кода систем.
Чтобы это работало, нужно и код писать понятно.
Простой пример: мне нужно сделать исключение файлов по маске в .gitignore
Самый очевидный ход - полезть в исходники git и взять код оттуда. Вот только вытащить его оттуда - задача весьма непростая. Потому что он там "прибит гвоздями" к другому коду. Начал писать свою функцию и уже тоже начинаю замечать что тоже прибиваю функцию к своему коду. Т.е. в этой функции я использую другие свои наработки, те, в свою очередь, треть мои наработки и т.д. И получается что при вставки одного класса нужно вставлять ещё кучу другого кода.
И так практически при вставке любого алгоритма сложнее сортировки массива. Также вылезает проблема та же что и для NPM, когда ставится зависимость чтобы использовать одну функцию этого пакета. А в этом пакете ещё куча зависимостей и в результате в код попадает целая куча кода.
С другой стороны - будущее уже с нами. Посмотрите на объём кода в npm-модулях проекта, возможно, уже будет больше 90%. Это мы саму ноду, V8 и ОС еще не посчитали :) Общие компоненты обычной "бизнес-разработки" давно составляют 99+%, даже не понимаю смысл их считать, всё равно оставшегося огрызка хватает, чтобы был дефицит тех, кто пишет прикладную часть. Вон, у тех же data-scientists, убрали под капот миллионы строк кода и значительную часть сложности, оставив какой-нибудь простой Python снаружи. Теперь нужны data-scientists (и смежные специалисты).
Остальные пункты, впрочем, тоже напоминают перья совы на глобусе.
минимизация времени разработки (то есть скорость важнее, чем качество)Это конец.
решение проблем по мере возникновения потребности (solving for need)
постоянные изменения (excelling at change)
Внедрение ИИ, автоматизация разработки
Упрощение разработки
Верно и всегда так будет потому что быстро поумнеть, т.е. усложниться невозможно.
Возможно, я что-то пропустил, но это тренд последние лет 10.
Подождём, когда винду напишут на no-code
Перспективы IT — разный взгляд на будущие тренды