The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Попытки получения контроля над открытыми проектами, похожие на случай с пакетом xz, opennews (?), 17-Апр-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


35. "Попытки получения контроля над открытыми проектами, похожие ..."  +1 +/
Сообщение от Golangdev (?), 17-Апр-24, 13:01 
Согласен со всем, кроме тезиса про ООП. Как правило он не мешает, позволяя создать нужные разработчику иерархии классов. (Опять же, какое ООП. То что в Java - не совсем ООП =) ) Опять же, если человек дебил, ему любую технологию дай, он везде умудрится всё испортить и сделать через задницу.
Ответить | Правка | Наверх | Cообщить модератору

70. "Попытки получения контроля над открытыми проектами, похожие ..."  +2 +/
Сообщение от Аноним (-), 17-Апр-24, 14:28 
По моему опыту, чем умнее человек, и чем глубже он вник в ООП, тем больше он занят не тем, чтобы решать проблемы при помощи ООП, а чтобы городить ООП на ООП при помощи ООП, для того чтобы ООП ООП ООП ООП. Любой инструмент нужен для решения каких-то проблем, но ООП решает несуществующие проблемы (которые, может быть возникнут в будущем, но могут и не возникнуть) и таким образом создаёт проблемы уже сейчас.

Мне кажется, что единственный способ с этим бороться -- вычитать из зарплаты программиста за каждое использование наследования. Вот тогда он начнёт думать, когда наследование упрощает ему жизнь, а когда это условный рефлекс, наследую потому что могу наследовать.

Ответить | Правка | Наверх | Cообщить модератору

77. "Попытки получения контроля над открытыми проектами, похожие ..."  +1 +/
Сообщение от Golangdev (?), 17-Апр-24, 15:08 
Длительное время, пока работал на Java - не встречался прямо с сильными проблемами из-за кривого использования ООП.

Знакомо. В тоже время пимерно такие же симптомы видел - как практически всё пытались решить с помощью CQRS, в то время когда он реально нужен в процентах 5 случаев.
Там прямо мания была - все как хомяки копировали говнокод с medium.com, и дружно прыгали вокруг свеже образовавшемуся техдолгу. В 100% случаев техдолг не решался во время жизненного цикла продукта, а копился и стрелял плавающими багами.

Как правило - удалял CQRS и всё становилось лучше.

Опять же, я не говорю что он(CQRS) не нужен никогда(можно посмотреть на решение задачки про Твиттер из собеседований). Он не нужен в 95% случаев. Как и пожалуй и ООП.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру