Когда хорошая идея становится популярной - все начинают пересказывать её "как поняли". В итоге в информационном поле от изначальной идеи остаётся настолько мало, что её перестают воспринимать всерьёз. Но когда я, изучая такие идеи, возвращаюсь к контексту их появления и исследую исходные предположения, на которых они основаны, я всегда поражаюсь их изначальной простоте и эффективности. И это закономерно, ведь если изначальная идея была бы никудышной - она бы и не стала популярной.
В этой статье я хочу рассказать о двух таких идеях: Scrum и ООП. В своё время они обе были прорывными и эффективными, но превратились в cargo-культ с десятками интерпретаций. Я же хочу рассказать вам об исходных предположениях, на которых они основаны, и контексте их появления, чтобы вы смогли использовать эти отличные идеи для своей выгоды.
Scrum
Изначальная идея
Возьмём книгу Джеффа Сазерленда "Scrum: искусство выполнять вдвое больше работы за вдвое меньшее время". Сазерленд - это один из создателей Scrum, а эта книга рассказывает историю возникновения методологии и её основные принципы. Это как раз то, что нам нужно. Будем опираться на неё.
Жизненный опыт Джеффа привёл его к следующим мыслям:
Адаптация - Эффективно выживают только те, кто умеет адаптироваться к изменениям
Ценность - Производство продукта, не имеющего подлинной ценности - это безумие
Команда - Небольшие (7±2 человека) сплочённые команды достигают результата быстрее, чем набор разрозненных специалистов
Опираясь на эти предположения мы можем сформулировать стратегию:
Проект выполняется небольшой сплочённой командой в несколько подходов. В конце каждого подхода команда поставляет клиенту готовую и ценную часть продукта. На основе результатов подхода план проекта адаптируется
Фактически - мы получили Agile
Реализовать эту стратегию можно разными способами, которые приведут нас к разным методологиям. Мы рассмотрим способ, который приведёт нас к Scrum.
"Подход" мы будем называть "спринтом". Каждый спринт выполняется по циклу Деминга-Шухарта. Почему именно по нему? Потому что создатели Scrum посчитали его подходящей адаптационной моделью. Можно было бы взять и другую модель, и тогда мы бы получили другую методологию.
Как работает цикл Деминга-Шухарта:
Сначала мы выдвигаем гипотезу: план. Мы предполагаем, что если мы будем делать что-то как-то, то достигнем цели (Plan)
Потом мы следуем этому плану (Do)
Когда план выполнен, тогда мы проверяем, как хорошо мы достигли поставленной цели. А если не достигли, то почему (Check)
На основании этих данных (полученных экспериментальным путём!) мы изменяем свой рабочий процесс (Act) и идём проверять его эффективность на следующем цикле
А теперь соотнесём эти 4 этапа с "ритуалами" Scrum:
"Планирование спринта" - это "Plan"
"Обзор с клиентом" - это "Check"
"Ретроспектива" - это "Act"
"Ежедневный Scrum" - это "Do". Этот этап превратили в самостоятельный маленький цикл Деминга-Шухарта, где Check/Act/Plan выполняются ежедневно в начале рабочего дня
Основа готова. Собираем команду и идём работать. Роли, backlog, user stories и т.д. - это дополнения, необходимые для плавной работы.
Что пошло не так
В изначальном варианте Scrum спринт длился 1 месяц. Ни 2 недели! Ни, тем более, 1 неделю! Месяц! Одна из целей спринта - это поставить клиенту законченную и полезную версию продукта. Если раньше, в проекте на 6 месяцев, мы занимались сначала только сбором требований (1 месяц), потом только анализом (ещё 1 месяц), и только потом реализацией (4 месяца), то по Scrum проект разбивается на 6 спринтов-месяцев, где эти 3 фазы повторяются в каждом спринте.
Подумайте, к чему приводят недельные спринты:
У вас нет времени на сбор требований и анализ. При спринте в 1 месяц вы можете заниматься подготовкой ~ 1 неделю. Вы продумываете план, критерии завершённости, архитектуру, распределяете задачи. При спринте в 1 неделю на это всё у вас есть максимум 1 день. О какой архитектуре или стратегическом планировании тут можно говорить? У вас даже нет времени пообщаться с клиентом, чтобы обновить модель предметной области
У вас нет времени на реализацию. У вас осталось 4 дня, за которые нужно успеть реализовать полноценный Epic. Вы не справляетесь, и вынуждены делить 1 Epic на несколько спринтов. Но пока весь Epic не готов - вы не можете заливать его на PROD. И тогда мы выбираем из 2 зол: либо мы делим Epic на отдельные истории, получая не консистентный UI и кашу в коде; либо релизимся раз в несколько спринтов, что противоречит заявленной стратегии (1 подход = 1 релиз). И тогда зачем вообще сокращать спринт до 1 недели?
Этап планирования становится бессмысленным. Зачем что-либо планировать, если можно сделать "как поняли", показать клиенту, а потом исправлять с его слов? Но во время планирования мы определяем критерии завершённости, которые позже используем на этапах Check и Act. Нет планирования = нет критериев завершённости = нет данных для улучшения процесса
Невозможно распараллелить работу. При планировании на 1 месяц можно создать диаграмму PERT, перетасовать её, чтобы получились несколько параллельных веток, и отдать эти ветки разработчикам. При планировании на 1 неделю это не эффективно. Как следствие на проекте уже не могут работать 7 человек. Команду сокращают до 2-3 человек, что удлиняет время работы над проектом, и не позволяет компании получить на рынке конкурентное преимущество за счёт быстрой сдачи проектов
В изначальной версии Scrum каждый "ритуал" соотносится с этапом цикла Деминга-Шухарта. Ни один из них нельзя выкидывать! Отказавшись от любого из этих ритуалов вы отказываетесь от всего цикла целиком.
Без планирования у вас нет критериев завершённости, чтобы сравнить "ожидание" и "результат". Без ретроспективы вы не улучшаете производственный процесс, а значит не адаптируетесь. Ежедневному Scrum и обзору с клиентом повезло больше, их выкидывают редко. Скорее всего, потому что они позволяют менеджерам "держать руку на пульсе" и контролировать выполнение проекта. Поэтому менеджеры их защищают.
Напомню наши ценности из начала статьи: Адаптация, Ценность, Команда. Если вы выкидываете хотя бы один из ритуалов, то забудьте об Адаптации. Никаких улучшений со временем не будет.
Можно ещё много чего сказать о том, что пошло не так со Scrum. Agile методологии сложны. Это набор принципов и ценностей, которые не связанны между собой логически. А значит всегда есть соблазн что-то выкинуть или изменить, ведь трудно понять, на что это повлияет. Когда-нибудь мы, как сообщество, решим эту проблему. Но не сегодня.
А теперь, давайте окунёмся в мир инженеров.
Объектно-ориентированная парадигма
Изначальная идея
Эта история началась в Xerox PARC. Инженеры этого исследовательского центра работали над революционной идеей: оконным графическим интерфейсом.
Чтобы понимать контекст: в то время все операции производились через консоль или перфокарты. Компьютерных мышей тогда не существовало даже как концепции. Так что идею создать первый в мире интерфейс с окнами и кнопками, который управляется компьютерной мышью, можно по праву назвать революционной.
И вот компьютерная мышь придумана и собрана, концепция интерфейса с окнами, менюшками и кнопками разработана. Есть даже идея для WYSIWYG текстового редактора. Но для программирования этого "добра" существовавшие тогда языки и методологии не подходили, потому что были заточены под один ввод-вывод. Инженерам PARC нужен был способ запрограммировать элементы интерфейса так, чтобы они могли быть независимыми (как например "окна"), но при этом могли взаимодействовать между собой (кнопка внутри одного окна открывает другое и т.п.). И вот что они придумали.
Они дали каждому элементу интерфейса "почтовый ящик". Теперь каждый элемент мог отправлять другим элементам "письма", а получатель "письма" мог на них как-то отреагировать (или не отреагировать, всё зависит от получателя). Давайте называть тех, кто может получать и отправлять письма "объектами", а сами письма будем называть "сообщениями".
Пример. Вы нажимаете на "крестик", чтобы закрыть окно с приложением. Объект кнопки посылает объекту операционной системы сообщение "я кнопка закрытия приложения (id) и на меня нажали". Операционная система отправляет сообщение объекту приложения "тебя хотят закрыть". Приложение подготавливает себя к закрытию и отправляет сообщение операционной системе "я приложение (id) готово к закрытию". После чего операционная система завершает процесс. А что случится, если приложению отправили сообщение о закрытии, но от него долго не поступает ответ? Вы видите на экране сообщение "Приложение не отвечает".
Так и появилась ООП, которое мы сейчас знаем. Системы в них - это набор объектов, которые могут посылать друг другу сообщения и реагировать на эти сообщения. По своему устройству это асинхронная система, потому что ответы на сообщения не предполагались. На основе этой парадигмы реализовали язык Smalltalk, на котором и запрограммировали первый в мире компьютер с графическим интерфейсом Xerox Alto.
А потом...
А потом Xerox не поняла, что с этим изобретением делать, и положила Alto пылиться на склад. В PARC приехал Стив Джобс, увидел Alto, и Apple создала Machintosh. А под вдохновением от Machintosh появилась графическая оболочка для MS-DOS под названием Windows. А Xerox всё ещё продаёт принтеры c 7253-й строчкой по капитализации. В общем, так им и надо. Нечего было недооценивать своих инженеров.
Давайте введём определение:
Объектно-ориентированная парадигма описывает систему как набор объектов, обменивающихся друг с другом сообщениями
Вот некоторые выводы, которые можно из этого сделать:
ООП видит систему как "подсеть". Можете сравнить это с несколькими телефонами и ноутбуками в квартире, связанными через Bluetooth (или через wi-fi, но тогда у них есть маршрутизатор. Кстати, вы только что открыли паттерн "Mediator"). Каждый такой телефон или ноутбук - это объект. Запросы по сети между ними - это сообщения
ООП отлично справляется с моделированием передачи данных, и никак не помогает в их трансформации. Если вам нужно превратить один тип данных в другой по каким то правилам - воспользуйтесь ФП или СП. А вот если нужно смоделировать общение между узлами сети, да ещё и асинхронное, то ООП в этом пока нет равных
Лучшее применение ООП находит в программировании UI, сетевом взаимодействии и программировании конечных автоматов
Что пошло не так
Всю проблему с ООП можно описать одним предложением: "Её используют там, где не нужно, и не используют там, где нужно".
Нет смысла моделировать всю систему через объекты. Если предположить, что "Программная система - это набор UseCase'ов по передаче, трансформации и хранению данных", то ООП хорошо справляется только с "передачей". Для трансформации лучше всего подходит функциональная парадигма. Для хранения (чтение и запись) - реляционная.
Вот хороший и лёгкий пример применения ООП. Вы пишете небольшую программную систему, и она может связываться с другими программными системами (через сеть или процессы). Представьте каждую внешнюю систему как объект. Предположим, что ваше приложение взаимодействует с базой данных, сервисом для отправки SMS и облачным хранилищем файлов. Создайте для каждого из них интерфейс (абстракция):
interface Database
{
public function saveUser(User $user): void;
public function getUser(UserId $id): ?User;
}
interface SmsService
{
public function send(Phone $number, string $text): void;
}
interface AmazonStorage
{
public function put(File $file): void;
public function get(FileId $id): ?File;
}Потом создайте 2 реализации: одну для тестов, а другую для PROD (полиморфизм). Внутри реализации для RPOD объект будет хранить адрес сервиса и credentials, самостоятельно настраивая и отправляя запросы по сети (инкапсуляция).
Пример с UI (крестик для закрытия окна) вы уже видели выше. Если вы пишете интерфейсы на JS, то там посылки сообщений используются почти для всего. Чаще они делаются через замыкание, но их можно превратить в объекты:
// Посылка сообщения `open` объекту `modal` при клике на кнопку
button.addEventListener('click', modal.open);"Когда у вас в руках молоток - все вокруг становится похоже на гвоздь". Помните, что ООП - это про посылку сообщений. Используйте его для настраивания взаимодействия между изолированными программными модулями. А трансформацию данных оставьте ФП. Связка из этих двух парадигм - лучшее решение при создании приложений.
P.S. И прошу, не надо больше кошек, собак и машин. Вам нужны все данные из этих объектов, и по итогу вы просто делаете getters и setters для каждого поля. Для моделирования предметных областей лучше всего подойдёт ФП. Методологию можете прочитать в книге "Domain Modelling Made Functional" (Scott Wlaschin).
Итог
Даже хорошие идеи со временем могут преобразиться в худшую сторону. Понимание логики, стоящей за идеей, позволит вам понять её суть и использовать в свою пользу.
В этой статье мы рассмотрели 2 такие идеи:
Scrum - это Agile методология (Адаптивность, Ценность, Команда), которая реализована через цикл Деминга-Шухарта
ООП - это парадигма, которая рассматривает систему как набор объектов, обменивающихся сообщениями
Комментарии (35)
octoMax
24.10.2025 13:44А чем Scrum отличается (ну кроме лексики) от утренней планерки у директора металлургического комбината (ну или любой другой конторы)? Я первый раз на такой "скрам" попал в 7 лет, когда садик уже закончился, а школа не началась. Целый месяц на таких скрамах сидел. По сути никакого отличия кроме "я вчера писал код для фичи А, а сегодня буду переписывать, так как продакт передумал" VS "я вчера ..ля как последний ...к ...ля работал над этими ...ми деталями к заказ-наряду, а сегодня утром выясняется, что они ...й не .... и вообще надо делать было другое"
Скрам это тупо маркетинговая обертка над банальной планеркой
lifespirit
24.10.2025 13:44В целом не отличается ничем, но, как обычно, есть ньюанс. Если вы не завод а, например, огромная ИТ корпорация, и вы пытаетесь выпустить нечто на рынок, то для многих (очень многих) людей оказывается откровением что:
не нужно составлять планы "как я буду год строить платформу" тратя кучу времени и ресурсов на планирование чего-то что никогда не случится.
Команда из 5-7 человек из разных отделов, закрепленная за проектом эффективнее чем "если тебе нужна виртуалка напиши заявку в отдел виртуализации и жди согласования всех менеджеров 2 недели", "если тебе нужен репозиторий заведи заявку и жди согласования 20 ИБшников целый месяц".
У продукта должен быть цикл проверки состоятельности с реальным решением его дальнейшей судьбы не раз в 5 лет.
Лично я думаю что в целом scrum - естественный враг бюрократии. И в результате его превратили в непонятно что пытаясь продать максимально бюрократизированным кампаниям.
MrShnaider Автор
24.10.2025 13:44Наверно, вы имели ввиду: чем отличается "Ежедневный Scrum" (он же stand-up встреча) от планёрки. Потому что Scrum - это методология организации деятельности, и это далеко не только stand-up'ы. По своей сути - не отличается. Stand-up это действительно планёрка (за исключением нюансов, связанных с PDCA-циклом).
Но в вашем комментарии я заметил боль: "На планёрке мы рассказываем о том, что будем переделывать, потому что заказчик передумал". Такие ситуации говорят о нездоровом рабочем процессе. И часто означают некомпетентность менеджеров: линейного (бригадира) и проектного (начальника цеха).
Деятельность исполнителей должна иметь смысл. Попадая в ситуацию, в которой их заставили делать ненужную работу, они чувствуют себя "дураками", а свою деятельность перестают считать полезной. При этом они сами ничего не могут с этим сделать, что вызывает у них ещё больше негативных эмоций.
Если говорить про Scrum, то это решается "планированием спринта". Когда заказчик согласился с "критериями завершённости" спринта, тогда программисты идут работать, и план на спринт больше никто не изменяет. Приоритеты никто не трогает и люди спокойно работают в течении всего выделенного времени (а это, как и написано в статье, от 2 недель до 1 месяца)
Если у вас часто происходят такие ситуации со сменой приоритетов, то вашим менеджерам нужно больше компетенций. Ну или вам, чтобы им это объяснить.
themen2
24.10.2025 13:44200%. Но попробуй, сделай замечание такое менеджерам. Они сразу же обидятся и скажут тебе, что ты не гибкий... У работника нету власти, кроме как уйти
Akon32
24.10.2025 13:44Идеи эволюционируют, адаптируясь под условия. Ну не может ни скрам, ни ООП оставаться тем же, что и 30-40 лет назад, когда мир меняется.
И ещё успешность подхода зависит от реализации. Создатели ООП вряд ли рассчитывали, что необходимо наследовать собаку от кошки или кошку от собаки, а сейчас в большинстве споров об ООП кто-то пытается выбрать один из этих (неправильных) вариантов. Так же и скрам - методология может работать даже при больших отступлениях от правил (эти подходы уже не являются скрамом согласно scrum guide), а может не работать при декларируемом строгом следовании правилам.
Но в целом и ООП, и скрам - хорошие идеи для разработки (если не разбивать о них лоб).
Atorian
24.10.2025 13:44Если не разбивать о них лоб - это как раз про то, что они потеряли смысл.
Идеи не меняются. Их бывает толкуют не верно. Но скорее появится что-то новое, чем старое изменит смысл.
Скрам - не скрам, если его изменить. Но люди в скудоумии своём не могут в абстракции и дать другой идее новое имя. По этому как те зомби повторяют - Мозги.
pomponchik
24.10.2025 13:44Большинство сегодня пишет на мультипарадигменных языках, где подобной дихотомии просто нет.
MrShnaider Автор
24.10.2025 13:44И это прекрасно. Даже в изначально FP языки добавляют объектную нотацию.
Но вот сами программисты могут и не пользоваться мульти-парадигменностью. Если почитать книги из 90-ыx / 00-ых (например "Применение UML 2.0 и шаблонов проектирования "), то там советуют ВСЮ программу писать в ООП. Да не просто писать, а ещё и проводить анализ и проектирование в ООП терминах.
Учитывая объем и кол-во материалов, которые предлагают так делать, напомнить о мульти-парадигменности (и областях применения разных парадигм) лишним никогда не будет
spas2001
24.10.2025 13:44Хорошая статья. Очень показательно, что люди не понимая идею, выстраивают карго-культ. Наконец-то кто-то попытался донести простую истину: "Не сотвори себе кумира"!
warkid
24.10.2025 13:44Со скрамом так получилось изначально, так-как стали делать бизнес на сертификации. Чтобы стать кумиром, надо было заплатить. Вот и расплодилось скрам-мастеров.
kain64b
24.10.2025 13:44"Критикует - предлагай"
Сервис/канбан, да любой из agile, просто набор церемоний , как конструктор, собери под свой проект, кажется agile как раз про гибкость, а не твердолобое выполнение церемоний, agile manifesto вам в руки.
Тоже самое про ООП.. в ООП яп давно пышные вещи.
Попробуйте разработать что-то большое без всего этого, покажите что получилось. Новички часто страдают критикой, вырабатывают какие-то мега инструкции, пробуют какие о новые подходы без адаптации к задаче и говорят : ну гавно же. Не гавно, просто выбирайте инструмент под задачу, и даже выбранные инструменты дорабатывайте под задачу. Как раз делал ревью кода, где чувак не понимает , что речь это не rmi, что нужно немного в структурность, не нужно писать дубликаты типа getbycompanyid, getbyclientid, getbyxxxx, не понимает зачем и как валидироватьтвходные данные, но твердо предлагает перейти на другой подход к бранчингу в проекте.
Lewigh
24.10.2025 13:44Тоже самое про ООП.. в ООП яп давно пышные вещи.
Попробуйте разработать что-то большое без всего этого, покажите что получилось.
Раскройте пожалуйста тему, почему без ООП, по Вашему мнению, нельзя построить что-то большое?
Kerman
24.10.2025 13:44Давайте я. ООП - это в первую очередь инструмент. Инструмент управления сложностью. Его парадигма - скрытие деталей от тех кусков кода, которым это не надо знать. Если им пользоваться, то гораздо проще потом ориентироваться в своих же собственных абстракциях, тупо скоп меньше и понятнее.
По моему опыту все большие проекты написаны на ООП. Даже линукс, который на С и тот использует ООП-приёмы, когда в структурах пишутся колбеки на функции для этой структуры. А вот ФП-шных проектов, достаточно больших, я что-то не припомню.
vadimr
24.10.2025 13:44А по моему опыту все большие проекты написаны процедурно, с использованием атрибутов ООП только по синтаксической необходимости. Причём это происходит не потому, что так кто-то специально придумал, а потому, что это самый простой способ писать говнокод, к которому с неизбежностью всё скатывается через год-другой. Через 10 лет – к собственным особым версиям компиляторов, необходимых для построения проекта, а через 30 лет – к заплаткам в машинном коде (к этому времени исходные тексты обычно в существенной части уже утеряны).
Даже линукс, который на С и тот использует ООП-приёмы, когда в структурах пишутся колбеки на функции для этой структуры.
Вам не странно "колбеки на функции" называть "ООП-приёмом", хотя даже сами термины относятся к другим идеологиям?
WieRuindl
24.10.2025 13:44Про скрам ничего не понял, но в целом-то пофиг, какая там методология. Сколько раз я слышал и про скрамы, и про аджайлы, а в конечном итоге все сводится к тому, что ты берёшь задачу и пишешь код. Вся эта возня с методологиями, процессами и прочее - это какая-то менеджерская возня, в которую мне неинтересно и не хочется лезть. Я умею и хочу писать код, а как это будет называться в отчётах мне безразлично
А вот про ООП мне есть что сказать. Я за последние несколько леи поработал на разных проектах с разными командами, и вижу, что люди массово не умеют в ООП. Умные слова типа "интерфейс", "SOLID", "инкапсуляция" и другие они выучили, и считают, что теперь они пишут ООП код. А они нет. Городят абстракции где не надо, где надо не делают, интерфейсы у них по 10 методов, в классах по 20 филдов, DTO мутабельные, одни приватные методы вызывают другие приватные методы матрёшкой, все это обмазано switch/case и instanceof, try-catch напоминает местами простыню тайпчеков по разным ексепшенам, и конца и края этому нет. Проблема не в ООП как инструменте, а в том, что многие не умеют инструментом пользоваться, и это грустно
Atorian
24.10.2025 13:44А null? Там же были проверки на нул в каждом методе? :)
У меня ровно такая же проблема с командой. Только теперь я могу на это повлиять.
WieRuindl
24.10.2025 13:44Повсеместного null-чекинга не помню, но не исключаю, что моя психика в какой-то момент просто уже не выдержала и заблокировала травму :(
Я на этот ужас повлиять не сумел, хотя очень пытался. И на созвонах с коллегами поднимал эти вопросы неоднократно, и с тим лидом one-to-one беседовал, и, блин, даже с психологом обсуждал эту тему, типа мало ли я просто слишком эмоционально это воспринимаю, а на самом деле все не так плохо. В конечном итоге свалил нафиг из того проекта и той компании в целом
Atorian
24.10.2025 13:44Как говорил Фаулер: "if you can't change your team - change your team" :)
Правильно сделали. Нечего в чужом болоте тонуть.
muhachev
24.10.2025 13:44Методологии эти придуманы тупыми и ленивыми менеджерами, которые в страстном порыве получения абсолютной власти, достигнув вершины уровня некомпетенции, захотели, хотя бы ритуально, контролировать то, что они контролировать не в состоянии в принципе, в силу полного отсутствия понимания, а также желания и способностей понимать, то, что они пытаются контролировать, и реализовали эти свои бессмысленные хотелки в виде менеджериальных карго культов.
MrShnaider Автор
24.10.2025 13:44Менеджеры действительно адаптировали Agile методологии под себя. И так как, к сожалению, среди менеджеров много некомпетентных специалистов - эти адаптации исказили суть методологий.
Однако в истоках их возникновения вы ошибаетесь. Они уходят корнями в "научный метод" и "производственную систему Toyota". В начале 90-ых (после выхода GoF) на конференциях для программистов начинают появляться "паттерны разработки". И в 2001 появляется Agile Manifesto, который разработали тоже, в основном, программисты.
SolidSnack
24.10.2025 13:44Извините меня конечно, но если вы занимаетесь просвещением людей по наболевшей теме, как можно писать... такое?
ООП отлично справляется с моделированием передачи данных, и никак не помогает в их трансформации. Если вам нужно превратить один тип данных в другой по каким то правилам - воспользуйтесь ФП или СП
Помните, что ООП - это про посылку сообщений.
Вы хотя-бы книгу Мартина читали про архитектуру? Или банды про ООП...
Dywar
24.10.2025 13:44Поддерживаю.
На хабре в этой статье уже спорили на тему что такое ООП - https://habr.com/ru/articles/554474/
Мне ближе 3-6 парадигм ООП, чем просто одна из них - обмен сообщениями.
Походу это привычка сформированная обилием материала с этим уколоном.
Вероятно он победил, если более распространен, или я попал не в ту ветку, о боже какая катастрофа :)
Как и то что массивы индексируются, хотя индекса там нет, есть смещение. Видать холиварить тут не так интересно :)SolidSnack
24.10.2025 13:44Приведенная вами статья в правильную сторону копает, как по мне. Но там, как и в этой статье, почему-то ООП определяется через посылку сообщений, хотя в книге банды четырех (по моему) четко говорится что в ООП метод должен получать только другие объекты, что само собой, изначально, подразумивает изменения данных под структуры (го) классы (много всего другого) и уже эти объекты передавать туда сюда.
MrShnaider Автор
24.10.2025 13:44Не совсем понял, что значит "писать такое". Но наверно вас смутило расхождение моей формулировки (а на самом деле формулировки Алана Кея) и Мартина + GoF.
Так как мы в этой статье возвращаемся к "истокам", то вот формулировка Алана Кея (инженера PARC, создавшего привычное нам ООП и Smalltalk):
Для меня ООП — это только отправка сообщений, локальное хранение, защита и сокрытие состояния-процесса, а также предельно позднее связывание всего
Так что даже прочитав все книги Роберта Мартина и GoF, я придерживаюсь изначального определения. А особенно в этой статье, которая говорит о возникновении и истоках ООП.
Вот почему я придерживаюсь именно определения с отправкой сообщений:
Оно даёт чёткое разграничение между парадигмами. "ООП представляет систему как набор объектов, обменивающихся друг с другом сообщениями"; "ФП представляет систему как набор декларативных правил, описывающих соотношения между типами данных"; "СП представляет систему как последовательность команд, ветвлений и циклов". В каждом определении есть свой "взгляд на систему", что и определяет слово "парадигма" как термин
Это простое определение. Не лёгкое, а именно простое. Это значит, что из него ничего нельзя выкинуть (оно имеет минимальное кол-во элементов), и при изменении любого элемента мы можем предсказать будущее поведение системы (все причина-следственные связи очевидны). Иметь 3-4 принципа (абстракция, инкапсуляция и т.д.) - это сложно, потому что они не связаны между собой
Stanislav_Z
24.10.2025 13:44Для трансформации лучше всего подходит функциональная парадигма. Для хранения (чтение и запись) - реляционная.
Интересно было бы посмотреть на пример. Пока не очень понятно
bel1k0v-da
24.10.2025 13:44Вот хороший и лёгкий пример применения ООП.
Нет, вы привели антипаттерн. В вашем примере нет понимания разницы между интерфейсом и конкретным классом. RTFM
ImagineTables
24.10.2025 13:44У авторов идей нет эксклюзивного права ими распоряжаться, к счастью или несчастью.
Вот два примера «к несчастью»: MFC и jQuery. MFC создавалась как способ писать редакторы файлов на базе парадигмы Model-View-Controller. Но для 95% программистов это была либо «стандартная» библиотека C++ (тут я их не осуждаю,
CStringиCArrayбыли очень дружелюбными по сравнению с другими стандартными библиотеками, с кавычками и без), либо тоненькая обёртка над WinAPI. jQuery была попыткой сделать более функциональной работу с DOM (язык JS был изрядно функциональным, а вот корявый DOM API браузеров — императивным на уровне, я не знаю, Си или ассемблера). Но для 95% программистов это был всего лишь селекторный движок. Когда в корявом DOM API браузеров появился доступ к нативному селекторному движку, для многих программистов jQuery стал не нужен.Что касается ООП, тут дело сложилось более счастливым образом. Во-первых, если почитать Алана Кея, который, типа, изобрёл ООП, он же рассказывает, что сделал это, применив принцип Бартона. Отсюда все эти «объекты это маленькие компьютеры» и «отправки писем». Но принцип Бартона можно применить и иначе, как в C++: уравнять функции с полями и получить методы (ой, извините, член-функции… пока кто-нибудь не уронил монокль в бокал с коктейлем (ц)). А можно вообще вывести из принципа Бартона функциональное программирование. Например, уравнять функции с аргументами в праве быть параметрами.
Так что, не думаю, что правильно понимать идею ООП как «маленькие компьютеры» и «отправки писем». (Я бы даже сказал, это довольно неочевидное применение принципа Бартона). Самое продуктивное (приносящее огромную пользу) понимание, что я видел, это считать ООП способом организации кода, который поможет человеку, знающему предметную область, легче находить имплементации. Юзеру библиотеки — написать точку или стрелочку и увидеть полный список. А автору библиотеки найти класс, а затем искать имплементацию (структуру полей и функции) в нём.
vadimr
24.10.2025 13:44это считать ООП способом организации кода, который поможет человеку, знающему предметную область, легче находить имплементации
Очень странный взгляд на вещи.
Что вы тогда скажете о DSL?
Или у вас "человек, знающий предметную область" одновременно автоматически является ООП-программистом? Тогда утверждение, что ООП помогает ООП-программисту, является тавтологией.
ImagineTables
24.10.2025 13:44Этот «очень странный взгляд на вещи» распространён гораздо шире, чем исходная идея Алана Кея с «письмами». О чём, по-вашему, эта статья?
CrashLogger
24.10.2025 13:44Интересно, автор сам что-нибудь писал серьезное в ООП парадигме ? Ну не делаем мы геттеры и сеттеры на каждое поле. Зачем выставлять наружу внутренние кишки реализации алгоритма ? Да, бывают классы, предназначенные только для хранения данных, они называются структурами в C++ и POD в Java но у них не делают геттеры и сеттеры, они там не нужны. Просто все поля делают public.
vadimr
24.10.2025 13:44Автор о том и пишет, что изначальный смысл потерялся. Изначальному ООП в стиле Смоллтока с геттерами и сеттерами было, например, наплевать, как распределены объекты внутри компьютера или по сети. А чтобы использовать public поля, вы должны быть, как минимум, в одном адресном пространстве с используемым объектом.
Классического ООП, честно говоря, больше осталось в функциональных языках вроде Erlang и Termite, чем в современных "объектно-ориентированных" языках.
kenomimi
24.10.2025 13:44Месяц на спринт в более-менее крупном продукте - это курам на смех, ни о чем вообще. Неделю просто скушает общение по фиче с заказчиком, еще две - постановка задач по тому, что узнали от заказчика, уточнения, еще к юристам сходить надо, чтобы вычитали. Сколько там разработка, учитывать не будем, ибо зависит от фичи. Дальше фичу надо отдать на тестирование, и тестируется не только фича, но и весь функционал, который потенциально может быть задет. Еще неделя на ручное тестирование, автотесты, проверки ИБ. Дальше всегда будут баги, которые надо закрыть - еще неделя-две с частичным перетестированием. И, может быть, неделю на релиз, потому как его надо согласовать с бизнесом - не у всех бесшовная раскатка есть. Цикл в три месяца - это минимум для крупного продукта. Для небольшого продукта и простых фич можно уложится в месяц, но это прям с авралом и горящими ср(а|о)ками.
А для этапа поддержки, когда основная разработка закончилась, лучше всего подходит канбан, особенно если его адаптировать под свои реалии.
MrShnaider Автор
24.10.2025 13:44Не буду спорить, что на некоторых проектах 1 месяца может быть мало. Но если общение, постановка задач, проверка юристов и безопасников, тестирование, фикс багов и релиз занимают столько же времени, сколько и разработка, то проблема не в длине спринта, а в неоптимизированном процессе разработки. Если постановка задач занимает 2 недели, а после разработки вы ещё столько же фиксите баги, то тут явно что-то не так. В вашем конкретном случае я бы обратился к инженеру-технологу и попросил бы оптимизировать процесс.
SvetlanaDen
Для меня актуальная тема — напоминает о том, что за модными терминами часто теряется суть изначально гениальных идей. Особенно развенчание мифов вокруг Scrum приятно видеть.