Объектно-ориентированное программирование — оно про объекты, которые владеют собственными данными, а не предоставляют их для обработки другому коду.
Интересно, автор оригинала это сам придумал или ему кто-то подсказал. Инкапсуляция — это только часть ООП, а не все ООП. Хотелось бы узнать ответы автора оригинала на пару вопросов. Есть Клиент, есть Заказ и есть бизнес функция Рассчитать скидку.
Вопрос 1: куда поместить логику расчета скидки?
1. В класс клиента.
2. В класс заказа.
3. В отдельный сервис.
Вопрос 2. Кто в итоге будет «владеть» всем набором данных?
1. Класс клиента.
2. Класс заказа.
3. Сервис.
4. Никто.
В целом я бы переформулировал: если для выполнения некой логики достаточно знать состояние одной сущности, лучше поместить эту логику непосредственно в объект этой сущности.
Но предложенный в дальнейшем пример рефакторинга вполне годный.
Однако это не основное значение слова «польза». Кроме того два этих слова имеют абсолютно разный эмоциональный окрас. Именно поэтому когда пытаются манипулировать, то говорят о некой абстрактной пользе. А вот когда хотят реально вовлечь, говорят о конкретной выгоде.
Но ваш текст подразумевает, что «все так делают»
У меня есть только личный опыт, я не могу обобщать на всех. Могу даже допустить, что есть такие работодатели, которые не используют этот прием для манипулирования сотрудниками.
В случае, если это всегда манипуляция получается: «Нельзя знакомить бизнес и разработчиков»
Да почему же, знакомьте на здоровье, только не в стиле розовых пони и давайте все обнимемся и дружно зашагаем в светлое будущее. Знакомьте разработчиков с процессами, на которых построен бизнес, показывайте разработчикам как ваше приложение позволяет решать реальные задачи бизнеса, например, ускоряет документооборот, повышает скорость принятия решений. Привлекайте разработчика к анализу и оптимизации этих процессов. Дайте ему в конце концов посмотреть на ваше ПО с точки зрения пользователя, чтоб он увидел что его отрефакторенный поиск, который подгружает значения на 20% быстрее, проблемы пользователя не решает, потому что ему надо ручками заполнить 20 полей. А вот функция автозаполнения связанных данных, на которую он забил ради рефакторинга, позволила бы заполнять 3 поля вместо 20.
Сигареты, алкоголь, наркотики, уничтожения излишков товаров для сохранения цены, реклама всяких «фуфломицинов», уничтожение промышленных линий, ради быстрого заработка на распродаже «металлолома» и сдачи в аренду торговых площадей — это все приносит деньги. Какую пользу это приносит кому-либо кроме владельца бизнеса?
Мне кажется, можно найти гораздо более грамотные способы снижать ставку разработчику
Зачем, если этот работает и не требует практически никаких усилий? Рассказал разработчику о важности миссии компании, пригласил на совещание о следующем этапе внедрения продукта, чтоб он молча постоял в сторонке, глядишь и человек уже считает себя не просто наемным сотрудником, а частью команды. А как же можно подвести команду, потребовав прибавки или вообще уйдя с проекта — это же не справедливо по отношению к остальным участникам команды? Затрат ноль, а на некоторых все еще действует. Вот когда это перестает действовать, тогда уже идут в ход разные грейды, которые еще обосновывать надо, актуализировать, если разработчик внезапно решил прокачать скилы, силы свои тратить, время.
Не надо держать разработчика за идиота, не надо ему рассказывать о громадной пользе производимого продукта. Разговаривайте с ним как с взрослым человеком, если он реально взрослый. Объясняйте почему вот все переписать на RUST мы не можем, у нас на это нет бюджета, нам за это никто не заплатит. Но вот если ты предложишь план постепенного улучшения продукта, мы включим его в общий план разработки перемежая с фичами, необходимыми бизнесу. А уж коли включили, то не говорить: ну ты же понимаешь что у нас сейчас сроки горят, вот давай все разгребем, а потом вернемся к твоему плану.
Заработать денег. Принесет это кому-то пользу, кроме владельцев бизнеса — ну замечательно. Принесет это кому-то вред — ну бывает, мир не совершенен. Главное чтоб деньги у владельца бизнеса появлялись.
Соответственно, его мотивация
Заработать денег, точно такая же как и у владельца бизнеса. А еще у него мотивация снизить издержки процесса зарабатывания денег, если это конечно хороший специалист. Соответственно его желание переписать вот этот вот кусок коричневой субстанции обусловлено, не отсутствием понимания целей бизнеса, а пониманием что сейчас мы тратим на внедрение любой новой функции 40 часов и потом еще 80 на исправление багов, а могли бы тратить 20 часов на внедрение фич и 20 часов на исправление тех немногих багов, которые в любом случае будут появляться. Но для этого надо потратить 200 часов на рефакторинг. Но рефакторинг не приносит денег бизнесу.
А вот эти вот рассказы о том какую пользу приносит человечеству разработчик от того что решает проблемы вот этого вот бизнеса, они нужны ровно для одного — платить меньше разработчику, чтоб у владельца бизнеса оставалось больше денег.
В том то и дело, что некий маркер в виде «клея», еще и купленный отдельно от предмета, на который он нанесен, не является признаком того, что предмет кому-либо принадлежит. Т.е. этот клей абсолютно бесполезен, компания просто зарабатывает деньги из воздуха.
Компании вроде британской Alpha Dot продают маленькие флаконы с перманентным клеем, который заполнен миниатюрными шариками диаметром 1 мм с номером PIN. Если полиция найдёт какой-то украденный предмет, то этот PIN теоретически доказывает ваше право собственности.
Прошелся по офису, перемазал понравившиеся телефоны/планшеты/ноутбуки «клеем», накатал заяву в полицию. Как-то не сильно радужно получается.
И в том же вашем комментарии рекомендация минздрава о применении гидроксихлорохина, про который известно, что нет ни теоретического механизма защиты против COVID-19, ни значимых практических результатов клинического применения для лечения, в смысле положительных результатов, отрицательные в виде смерти пациентов как раз есть. Т.е. источник на который вы ссылаетесь не заслуживает доверия.
И опять же как неоднократно намекают в комментариях: все приведенное в статье — это максимум некие гипотезы, которые требуют тщательной проверки, в первую очередь медицинскими специалистами. При этом заголовок статьи содержит такое броское заявление как «Факты доказанные наукой». Это не факты.
Побочные действия вещества Гидроксихлорохин
…
Со стороны сердечно-сосудистой системы и крови (кроветворение, гемостаз): кардиомиопатия, AV-блокада, уменьшение сократимости миокарда, гипертрофия миокарда, апластическая анемия, нейтропения, агранулоцитоз, лейкопения, тромбоцитопения, гемолитическая анемия (у пациентов с дефицитом глюкозо-6-фосфатдегидрогеназы); при длительном применении в высоких дозах — миокардиодистрофия.
Другой вопрос что для тех кому его реально надо применять польза больше риска осложнений. При COVID-19 пользы от его приема нет, остаются только побочки.
Анализ литературных данных по клиническому опыту ведения
пациентов с атипичной пневмонией, связанной с коронавирусами SARSCoV и MERSCoV, позволяет выделить несколько этиотропных препаратов,
которые рекомендовано использовать в комбинации. К ним относятся
хлорохин, гидроксихлорохин, лопинавир+ритонавир, азитромицин (в
комбинации с гидроксилорохином), препараты интерферонов.
Да, сейчас гидроксихлорохин есть в рекомендациях и врачи вынуждены его раздавать и рекомендовать, в том числе амбулаторно. Но доказанной эффективности у него нет. И если в стационаре человека с фибрилляцией желудочков спасти можно, то дома вы ничего сделать не сможете. Поэтому применение гидроксихлорохина дома – это огромный, огромный вопрос. Подавляющее большинство стран его не применяют. Его рекомендуют только в нескольких, в основном в США, во Франции и в России.
Так что не надо слепо переписывать рекомендации минздрава.
Хоспади, да сколько уже можно про эти deep fakes писать в жанре «все пропало». Я вот может кому-то страшную тайну открою, но проблеме детектирования искажения сообщения при передаче через незащищенный канал сто лет в обед. Видео в этом смысле не отличаются ничем. Оригиналы будут шифроваться закрытым ключом, открытым ключом всегда можно будет проверить оригинальное видео или модифицированное.
Может для начала научиться отличать шардинг от репликации? Если у вас при использовании шардинга, который внедряют для ускорения выполнения запросов, они начинают тормозить по сравнению с однонодовой конфигурацией, у вас явно что-то не так.
потому что требует к себе больше внимания (отнимает время разрабов и админов) по-сравнению с обычным подходом
У вас шардинг на уровне приложения реализован? Тогда у меня для вас плохие новости. Если же он реализован на уровне сервера БД, и для приложение представляет single entry point, то какие проблемы у разработчиков?
которая никогда не распухнет больше определенных пределов
Это официальное ограничение или это ваши эмпирические наблюдения за пол-года работы? Если официальное ограничение, почему было принято решение использовать шардинг? Или же в проекте уже была база с шардингом для других данных и для одной таблицы решили не городить огород с отдельным сервером и соединением?
Я ж говорил «пустой звук». Технический долг — это то что мешает вашему проекту масштабироваться и добавлять новый функционал, а не то что вы не понимаете и не желаете изучать, потому что сейчас нагрузки «не те». Если для вас поддержание шардинга в БД — это неподъемная техническая задача, наймите толкового админа, который настроит автоматическое развертывание, бекапы, фейловер.
Конечно, ведь оптимизировать будут через год те самые «недалекие» коллеги, когда нагрузка на сервер возрастет порядка на три после заключения договора с новым «жирным» клиентом. Тихонько матерясь из-за того что автор «сэкономил» на старте день на «не нужной» оптимизации, но теперь надо потратить месяц, на доведение до ума уже запущенного сервиса. А «герой» будет на очередном собеседовании рассказывать как он реализовал за два дня сервис, на который по плану выделялась неделя.
На мой вопрос “А зачем это всё нужно для нагрузки 1 запрос/мин?” получаю лишь укоризненный взгляд от коллег, на лбах которых светится надпись “Вот ты тупоооой”.
Я так понимаю слова «технический долг» для автора-«сеньора» пустой звук, и поддержкой проектов со временем жизни дольше полу-года он никогда не занимался. Но мнение естественно имеет.
У вас есть прикладная задача и инструмент, позволяющий эту задачу решить. Какая разница как там внутри все реализовано, пока инструмент решает задачу и не требует безумных вложений для его поддержки?
Конечно, если вы завтра захотите его продавать под видом инновационного интеллектуального ассистента для написания стихов, работающего на базе нейронной сети с глубоким обучением и хранением данных в распределенном реестре с использованием смарт контрактов, то да тут без питона или в крайнем случае js никуда.
А пока замечательный результат, доказывающий что у вас отличное инженерное мышление.
Как утверждает Nature, AlphaStar не имел никакого особенного преимущества перед обычными игроками, его соперники не знали, что играют против машины.
Да, да. Только совершенно случайно имеет вижн на всю карту. Умеет отдавать команды зданиям и юнитам не выделяя их. С бешеной скоростью меняет составы групп юнитов. И который при этом не может запомнить что он только что заказал и отменил пять старгейтов подряд и заказывает шестой.
Интересно, автор оригинала это сам придумал или ему кто-то подсказал. Инкапсуляция — это только часть ООП, а не все ООП. Хотелось бы узнать ответы автора оригинала на пару вопросов. Есть Клиент, есть Заказ и есть бизнес функция Рассчитать скидку.
Вопрос 1: куда поместить логику расчета скидки?
1. В класс клиента.
2. В класс заказа.
3. В отдельный сервис.
Вопрос 2. Кто в итоге будет «владеть» всем набором данных?
1. Класс клиента.
2. Класс заказа.
3. Сервис.
4. Никто.
В целом я бы переформулировал: если для выполнения некой логики достаточно знать состояние одной сущности, лучше поместить эту логику непосредственно в объект этой сущности.
Но предложенный в дальнейшем пример рефакторинга вполне годный.
Однако это не основное значение слова «польза». Кроме того два этих слова имеют абсолютно разный эмоциональный окрас. Именно поэтому когда пытаются манипулировать, то говорят о некой абстрактной пользе. А вот когда хотят реально вовлечь, говорят о конкретной выгоде.
У меня есть только личный опыт, я не могу обобщать на всех. Могу даже допустить, что есть такие работодатели, которые не используют этот прием для манипулирования сотрудниками.
Да почему же, знакомьте на здоровье, только не в стиле розовых пони и давайте все обнимемся и дружно зашагаем в светлое будущее. Знакомьте разработчиков с процессами, на которых построен бизнес, показывайте разработчикам как ваше приложение позволяет решать реальные задачи бизнеса, например, ускоряет документооборот, повышает скорость принятия решений. Привлекайте разработчика к анализу и оптимизации этих процессов. Дайте ему в конце концов посмотреть на ваше ПО с точки зрения пользователя, чтоб он увидел что его отрефакторенный поиск, который подгружает значения на 20% быстрее, проблемы пользователя не решает, потому что ему надо ручками заполнить 20 полей. А вот функция автозаполнения связанных данных, на которую он забил ради рефакторинга, позволила бы заполнять 3 поля вместо 20.
Сигареты, алкоголь, наркотики, уничтожения излишков товаров для сохранения цены, реклама всяких «фуфломицинов», уничтожение промышленных линий, ради быстрого заработка на распродаже «металлолома» и сдачи в аренду торговых площадей — это все приносит деньги. Какую пользу это приносит кому-либо кроме владельца бизнеса?
Зачем, если этот работает и не требует практически никаких усилий? Рассказал разработчику о важности миссии компании, пригласил на совещание о следующем этапе внедрения продукта, чтоб он молча постоял в сторонке, глядишь и человек уже считает себя не просто наемным сотрудником, а частью команды. А как же можно подвести команду, потребовав прибавки или вообще уйдя с проекта — это же не справедливо по отношению к остальным участникам команды? Затрат ноль, а на некоторых все еще действует. Вот когда это перестает действовать, тогда уже идут в ход разные грейды, которые еще обосновывать надо, актуализировать, если разработчик внезапно решил прокачать скилы, силы свои тратить, время.
Не надо держать разработчика за идиота, не надо ему рассказывать о громадной пользе производимого продукта. Разговаривайте с ним как с взрослым человеком, если он реально взрослый. Объясняйте почему вот все переписать на RUST мы не можем, у нас на это нет бюджета, нам за это никто не заплатит. Но вот если ты предложишь план постепенного улучшения продукта, мы включим его в общий план разработки перемежая с фичами, необходимыми бизнесу. А уж коли включили, то не говорить: ну ты же понимаешь что у нас сейчас сроки горят, вот давай все разгребем, а потом вернемся к твоему плану.
Заработать денег. Принесет это кому-то пользу, кроме владельцев бизнеса — ну замечательно. Принесет это кому-то вред — ну бывает, мир не совершенен. Главное чтоб деньги у владельца бизнеса появлялись.
Заработать денег, точно такая же как и у владельца бизнеса. А еще у него мотивация снизить издержки процесса зарабатывания денег, если это конечно хороший специалист. Соответственно его желание переписать вот этот вот кусок коричневой субстанции обусловлено, не отсутствием понимания целей бизнеса, а пониманием что сейчас мы тратим на внедрение любой новой функции 40 часов и потом еще 80 на исправление багов, а могли бы тратить 20 часов на внедрение фич и 20 часов на исправление тех немногих багов, которые в любом случае будут появляться. Но для этого надо потратить 200 часов на рефакторинг. Но рефакторинг не приносит денег бизнесу.
А вот эти вот рассказы о том какую пользу приносит человечеству разработчик от того что решает проблемы вот этого вот бизнеса, они нужны ровно для одного — платить меньше разработчику, чтоб у владельца бизнеса оставалось больше денег.
Поэтому подружить бизнес с разработкой нельзя.
Прошелся по офису, перемазал понравившиеся телефоны/планшеты/ноутбуки «клеем», накатал заяву в полицию. Как-то не сильно радужно получается.
И опять же как неоднократно намекают в комментариях: все приведенное в статье — это максимум некие гипотезы, которые требуют тщательной проверки, в первую очередь медицинскими специалистами. При этом заголовок статьи содержит такое броское заявление как «Факты доказанные наукой». Это не факты.
www.rlsnet.ru/mnn_index_id_1112.htm
Другой вопрос что для тех кому его реально надо применять польза больше риска осложнений. При COVID-19 пользы от его приема нет, остаются только побочки.
Про гидроксихлорохин уже неоднократно объяснялось — не надо применять, особенно амбулаторно, особенно для профилактики.
vk.com/@zanudascience-lekarstva-i-vakciny-ot-covid-19-aleksei-vodovozov
Так что не надо слепо переписывать рекомендации минздрава.
У вас шардинг на уровне приложения реализован? Тогда у меня для вас плохие новости. Если же он реализован на уровне сервера БД, и для приложение представляет single entry point, то какие проблемы у разработчиков?
Это официальное ограничение или это ваши эмпирические наблюдения за пол-года работы? Если официальное ограничение, почему было принято решение использовать шардинг? Или же в проекте уже была база с шардингом для других данных и для одной таблицы решили не городить огород с отдельным сервером и соединением?
Конечно, ведь оптимизировать будут через год те самые «недалекие» коллеги, когда нагрузка на сервер возрастет порядка на три после заключения договора с новым «жирным» клиентом. Тихонько матерясь из-за того что автор «сэкономил» на старте день на «не нужной» оптимизации, но теперь надо потратить месяц, на доведение до ума уже запущенного сервиса. А «герой» будет на очередном собеседовании рассказывать как он реализовал за два дня сервис, на который по плану выделялась неделя.
Я так понимаю слова «технический долг» для автора-«сеньора» пустой звук, и поддержкой проектов со временем жизни дольше полу-года он никогда не занимался. Но мнение естественно имеет.
У вас есть прикладная задача и инструмент, позволяющий эту задачу решить. Какая разница как там внутри все реализовано, пока инструмент решает задачу и не требует безумных вложений для его поддержки?
Конечно, если вы завтра захотите его продавать под видом инновационного интеллектуального ассистента для написания стихов, работающего на базе нейронной сети с глубоким обучением и хранением данных в распределенном реестре с использованием смарт контрактов, то да тут без питона или в крайнем случае js никуда.
А пока замечательный результат, доказывающий что у вас отличное инженерное мышление.
Т.е. о ППР (планово предупредительных ремонтах), которым сто лет в обед современные «эффективные менеджеры» и разработчики АСУ ТП не в курсе?
Да, да. Только совершенно случайно имеет вижн на всю карту. Умеет отдавать команды зданиям и юнитам не выделяя их. С бешеной скоростью меняет составы групп юнитов. И который при этом не может запомнить что он только что заказал и отменил пять старгейтов подряд и заказывает шестой.