Что нас ждёт в будущем? Куда мы движемся, и насколько светлое это будет время? Такие вопросы актуальны в любой момент развития человеческой цивилизации, в том числе и сейчас. Хотя люди больше хотят верить хорошим прогнозам, чем плохим, но важно смоделировать все варианты.
В недавней редакционной статье технологический совет журнала Forbes обсудил несколько технологий и трендов, которые могут сильно повлиять на индустрию разработки ПО в ближайшие годы.
Некоторые прогнозы кажутся логичными, но есть и спорные.
Попробуем расположить 15 тезисов технологического совета Forbes по уровню реалистичности: от более очевидных (в начале) до спорных (в конце)
-
Дистанционная работа. Сотрудничество в онлайне коллективов, разбросанных по странам и континентам — это уже даже не прогноз, а местами самая настоящая реальность. Как говорили классики, будущее уже здесь, просто оно ещё недостаточно распространилось. Этот прогноз кажется весьма вероятным.
-
Новые, лучшие инструменты для совместной разработки. В качестве «вестников будущего» называют Live Share (Visual Studio Code) и Copilot (GitHub).
Live Share
-
Углубление и расширение знаний разработчика. Кроме основной квалификации, придётся разбираться во множестве других вещей (горизонтальные знания), а также ещё сильнее углубляться в свою специфику (вертикальные знания), что образует Т-образную структуру знаний. Наверное, это очевидный и естественный путь развития любого специалиста в любой отрасли, не только в программной инженерии.
-
Общие компоненты будут составлять до 90% программного кода систем. Сбор более шаблонных решений из конструктора (фреймворков) и открытого кода.
-
Разбиение проектов на подзадачи для делегирования разным командам. Предполагается, что такой «многопоточный» децентрализованный процесс 24/7 ускорит разработку.
-
Проблемы с безопасностью из-за децентрализованной разработки, увеличения количества участников и снижения средней квалификации участников. Поскольку в процессе участвует всё больше людей, то средний уровень участника естественным образом снижается.
-
Усиление требований к безопасности облачных решений и онлайновых инструментов. Увеличение спроса на DevSecOps (пункты 3 и 9 в оригинальном списке).
-
Фокус на долговременные задачи. Список главных проблем в безопасности веб-приложений OWASP Top Ten практически не изменился за последнее десятилетие. Это по сути одни и те же базовые проблемы.
Кроме мониторинга новых уязвимостей, руководителям рекомендуется обратить больше внимание на долговременные задачи, такие как внедрение стойкой криптографии.
-
Распространение «продуктового» мышления вместо предпочтения процессу разработки. По мнению экспертов Forbes, есть три признака «продуктового» мышления:
- минимизация времени разработки (то есть скорость важнее, чем качество),
- решение проблем по мере возникновения потребности (solving for need);
- постоянные изменения (excelling at change).
- минимизация времени разработки (то есть скорость важнее, чем качество),
-
Внедрение ИИ, автоматизация разработки. Этот прогноз справедлив, если сюда относить инструменты автодополнения и генерации кода вроде Copilot.
-
Упрощение разработки (пункты 1, 7, 10 и 12 в оригинальном списке). Всё больше компаний начнут использовать решения no-code/low-code. В процесс создания программных решений вовлекаются граждане, не имеющие профессиональной квалификации (citizen-based development).
Вот уже много лет специалисты говорят, что разработка программного обеспечения должна стать проще и доступнее для широких слоёв населения. Но несмотря на весь прогресс в этой области, обучение программной инженерии и освоение инструментария по-прежнему остаётся уделом избранных. Хотя многие эксперты говорят о распространении no-code/low-code инструментов, но нам сложно представить, что когда-нибудь в будущем профессия инженера-программиста перестанет быть элитной. Мы видим скорее обратный процесс: спрос на высококачественных профессионалов только растёт с каждым годом, как и их зарплаты.
Нужно заметить, что коммодитизация/упрощение разработки, продуктовое мышление, внедрение инструментов no-code/low-code — довольно общее место в прогнозах технологического совета Forbes. Но история показывает, что не все «желания» представителей индустрии возможно реализовать на практике. Зачастую будущее принимает иную форму, чем представлялось человечеству в прошлые десятилетия.
Комментарии (12)
rqdkmndh
16.10.2022 22:46+1Мечтать не вредно, конечно... Но текущее развитие событий в мире - делает куда более вероятным сценарий ядерной катастрофы, в которой если и выживет человечество, то будет отброшено в каменный век.
redneko
17.10.2022 00:36+2"Всё, что нельзя написать на ассемблере - можно спаять". Если не удастся раздобыть паяльник, канифольку и припой, то можно прибегнуть к лайфхакам дедов и виде замечательного способа монтажа в виде накруток. Опасность ядерной катастрофы сильно преувеличена, кто-то да выживет в любом случае. Плохо то, что навыки сборки простейших радиостанций давно утеряны по обеим сторонам океана, а интернет на лампах не работал отродясь
dyadyaSerezha
17.10.2022 00:46Опасность ядерной катастрофы сильно преувеличена, кто-то да выживет в любом случае.
Хахаха, прекрасная фраза, прекрасная логика. Уверен, что автор давно в окопах, потому что опасность гибели от взрыва ракеты сильно преувеличена, что-то да останется в любом случае (от человека).
hard2018
17.10.2022 02:08Сколько лет про эту ядерную катастрофу говорят, уже смысл фразы давно потерян.
shasoftX
17.10.2022 06:21Общие компоненты будут составлять до 90% программного кода систем.
Чтобы это работало, нужно и код писать понятно.
Простой пример: мне нужно сделать исключение файлов по маске в .gitignore
Самый очевидный ход - полезть в исходники git и взять код оттуда. Вот только вытащить его оттуда - задача весьма непростая. Потому что он там "прибит гвоздями" к другому коду. Начал писать свою функцию и уже тоже начинаю замечать что тоже прибиваю функцию к своему коду. Т.е. в этой функции я использую другие свои наработки, те, в свою очередь, треть мои наработки и т.д. И получается что при вставки одного класса нужно вставлять ещё кучу другого кода.
И так практически при вставке любого алгоритма сложнее сортировки массива. Также вылезает проблема та же что и для NPM, когда ставится зависимость чтобы использовать одну функцию этого пакета. А в этом пакете ещё куча зависимостей и в результате в код попадает целая куча кода.
speshuric
17.10.2022 07:57+2С другой стороны - будущее уже с нами. Посмотрите на объём кода в npm-модулях проекта, возможно, уже будет больше 90%. Это мы саму ноду, V8 и ОС еще не посчитали :) Общие компоненты обычной "бизнес-разработки" давно составляют 99+%, даже не понимаю смысл их считать, всё равно оставшегося огрызка хватает, чтобы был дефицит тех, кто пишет прикладную часть. Вон, у тех же data-scientists, убрали под капот миллионы строк кода и значительную часть сложности, оставив какой-нибудь простой Python снаружи. Теперь нужны data-scientists (и смежные специалисты).
Остальные пункты, впрочем, тоже напоминают перья совы на глобусе.
Mike-M
17.10.2022 13:08+1минимизация времени разработки (то есть скорость важнее, чем качество)
Это конец.
решение проблем по мере возникновения потребности (solving for need)
постоянные изменения (excelling at change)
Внедрение ИИ, автоматизация разработки
Упрощение разработки
anonym0use
17.10.2022 20:13> Мы видим скорее обратный процесс: спрос на высококачественных профессионалов только растёт с каждым годом, как и их зарплаты.
Верно и всегда так будет потому что быстро поумнеть, т.е. усложниться невозможно.
funca
Это обещают со времён появления индустрии. Но пока сложность ни куда не девается, а лишь перераспределяется между вендорами пропорционально все время растущим бюджетам.
RWizard
Соглашусь, что это скорей западные тренды. У нас более традиционный подход, даже если это не заказная разработка с "утилизацией" бюджетов, где проект не так важен как сумма, в других компаниях с собственной разработкой, очень не охотно переходят на что то новое, а средний срок работы систем (это только мой личный опыт, с кем то может не совпадать) 7+ лет с вытекающим устаревшим стеком и такими же людскими ресурсами к этому стеку, которым не нужен low-code и компания не готова вкладывать в изменение подхода.
SadOcean
Ну почему же, ведь и достижений много.
Удобные IDE, инфраструктуры готовых компонентов.
Зря что ли софт такими решительными темпами пухнет в размерах? (Конечно зря)
Другое дело, что это компенсируется таким же радикальным ростом потребностей и падением квалификации (в смысле больше людей)