Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 29
Уже давно пишу код только для своих пет-проектов, больше нет необходимости соответствовать требованиям отрасли. Никакого спринга, чистые сервлеты, чистый jdbc, никаких миграций - всё ручками прямо в БД, никаких докеров/куберов - гружу руками варники в Томкат... Просто кайфую, что не трачу кучу времени на всякое говно, могу сконцентрироваться на бизнес-логике. Благодаря ИИ, теперь ещё и фронт можно спокойно писать на чистом JS.
спокойно писать на чистом JS.
Осторожнее только с чистым JS. Что бы по скорости написания фронт не отставал от бэка, его тоже правильно писать надо, модулями и архитектуру продумывать не меньше чем на бэке.
Даже 2 модуля как на скриншоте, становятся очень плохо поддерживаемыми, если просто попросить ИИ что то сделать. А нормально приложение таких модулей содержит 20-80 штук
Индустрия развивается, меняется и адаптируется. А автор — нет.
Привет, Дед. Спасибо что живой.
В этом плаче Ярославны очень не хватает примеров кода: мол, вот 20 (15 или даже 10) лет назад было вот так, а сейчас вот так и посмотрите какая разительная разница.
вот пример к чему я пришел в пет проекте, всё в своих структурках и компактно, в проекте я пошел дальше и теперь всё в модулях в своих структурах структуры есть уже иерархические, вроде это не ООП, помойму что ООП что структурно-функциональный подход в своей екзальтации сложны, вулкан на структурах например
Подставляю свой фреймворк (.net) и радуюсь что статья не про меня. У него есть конечно некоторые шероховатости, но он развивается и с каждым годом становится лучше. Да мне нравится мой фреймворк и мне нравится как он развивается.
Единственный минус - куча windows-only функций и тп. Даже там, где казалось бы на других платформах есть идентичные или хотя-бы похожие методы
EF например, с несколькими джойнами, группировками, оконными функциями и пейджингом.
Начинал промышленную разрбаотку как раз с .NET, а сейчас на TS пишу. Как же было приятно иметь дело с LINQ, где с любой коллекцией единообразная работа. А то в JS реально, как автор пишет, есть .length, есть .size , есть, не дай бог, еще Object.values({ /* ... */ }).length. А чтобы сумму по массиву посчитать приходиться городить reduce каждый раз... Ну либо lodash тащить...
Лучше иметь несколько структур данных и несколько сотен постоянных функций над ними. Постоянных - т.е. они не будут меняться из класса в класс, из объекта в объект. Нужно только разобраться один раз.
И получаем 100500 функций * на 100500 объектов, и весёленький интелесенс. Может всё таки проблема не в ооп а в ручках?
Зачем нужны объекты тогда?
Несколько структур данных и функции, которые только с ними работают.
В смысле зачем? Если делать по нормальному а не фигачить по 100500 методов то всё будет в порядке, а так говнокодить можно в любой парадигме и не любом языке
Это замечательно когда проект небольшой, например микро сервис какой-нибудь, а когда проект становится здоровым, добавляется вариация с плагинами у кучей всего остального. Критичными становятся грамотно построенные интерфейсы, и ооп тут помогает несколько больше нежели функциональное программирование.
Ну и в конце концов, зачем обязательно упираться во что-то одно, можно ведь смешивать подходы, там где это выгодно. Бери плюсы из обоих миров.
Идея функционального подхода как раз в том, чтобы иметь минимальное количество структур (желательно пересчитываемых пальцами одной руки) и много стандартных функций работы с ними. Тогда предотвращается комбинационный взрыв за счет композиции стандартных функций.
А ООП, которое предотвращает комбинационный взрыв, существенно отличается от текущего мейнстрима в ООП. Есть интересные проекты на эту тему - но тут надо целую статью писать. Понятие объекта там совсем другое.
Грамотно построенные интерфейсы/контракты - это разве требование только ООП?
Что касается вариации с плагинами и кучей всего остального - вот как раз куч хотелось бы избежать. Будем считать, что у нас разный опыт и каждый остался при своем мнении.
Автору очень рекомендую перейти в Си-программисты. Да именно Си - который без плюсов, ибо в плюсах начинается полный АД. Для контроллеров или для ядра пишут так. Просто и выверено. И такие специалисты востребованы сейчас. Ну про безумие библиотек и подходов - тут тоже прав. Всегда на проекте может появится крутой перец - который попытается докинуть своих фитч. Он то их знает. Как с такими во времена тотальной демократии бороться, я просто не знаю.
философски автора понять можно, нужна стабильность, выверенный код, типо зачем математику обновлять, написал 1 раз и всё, а вот в библиотеке Х постоянные обновления.
это тоже Ахилесов вопрос - потомучто реализовывая свой велосипед дойдя до реализации, обязательно что-то да изменится)
заметьте Линукс ядро тоже не стоит на месте, да есть код, который не трогают, но там постоянно происходит шлифовка, и получается стабильность от релиза к релизу
эти оба подхода по всей видимости это просто 2 взгляда на задачу
В сях сейчас тоже много приколов. Раньше, чтобы мигнуть светодиодиком, пишешь в регистр порта ноль, потом единичку и все работает. А сейчас надо вызывать одну функцию из другой функции, у которой в параметре - непонятные макросы. И с библиотеками тоже беда. Одну подключаешь - не работает, другую подключаешь - не работает, подключаешь третью - о, заработало! Вместо этих танцев вокруг библиотек я бы быстрее сам написал свою функцию, но вот беда, с некоторыми ядрами можно работать только через библиотеки.
Читаю комментарии, и думаю: а зачем, собственно, выбирать? Комбинируйте ФП и ООП. Вот вам и золотая середина
А насчёт темы статьи полностью согласен. Причём не в масштабах фреймворков, а в масштабе всех ЯП. Я очень надеюсь, что в мире программирования будет больше стандартизации. Это банально удобнее и более предсказуемо. Кроме того, любимый многими генеративный ИИ будет писать код чище и с меньшим количеством галлюцинаций
Толи дело в 1с!
Старые версии библиотек в большинстве случаев не удаляют. Хочешь как раньше, загрузи и мучайся. Хочешь быть на волне, адаптируйся, развивайся. Никакого тупика нет, разве что в голове.
Самая большая проблема в слоеной архитектуре. Когда код написан в стиле
func do_something_useful()
// что-то делаем
do_something_useful_next()
// что-то делаемИ так 20 раз тонкой нитью проходит через весь проект, через несколько репозиториев. Очень тяжело разбираться с таким кодом, писать и отлаживать.
Но пока версии инструментов, либ и фреймворков обновляются - бизнесу приходится переходить под новые версии для упрощения написания и ввода новой функциональности, если такие подразумеваются в новых версиях.
В любом случае, мне кажется что тенденция рынка меняется не быстро, а меняется после тотальных обзоров той или иной технологии, когда ввели функциональное программирование для одной области востребовано, то в другой отрасле/компании или бизнес-проекте, до него не дошли или вовсе не слышали.
Думаю, вопрос актуален только для того - куда вы метите.
Мальчик, ударившись об скамейку винит в этом скамейку. Мальчик-программист, ударившись об говнокод, или просто сгорев, винит в этом дьявольский ООП, фреймворки, куча кода понаписано всякого сложного. Всё это тяжело, мальчику больно. ООП виноват. Плохой ООП. ФП вот хороший, он простой, однобитный, думать вообще не надо. А злые люди понаписали всяких фреймворков, невозможно просто так жить. Уйду вот на ванильные функциональные языки, не нужны мне никакие библиотеки и фреймворки, и программы у меня будет не больше чем из 2-3 функций. Понятно?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тупик