Лучше писать меньше кода, чем больше
Во всём свои грани и нюансы, но когда-то я часто встречал мнение типа: "Современная разработка слишком простая и скучная, так как все перестали писать решения и просто пользуются библиотеками. Вот когда всё нужно было писать мы разы больше разбирались в программировании". И это отчасти правда, но тут я бы чуть-чуть сместил акценты.
Да, разработка развивается, прогрессирует и меняется. Любое развитие технологий ведёт к их демократизации, так как они начинают обрастать базой для обучения и инструментами. Ошибками ответ на который можно нагуглить и т.п. И сейчас разработка в своей массе — интеграционная. На первый план выходят архитектура и интеграции. Но это не значит, что она стала проще. На самом деле она стала в разы сложнее чем раньше. Потому что проекты стали крупнее, сложнее и думать нужно про больше вещей. Мелочи конечно интегрировать целой либой — это извращение :) Но разработка стала сложнее и другой и вот почему.
Для небольших проектов это конечно неправда, а вот для крупных, чтобы такой вести эффективно, ты должен знать прям очень много. В моей практике очень много проектов где приходилось писать нативные плагины (и соответственно на определённом уровне знать языки вообще других платформ) Иногда приходилось что-то портировать с одного языка на другой и нельзя было просто использовать либы. Но возьмём даже простую интеграцию. Она всегда обладает одной и той же проблемой. Библиотеки бывают:
1. Плохо документированы — и чтобы пользоваться библиотекой ты должен думать как библиотека. По сути понять идеологию по которой разрабы писали либу + спокойно читать чужие исходники, чтобы понимать "что не так". Так как в документации написано одно, а по исходникам всё совсем по-другому. Да и в целом можно разобраться
2. В них есть баги — и когда это критический баг, а либа решает очень много, нужно придумать воркэраунд. А для этого опять таки мы лезем в исходники либы и смотрим: "писать свой форк" — для опенсорсных, "придумать как обойти" — для закрытых либ, но декомпилируемых. Допустим вот в том же ARFoundation. Казалось бы готовая либа для AR, но у меня есть несколько расширений для неё так как: события на Android и IOS работают по разному и для этого нужен обработчик; в них есть часть багов для которых нужны воркэраунды; они немного по разному работают в разных условиях. Поэтому сделать большое AR приложение — это не просто интегрировать ARFoundation по туториалам и радоваться жизни, там есть огромное количество контекста, которые я продолжаю узнавать. Типа нюансов и проблем динамической подгрузке AR маркеров из облака. (Что такое AR маркер можно тут почитать)
3. Дружить библиотеки с друг другом — нетривиальная архитектурная задача. У каждой библиотеки свой контекст, своя идеология, свои баги, своя частота обновлений. И в рамках проекта интегрировать множество библиотек — уметь надо)
Так что я не считаю, что разработка стала проще. Порог входа стал ниже — да, типовые задачи упростились — да, стало работать в целом комфортнее — да. Но на высоком уровне она стала не проще, а просто другой. Раньше ты написал какой-то сложный алгоритм, и ты молодец. Твоя программа выполняет свою функцию. Максимум подружил с парой CLI утилит или типа того. Сейчас же любой программный продукт — это монстр из кучи зависимостей, которыми надо уметь грамотно жонглировать