10 принципов объектно-ориентированного программирования, о которых должен знать каждый разработчик
Мне довольно часто встречаются разработчики, которые не слышали о принципах SOLID (мы подробно рассказывали о них здесь. — Пер.) или объектно-ориентированного программирования (ООП), или слышали, но не используют их на практике. В этой статье описываются преимущества принципов ООП, которые помогают разработчику в его ежедневном труде. Некоторые из них хорошо известны, другие — не очень, так что статья будет полезна и новичкам, и уже опытным программистам.
Напоминаем: для всех читателей «»Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Skillbox рекомендует: Образовательный онлайн-курс «Java-разработчик».
DRY (Don’t Repeat Yourself)
Довольно простой принцип, суть которого ясна из названия: «Не повторяйся». Для программиста это означает необходимость ухода от дублирующего кода, а также возможность использовать в работе абстракцию.
Если в коде есть два повторяющихся участка, их стоит объединить в один метод. Если жестко заданное значение используется больше одного раза, стоит преобразовать его в общедоступную константу.
Это нужно для того, чтобы упростить код и сделать его поддержку проще, что является основной задачей ООП. Злоупотреблять объединением тоже не стоит, поскольку один и тот же код не пройдет проверку как с OrderId, так и с SSN.
Инкапсуляция изменений
Программные продукты большинства компаний постоянно развиваются. Значит, в код нужно вносить изменения, его нужно поддерживать. Упростить себе жизнь можно при помощи инкапсуляции. Это позволит более эффективно тестировать и поддерживать имеющуюся базу кода. Вот один из примеров.
Принцип открытости/закрытости
Этот принцип можно легко запомнить, прочитав следующее утверждение: «Программные сущности (классы, модули, функции и т.п.) должны быть открыты для расширения, но закрыты для изменения». На практике это означает, что они могут позволять менять свое поведение без изменения исходного кода.
Принцип важен, когда изменения в исходном коде требуют проведения его пересмотра, модульного тестирования и других процедур. Код, который подчиняется принципу открытости/закрытости, не изменяется при расширении, поэтому с ним гораздо меньше проблем.
Вот пример кода, который нарушает этот принцип.
Если в нем потребуется что-то изменить, на это уйдет много времени, поскольку менять придется все участки кода, у которых есть связь с нужным фрагментом.
Кстати, открытость-закрытость — один из принципов SOLID.
Принцип единственной ответственности (SRP)
Еще один принцип из набора SOLID. Он гласит, что «существует лишь одна причина, приводящая к изменению класса». Класс решает лишь одну задачу. Он может иметь несколько методов, но каждый из них используется лишь для решения общей задачи. Все методы и свойства должны служить только этому.
Ценность этого принципа в том, что он ослабляет связь между отдельным компонентом программного обеспечения и кодом. Если добавить больше одной функциональности в класс, это вводит связь между двумя функциями. Таким образом, если изменить одну из них, велик шанс испортить вторую, связанную с первой. А это означает увеличение циклов тестирования для того, чтобы выявить все проблемы заранее.
Принцип инверсии зависимостей (DIP)
Выше приведен пример кода, где AppManager зависит от EventLogWriter, который, в свою очередь, тесно связан с AppManager. Если нужен иной способ показать уведомление, будь это пуш, SMS или email, нужно изменить класс AppManager.
Проблема может быть решена при помощи DIP. Так, вместо AppManager мы запрашиваем EventLogWriter, который будет введен при помощи фреймворка.
DIP дает возможность без проблем заменять отдельные модули другими, изменяя модуль зависимости. Это дает возможность изменять один модуль, не влияя на остальные.
Композиция вместо наследования
Основных способов повторного использования кода два — это наследование и композиция, причем у каждого есть как свои преимущества, так и недостатки. Обычно предпочтение отдается второму, поскольку он более гибкий.
Композиция дает возможность изменять поведение класса во время выполнения путем установки его свойств. При реализации интерфейсов используется полиморфизм, который дает более гибкую реализацию.
Даже “Effective Java” Джошуа Блох (Joshua Bloch) советует отдавать предпочтение композиции, а не наследованию.
Принцип подстановки Барбары Лисков (LSP)
Еще один принцип из инструментария SOLID. Он гласит, что подтипы должны быть заменяемыми для супертипа. То есть методы и функции, которые работают с суперклассом, должны иметь возможность без проблем работать и с его подклассами.
LSP связан как с принципом единой ответственности, так и с принципом разделения ответственности. Если класс дает больше функциональности, чем подкласс, то последний не будет поддерживать некоторые функции, нарушая этот принцип.
Вот участок кода, который противоречит LSP.
Метод area(Rectangle r) просчитывает площадь Rectangle. Программа упадет после выполнения Square, поскольку Square здесь не является Rectangle. Согласно принципу LSP, функции, которые используют ссылки на базовые классы, должны иметь возможность использовать и объекты производных классов без дополнительных инструкций.
Этот принцип, который является специфичным определением подтипа, был предложен Барбарой Лисков в 1987 году на конференции в основном докладе под названием «Абстракция данных и иерархия» — отсюда и его название.
Принцип разделения интерфейса (ISP)
Очередной принцип SOLID. Согласно ему интерфейс, который не используется, не должен быть реализован. Следование этому принципу помогает системе оставаться гибкой и пригодной для рефакторинга при внесении изменений в логику работы.
Чаще всего эта ситуация происходит, когда интерфейс содержит сразу несколько функциональностей, причем клиенту нужна лишь одна из них.
Поскольку написание интерфейса — сложная задача, после завершения работы изменить его, ничего не нарушив, будет проблемой.
Достоинством принципа ISP в Java является то, что сначала нужно реализовать все методы, и только потом они могут быть использованы классами. Поэтому принцип дает возможность снизить количество методов.
Программирование для интерфейса, а не реализации
Здесь все понятно из названия. Применение этого принципа ведет к созданию гибкого кода, который сможет работать с любой новой реализацией интерфейса.
Следует использовать тип интерфейса для переменных, возвращаемых типов или же типа аргумента метода. Пример — использование SuperClass, а не SubClass.
List numbers= getNumbers();
ArrayList numbers = getNumbers();
Вот практическая реализация того, о чем говорится выше.
Принцип делегирования
Распространенный пример — методы equals() и hashCode() в Java. Когда требуется сравнить два объекта, то это действие делегируется соответствующему классу вместо клиентского.
Преимуществом принципа является отсутствие дублирования кода и относительно простое изменение поведения. Также он применим к делегированию событий.
Все эти принципы позволяют писать более гибкий, красивый и надежный код с высокой связностью и низким зацеплением. Конечно, теория — это хорошо, но чтобы разработчик действительно стал использовать полученные знания, нужна практика. Следующим шагом после освоения принципов ООП может стать изучение шаблонов проектирования для решения общих проблем разработки ПО.
Eugene’s blog
При просмотре вакансий на разных сайтах часто натыкаешься на такие вещи как: “Extensive knowledge in OOA, OOD and OOP”. Тут я подумал: – “Ну ладно OOP. Это я знаю. А что такое OOA, OOD?”. И решил я погуглить. Нашел такой вот интересный пост от какого-то VK_Fan, который я решил перепостить.
“Фаза 1. OOA – Объектно-ориентированный анализ.
Смотришь на постановку задачи, обдумывая, ну и как же сделать эту фиговину. Пытаешься понять, из чего оно в общем и целом состоит и могло бы быть, читая описание, рисуешь всякие там стрелочки, классики, объектики и прочие комментарии в вольном стиле и мысли, приходящие в голову. Когда процесс надоедает (кончается криатифф), переходишь к следующему этапу.
Фаза 2. OOD – Объектно-ориентированное проектирование
Читаешь все каля-маля, нарисованные во время этапа анализа и блуждания по порносайтам, в надежде, что тебя посетит гениальная идея. Пытаешься весь поток сознания хоть как-то систематизировать, разложив его по классам и объектам, продумываешь связи между ними, как они типично будут взаимодействовать друг с другом. Что-то придет само, что-то придется высидеть, а то и захочется нарисовать что-то совершенно абстрактное и вроде как бесполезное, но исключительно стильно выглядящее. Понимаешь, что не клеится. Мнешь лист бумаги, кидаешь в угол комнаты или коллегу по работе. Берешь другой, рисуешь заново, классы, связи, диаграммы стандартные и в свободном стиле, напоминающие инструкции по перебору двигателей. Когда понимаешь, что лучше ты все равно уже не придумаешь, переходишь к фазе внедрения в жизнь.
Фаза 3. OOP – объектно-ориентированное программирование
Берешь свой любимый язык программирования (Ассемблер и HTML не подойдут – нету размаха), и претворяешь наскальные письмена с предыдущей фазы в жизнь – раскладываешь классы на составляющие, разбрасываешь их по файлам исходников, закручиваешь взаимные связи, тихо офигевая от того кошмара, который выходит, понимаешь, что все не так плохо, как кажется, а намного хуже, и ты себе поставишь памятник, если оно хоть когда-нибудь заработает. Пишешь кучу строк текста, попутно матерясь на непроинициализированные указатели, утекшие мегабайты памяти, из-за которых ты хотел нарастить себе оперативку уже до 2 гигов, копаешься в документации, и вот однажды оно оживает и начинает напоминать желаемый результат. Еще труда – и ты у финишной черты.
Затягиваешься сигаретой, выпиваешь бутылку вина, с благоговейным ужасом смотря на то, что ты сделал, понимая, что второй раз ты это не повторишь. Смотришь на себя в зеркало, играя бицепсами/скулами (нужное подчеркнуть) и говоришь себе “Ну какой же я молодец!”.
Share this:
Like this:
Related
One thought on “ OOA/OOD/OOP и прочие матюки ”
OOA – анализ основанный на юз-кейсах. Прикинуть как пользователи будут вести себя с софтом и описать эти случаи. Получится список сценариев, которые ясно раскроют картину происходящего. ООD – на основе полученных сценариев выявляются существительные (классы) и глаголы (операции/методы). Все это можно красиво оформить в UML. И переходить к ООП.
Прочитав один раз книгу Крэг Ларман – UML 2.0…до сих пор использую этот подход при написании софта.
Объектно-ориентированный дизайн и как его использовать для проектирования систем
С тех пор как интерфейсы программ, приложений и сайтов стали сложными, среди дизайнеров началось хаотичное деление на узкие специальности: появились системные и бизнес-аналитики, UX-дизайнеры, UI-дизайнеры, проектировщики и прототипировщики.
Рынок разделился: одни знали о проекте все, другие раскрашивали кнопки, и все были уверены, что любую проблему решит разработчик, у которого просто нет выбора. Разработчики действуют в конце производственной цепочки, и все недочеты в итоге валятся на них. Не удивительно, что теперь в глазах программистов дизайнер, проектировщик и менеджер — это люди, которые только и делают, что мешают работать.
В последние годы эти области начали сближаться. Проектирование соприкасается с дизайном, а дизайн — с версткой. В этом помогают, к примеру, дизайн-системы, storybook’и, созданные по правилам разработки интерфейсов, а также современные инструменты: Figma, Sketch, InVision Studio и другие.
Фокусироваться сперва нужно на том, как система работает, и только после на том, как она выглядит. Чтобы проектировщики, дизайнеры и разработчики одинаково мыслили и лучше понимали, как решать задачи клиента, я использую разные подходы, в том числе и объектно-ориентированный дизайн.
Мой подход основан на OOUX Софии В. Пратер (https://alistapart.com/article/object-oriented-ux/), но дополняет и расширяет его, основываясь на моем опыте применения.
Зачем нужен ООД
Объектно-ориентированный дизайн (ООД) — это методика проектирования, точка, в которой во время работы над продуктом сходятся все члены команды: дизайнеры, проектировщики, разработчики, SEO-специалисты и копирайтеры. В этом случае под дизайном я понимаю не столько внешний вид системы, сколько то, как она работает.
ООД помогает команде решить несколько важных задач.
Определиться, с чего начать
Вопрос «С чего начать?» возникает даже у самых опытных. Допустим, вам нужно разработать мобильное приложение по доставке котиков. Что вы сделаете в первую очередь? Можно начать рисовать экраны или продумывать структуру, а можно проектировать сущности.
Какие сущности есть в таком приложении? Наверняка там будут «пользователь», «заказ» и «котик». У «пользователя» есть имя и фамилия, а заказ можно сделать из двух мест: с экрана товара или с экрана со списком ранее оформленных заказов. Значит позже нужно подумать, как отразить это в интерфейсе.
ООД дает базис, от него можно оттолкнуться, чтобы собрать конструктор из методов, которые подходят именно для этого проекта.
Сэкономить
Проектирование — самый дешевый процесс в создании системы, на этом этапе принято развлекаться, генерировать идеи и смело отметать то, что не подошло.
Однако у проектирования есть очень дорогой и сложный подпроцесс — прототипирование. Зачастую в него вовлечена вся команда и эксперты со стороны клиента, прототипирование делается долго, а в процессе генерируется слишком много отвлеченных идей.
Не хочется чтобы наш дизайнер неделю проектировал, например, функцию отложенной оплаты, которая никогда не будет использоваться. ООД помогает от этого избавиться.
Создать MVP
У себя в компании мы часто работаем со стартапами — ребятами у которых нет денег, но есть сильное желание их заработать. Нам, в свою очередь, хочется сделать меньше и получить больше. Каким-то чудом у нас получается сойтись.
В работе со стартапами ООД помогает разобраться, что является MVP (минимально ценностным продуктом) проекта и в первую очередь сделать только то, что действительно нужно.
MVP — это продукт, который стоит максимально дешево, но уже может приносить пользу конечным пользователям.
Пример очень бюджетного MVP — стартап по продаже обуви Zappos, который невероятно взлетел, привлек много инвестиций и превратился в суперсервис. Но в самом начале у его основателя Ника Свинмерна не было ничего, кроме совсем простого сайта. Он размещал там фотографии обуви из местных магазинов, чтобы понять, есть ли на нее спрос. Когда кто-то делал заказ, Ник покупал эту пару и привозил клиенту. Свинмерн не вкладывался в инфраструктуру и оборудование, но смог создать у клиентов иллюзию полноценного сервиса и с минимальными затратами проверил, востребован ли его продукт.
Исключить хаотичные скачки
Спроектировать все возможные состояния самых сложных страниц, а потом понять, что сайт вообще не нужен — очень обидно. Хочется, чтобы таких ситуаций было меньше, и чтобы команда равномерно двигалась по уровню декомпозиции от большого к малому.
Чтобы не делать лишнюю работу, сначала проектируют объекты и только потом — способы взаимодействия с ними. Пока вы не решили, какие объекты вам нужны и не составили список, не нужно думать о том, что и как с ними делать.
Мыслить таким образом тяжело: обычно мозг сам раскручивает клубок идей и не может остановиться. Если нужно сделать рейтинг, следом обязательно приходит идея добавить отзывы и реферальную программу. Хочется сразу идти и делать, а обсуждать и анализировать необходимость этого не хочется совсем. В такие моменты нужно тормозить себя или клиента и двигаться только по шагам.
С чего начинается ООД. Составляем карту объектов
Главная единица ООД — объект. Этим термином я называю логически выделенную часть системы, с которой можно взаимодействовать и обмениваться сообщениями. Каждый объект — это сущность со значимыми параметрами, которой можно управлять через административную панель.
Чтобы работать над проектом по методу ООД, нужно выявить все объекты системы и разобраться с их свойствами. Для этого в ООД используют специальную карту, которая делается в несколько шагов.
1. Выявляем объекты
Сначала нужно найти все объекты, которые встречаются в системе. Это можно делать с помощью пользовательских историй, я применяю именно такой вариант.
Выявляем все объекты, которые встречаются в системе.
Допустим, мы делаем программу для управления кадрами (HR). В ней HR-менеджер должен иметь возможность выгрузить список всех транзакций по покупкам вакансий на hh.ru, чтобы подготовить месячный отчет.
Здесь можно выделить объекты «пользователь» (с подтипом «HR-менеджер»), «транзакция» и «вакансия». С «вакансией» и «транзакцией» определиться легко: они точно являются объектами, с которыми проводятся операции в системе.
С «отчетом» сложнее. Это точно объект, но нет уверенности, что он должен быть частью вашей системы. Чтобы это понять, вы должны выяснить, для чего пользователю отчет и как именно он с ним взаимодействует.
Может оказаться, что HR-менеджер заходит в текущую программу, выгружает сырые данные о транзакциях в Excel, а потом идет в 1С и уже в этой системе составляет отчет привычным для себя образом. В текущем бизнес процессе возможность создавать отчет в проектируемой вами системе ему не нужна: ваша задача в новой системе дать возможность HR-менеджеру выгрузить список транзакций и не более.
В таком случае проектировщику нужно проанализировать: если сделать объект «отчет» частью новой системы, будет ли достигнут такой эффект, что это оправдает новые инвестиции? Или не стоит тратить на это время и ограничиться текущей реализацией.
2. Определяем параметры объекта и связи
На брейншторме, внутри команды или вместе с заказчиком находим все параметры, которые есть у объектов. Это может быть название, описание или дата создания.
Параметры для объекта «вакансия»
Дальше определяем связи между отдельными объектами. Для этого будут полезны профили пользователей, которые, обычно, составляются с помощью маркетингового исследования.
Для каждого пользователя составляется карточка с профилем, в которой расписаны сценарии и цели. Смотрим на них и думаем, чего бы хотел от объекта конкретный человек, какую информацию ему нужно узнать на странице, какое действие совершить.
Например, обсуждая сценарии отправки резюме на вакансию, мы поняли, что многие соискатели могут не понимать реальный уровень своих навыков. Особенно это актуально для разработчика ПО: у каждой компании свои грейды, возможно, именно в этой организации он пока не дотягивает до статуса Junior или, наоборот, почти дорос до Middle. Поэтому решили добавить на сайт тесты, которые можно пройти, чтобы определить свой уровень.
«Тест» — это отдельный объект, который связан с объектом «вакансия».
С объектом «вакансия» связаны «тест» и «новость».
3. Определить варианты и способы взаимодействия
На этом этапе рассматриваем каждый объект, чтобы понять, какие действия можно с ним совершать. Например, пользователь может откликнуться на вакансию, сохранить ее в избранном или просто посмотреть.
Когда варианты найдены, нужно определить, как именно будет происходить взаимодействие пользователя с объектами. Найти для этого лучшее решение — задача проектировщика интерфейсов.
Варианты взаимодействия определяются на брейншторме, во время которого клиент наконец-то начинает получать удовольствие от процесса, ведь теперь можно придумывать фичи.
Заказчики веселятся и радуются, но делают это в рамках конкретного объекта. Так можно избавится от хаоса, который обычно творится на встречах.
С вакансией можно взаимодействовать тремя способами
4. Определяем свойства параметров
Я придумал для свойств специальные обозначения.
А — автоматический параметр. Он проставляется системой, и человек не имеет к нему отношения. Таким параметром может быть дата или время создания.
Ф — фильтруемый (или сортируемый) параметр. Пользователь может взаимодействовать с ним интерактивно. Например выводить только те экземпляры объекта, которые соответствуют конкретному значению параметра. Допустим, посетитель информационного сайта может отфильтровать новости по темам и читать только про технологии.
Р — параметр, который задается вручную пользователем и/или администратором системы.
С — статический параметр, который вшит в верстку. Им нельзя управлять, а изменить его может только верстальщик либо разработчик.
В — внутренний параметр. Он используется в больших системах, где требуются связи, которые используются для организации внутренней работы с контентом и функциональностью сервиса. Например, внутренние теги. Вакансия отмечается тегом «срочно», чтобы администратор мог в административной панели отфильтровать только те вакансии, которые отмечены этим тегом и в первую очередь начать работу над ними.
Данные этого исследования заносим в таблицу.
Напротив параметров указаны их свойства
5. Указываем способы взаимодействия для функций
Для них тоже задают условные обозначения. У нас они выглядят так:
0 — способ доступен без ограничений любому пользователю.
1 — способ доступен с ограничениями. На данном этапе неважно, с какими именно, главное, что ограничение есть и о нем нужно детально подумать при проектировании.
Способы взаимодействия обозначаются цифрами.
У объектов бывают разные состояния. Вакансия может быть открытой или архивной, но при этом закрытую вакансию все равно можно посмотреть. В графическом виде все связанные объекты неактивной вакансии будут такими же, как прежде, а из способов взаимодействия останется только «просмотр». Возможности «откликнуться» или «добавить пользователя» исчезнут.
Если у объектов несколько состояний, мы используем пунктирную линию и указываем только отличия
Как это работает в моей компании
Описанную систему я периодически применяю уже несколько лет, а отдельные подходы ООД — более 6 лет. За это время мы увидели, какую пользу это приносит.
Получается точнее оценивать проекты
Раньше мы всегда работали по фиксированной цене и очень страдали, если ошибались с оценкой.
Клиенту неважно, укладывается ли аутсорсер в бюджет и хочет ли он делать какую-то работу, исполнитель должен выполнить то, что обещал по той цене, которую назвал.
Обычно мы оценивали проект страницами, делали карту сайта, максимально детализировали ее, но могли не продумать отдельные части backend. «Кто будет верстать админку?», — спрашивал разработчик в самом конце. «В смысле верстать админку?», — удивлялись остальные.
Применение ООД помогло нам оценивать проекты на 20−25% точнее. А главное, у нас появился мост между оценкой проекта и началом работы. Если клиент возвращается через месяц после оценки, у нас уже есть упрощенная модель системы — базис для начала работы.
Помогаем стартапам экономить
Порой ребята из стартапов знают про разработку цифровых продуктов столько же, сколько я про балет, но при этом они очень хотят поиграть в product-менеджеров. Стартаперы вдохновляются известными проектами, просят нас прикрутить на сайт красивую функцию, которую видели в «Инстаграме» или на Airbnb, а потом узнают, что это стоит 500 000 ₽ и пугаются.
Наша задача — показывать таким заказчикам объективную реальность. Список объектов и параметров здорово в этом помогает. Можно сказать человеку: «Смотри, если добавить параметр X, цена вырастет на 100 000 ₽, а если убрать Y — снизится на 200 000 ₽». Обычно клиент счастлив, потому что минус 200 000 ₽ — всегда классно.
Мозговые штурмы стали эффективней
Заказчики бывают разные, иногда к нам приходят сильные эксперты и мы с удовольствием учимся у них. Но бывают клиенты из малого бизнеса, которые знают о технологиях меньше, чем ничего. Мозговые штурмы с такими людьми очень непростые, но ООД помогает держать их в тонусе.
Берем профиль пользователя, кладем карточку на стол и всю встречу говорим только об одном объекте. Например, о том, как Вася взаимодействует с «вакансией». Клиент больше не отвлекается и не уходит в сторону. Раньше мозговые штурмы занимали 2,5−3 часа, а сейчас — 40−60 минут.
Появился обмен знаниями
Нам удалось без принуждения наладить постоянный обмен знаний между командами.
ООД предполагает общий документ, в котором сосредоточены ключевые знания о продукте. Обычно, члены команды подключаются к проекту по мере появление четких результатов предыдущих этапов и разработки ТЗ для их участка работ. При ООД все участники проекта могу подключаться к проекту намного раньше и раньше находить нестыковки, которые можно и нужно сразу обсуждать, вносить изменения и фиксировать в документации. Все мы знаем, как сложно и неприятно сталкиваться с ошибками в огромном ТЗ, которое уже согласовано с клиентом, и как часто участникам проекта не хочется вносить в него изменения, даже если это явно необходимо.
Проще делать контент
У нас есть партнеры, которые делают SEO. Они помогают сформировать правильную декомпозицию страниц, определяют, какие страницы объединять, а для каких делать отдельный интерфейс, в общем, разрабатывают подходящую для поисковых систем структуру. Благодаря ООД они могут работать параллельно проектированию.
Это избавляет клиентов от лишних тревог. Обычные люди, и я в их числе, понятия не имеют, что делает SEO-специалист: он целый месяц творит какую-то магию, а потом ему платят. Заказчик не хочет тратить месяц на непонятную магию, и теперь у нас есть инструмент, который позволяет всем работать сообща, отталкиваясь от одного документа.
Копирайтерам тоже важно подключаться к процессу на этапе проектирования. Раньше до начала разработки сайта они могли лишь продумать стратегию и tone of voice, а теперь берут на себя больше задач: придумывают структуру текстов по каждому объекту (теперь у них на старте есть знания о параметрах объектов и вариантах взаимодействия с ним), создают драфты, выдвигают свои требования и пожелания по формированию состава объектов.
Вместо заключения
ООД — это лишь один из методов проектирования, он очень помогает в работе, но не может заменить собой все. Обычно мы используем ООД для больших контентных сайтов или сервисов, когда систему сложно уложить в голове.
Не стоит применять ООД для небольших корпоративных сайтов из нескольких страниц. Объектов там не будет совсем или найдется несколько совсем очевидных. Для работы с ними не нужен отдельный выделенный процесс.
Еще важно, чтобы документы, составленные в процессе, вовремя обновлялись и были доступны всей команде. Если не делать этого, ООД останется лишь на бумаге, и ни разработчики, ни копирайтеры, ни дизайнеры не станут в этом участвовать.
Этот подход пригодится и для внутренних заказчиков, но аргументация может быть иной: «Если уберем эту функцию, сэкономим 50 часов на проектирование».
Что почитать про ООД
Статьи об OOUX от Sophia V Prater
София ведет блог про UX-дизайн, из ее статей я почерпнул много нового и был удивлен, как похоже и в то же время по-разному мы мыслим. Русский перевод одного текста можно посмотреть здесь.
«Разработка требований к программному обеспечению» Карла Вигерса
Настольная книга любого системного аналитика и проектировщика. Лучше нее нет. Самый важный труд для нашей профессии, по моему мнению.
«Пользовательские истории» Майка Кона
Лучшая и очень емкая книга по пользовательским историям, ее можно прочесть буквально за вечер. В ней вы сможете увидеть весь процесс целиком: от формирования карточек пользователей до разработки и тестирования.