Хороший заход про сложность работы программиста, даже собственный неструктурированный код, или код структуру которого ты писал но забыл достаточно сложно собрать в кучу в своей голове. Думаю от возможности расскрутить знания в книге с "собачка делает гав, кошка делает мяу" до "я хочу иметь возможность отправлять сообщения не только в существующие мессенджеры но и которые появятся потом" зависит сможет ли узрить суть программист того что он читает и как эффективно он будет это применять.
Гид по Computer Science не очень подробная, но хорошо отражает тематику книг по фундаментальным подходам в информатике. Дает начальные знания этой глубокой, большой и сложной науки. Как по мне самое то для первого погружения и минимального представления.
Не знаю про одно ли ООП мы говорим, в тексте почему-то имеется ввиду что книги по Computer Science содержат паттерны. Но книги про фундаментальные технологии в информатике больше про графы, устройство памяти и подобное, но не как не про паттерны
Борьба функциональных программистов (по моим ощущениям это те кто считают что программа и так может выдать нужный результат, зачем все эти заморочки в виде паттернов?) против адептов ООП (надеюсь здесь есть такие) в самом разгаре. Но почему надо говорить что с ООП что-то не так? Любая книга с архитектурными паттернами содержит плюс минус одни и те же решения, о чем это может говорить? Я думаю что это некие бест практис так сказать, и применить их или нет, в каком виде и количестве выбор только программиста. Вот и складывается ощущения что ООП даёт очень мощный инструмент для программиста, а программист его боится.
Вчера читал про падение StackOverflow. Там говорят что наоборот AI порождает некачественных программистов, которые распространяют код нейросети по сети интернет, на котором потом учатся нейросети (в итоге получаем что нейросети учатся сами на себе) что ведёт нас в достаточно неопределенную ситуацию
Потребность можно не только удовлетворять, но и создавать. Про активацию мне показалось спорно, может из-за примера, но могу себе представить как человек что-то продаёт через площадку в интернете и больше ею не пользуется.
С помощью объектов и контроля за ними можете гарантировать что любая функция в коде не изменит данных.
Все ООПшные прелести не завязаны на интерфейсе, само наличие интерфейсов и фабрик не делает по определению архитектуру качественной. Можно написать и плохую фабрику.
Чем плох интерфейс? Если вам не надо расширять, можно и без интерфейса обойтись
Вы говорите что "чистая архитектура" должна быть общим решением, и не все её потянут, получается чем больше разработчиков, тем "грязнее архитектура"? И как тогда нанимать людей, если такая архитектура была принята до них?
Ну и если честно распределенный монолит первый раз слышу (если говорить об общепринятом), если мы в микросервис начнём монолитить, это тоже будет распределенный монолит?
Если относится к классам как микросервисам и построить взаимодействие через шину данных (gRPC) это не будет микросервисом, ведь так? Мне кажется что микросервис это про вывод задачи и зависимостей которые помогают её реализовать в отдельный докер контейнер например. Что именно ложить в микросервис и для чего уже отдельный вопрос.
Вы хотите сказать что микросервис это панацея и верх архитектурного искусства в программировании? Я лично видел как в большой продуктовой компании фронт ходил на 30+ микросервисов и потом собирал все это в одну кучу. Разбираться в этом было то ещё удовольствие
Например если это внутренний проект компании где нужно свести использование библиотек к 0, и не зависеть от composer
Хороший заход про сложность работы программиста, даже собственный неструктурированный код, или код структуру которого ты писал но забыл достаточно сложно собрать в кучу в своей голове. Думаю от возможности расскрутить знания в книге с "собачка делает гав, кошка делает мяу" до "я хочу иметь возможность отправлять сообщения не только в существующие мессенджеры но и которые появятся потом" зависит сможет ли узрить суть программист того что он читает и как эффективно он будет это применять.
Помоему для этого созданы AMQP-брокеры
Вы можете отслеживать подключение с помощью наблюдателя
Гид по Computer Science не очень подробная, но хорошо отражает тематику книг по фундаментальным подходам в информатике. Дает начальные знания этой глубокой, большой и сложной науки. Как по мне самое то для первого погружения и минимального представления.
Не знаю про одно ли ООП мы говорим, в тексте почему-то имеется ввиду что книги по Computer Science содержат паттерны. Но книги про фундаментальные технологии в информатике больше про графы, устройство памяти и подобное, но не как не про паттерны
Борьба функциональных программистов (по моим ощущениям это те кто считают что программа и так может выдать нужный результат, зачем все эти заморочки в виде паттернов?) против адептов ООП (надеюсь здесь есть такие) в самом разгаре. Но почему надо говорить что с ООП что-то не так? Любая книга с архитектурными паттернами содержит плюс минус одни и те же решения, о чем это может говорить? Я думаю что это некие бест практис так сказать, и применить их или нет, в каком виде и количестве выбор только программиста. Вот и складывается ощущения что ООП даёт очень мощный инструмент для программиста, а программист его боится.
Вчера читал про падение StackOverflow. Там говорят что наоборот AI порождает некачественных программистов, которые распространяют код нейросети по сети интернет, на котором потом учатся нейросети (в итоге получаем что нейросети учатся сами на себе) что ведёт нас в достаточно неопределенную ситуацию
Ваше описание Open closed Principle больше напоминает паттерн "мост"
Я говорю с точки зрения бизнеса, вся активация это регистрация на площадке и продажа.
На больших площадках люди бизнес строят, как контролировать туже активацию если ты не можешь непосредственно влиять на этот процесс?
Потребность можно не только удовлетворять, но и создавать. Про активацию мне показалось спорно, может из-за примера, но могу себе представить как человек что-то продаёт через площадку в интернете и больше ею не пользуется.
С помощью объектов и контроля за ними можете гарантировать что любая функция в коде не изменит данных.
Все ООПшные прелести не завязаны на интерфейсе, само наличие интерфейсов и фабрик не делает по определению архитектуру качественной. Можно написать и плохую фабрику.
Чем плох интерфейс? Если вам не надо расширять, можно и без интерфейса обойтись
Хорошо сказано
Да кстати, Django это же фреймворк питона...
Вы говорите что "чистая архитектура" должна быть общим решением, и не все её потянут, получается чем больше разработчиков, тем "грязнее архитектура"? И как тогда нанимать людей, если такая архитектура была принята до них?
Ну и если честно распределенный монолит первый раз слышу (если говорить об общепринятом), если мы в микросервис начнём монолитить, это тоже будет распределенный монолит?
В статье я и задаю вопросы чтобы порассуждать на общепринятые термины
Если относится к классам как микросервисам и построить взаимодействие через шину данных (gRPC) это не будет микросервисом, ведь так? Мне кажется что микросервис это про вывод задачи и зависимостей которые помогают её реализовать в отдельный докер контейнер например. Что именно ложить в микросервис и для чего уже отдельный вопрос.
Вы хотите сказать что микросервис это панацея и верх архитектурного искусства в программировании? Я лично видел как в большой продуктовой компании фронт ходил на 30+ микросервисов и потом собирал все это в одну кучу. Разбираться в этом было то ещё удовольствие