Эффективные методики разработки ПО

1. Эффективные методики разработки ПО

Подготовил Кириллов Андрей
Группа АС-19-04

2. Содержание презентации

01
02
Прежде чем
кодить
Управление
сложностью
03
04
Классы
Немного ООП

3. Разработка ПО – сложный процесс

Определение проблемы
Выработка требований
Разработка архитектуры
Кодирование и отладка
Тестирование
Сопровождение

4. Метафора «Строительство здания»

Сравнение конструирования ПО с возведением здания
указывает на необходимость тщательной подготовки
к проекту и проясняет различие между крупными и
небольшими проектами.

5. Важность предварительных условий

Общая цель подготовки — снижение риска: адекватное
планирование позволяет исключить главные аспекты риска на
самых ранних стадиях работы, чтобы основную часть проекта
можно было выполнить максимально эффективно.

6.

Определение проблемы
Определение проблемы — это просто формулировка
сути проблемы без каких-либо намеков на ее
возможные решения

7. Выработка требований

Требования подробно описывают, что должна делать программная
система. Адекватное определение требований — одно из
важнейших условий успеха проекта. Внимание к требованиям
помогает свести к минимуму изменения системы после начала
разработки.

8. Разработка архитектуры

Это высокоуровневая часть проекта приложения,
каркас, состоящий из деталей проекта
Она позволяет разделить работу на части, над
которыми отдельные разработчики и группы могут
трудиться независимо.

9.

Компоненты архитектуры
Основные классы
Безопасность
Организация данных
Производительность
Бизнес-правила
Масштабируемость
Пользовательский интерфейс
Обработка ошибок
Управление ресурсами
Купить или создавать
велосипед

10.

Основные классы
Их области ответственности
Взаимодействия с другими классами
Иерархия
Время существования объектов

11. Управление сложностью

Управление сложностью — самый важный технический
аспект разработки ПО. Мы должны попытаться
организовать программы так, чтобы можно было безопасно
работать с их отдельными фрагментами по очереди.
Избегайте создания хитроумных решений

12. Как управлять сложностью?

13. Простота сопровождения

Проектируя приложение, не забывайте о программистах,
которые будут его сопровождать.
Постоянно представляйте себе вопросы,
которые будут возникать у них при взгляде на
создаваемый вами код.

14. Управление сложностью

Слабое сопряжение: сводите к минимуму число
соединений между разными частями программы.
Расширяемость: изменение одного фрагмента
системы не должно влиять на ее другие фрагменты
Минимальная, но полная функциональность:
программа закончена не тогда, когда в нее больше
нечего добавить, а когда из нее ничего нельзя
выбросить.

15.

Классы
Это Абстрактный тип данных(АТД) - набор данных и
методов, имеющих общую, целостную, хорошо
определенную сферу ответственности.

16. Нужно определить:

• АТД и его атрибуты
• действия, которые могут быть выполнены над классом
• Действия, которые класс может выполнять над другими
объектами
• Части класса, видимые снаружи
Интерфейс класса

17.

Выражайте в интерфейсе класса согласованный уровень
абстракции
<- Плохо
Хорошо ->
Каждый класс должен
быть реализацией
только одного АТД

18.

Другие советы
• Убедитесь, что вы понимаете, реализацией какой абстракции
является класс
• Предоставляйте методы вместе с противоположными им методами
• Убирайте постороннюю информацию в другие классы
• Интерфейс класса должен сообщать как можно меньше о внутренней
работе класса
• Опасайтесь нарушения целостности интерфейса при изменении
класса

19. Инкапсуляция

Инкапсуляция позволяет вам смотреть на дом, но не
дает подойти достаточно близко, чтобы узнать, из чего
сделана дверь.
Инкапсуляция управляет сложностью.

20.

Применение инкапсуляции
• Не делайте данные-члены открытыми
• Не включайте в интерфейс класса закрытые детали
реализации
• Не делайте предположений о клиентах класса
• Избегайте использования дружественных классов
• Цените легкость чтения кода выше, чем удобство его
написания
• Очень настороженно относитесь к семантическим
нарушениям инкапсуляции (вызывает зависимость
клиентского кода от закрытой реализации)

21. Наследование

Наследование подразумевает, что один класс является
более специализированной версией другого класса
Базовый класс формулирует ожидания и ограничения,
которым должен будет соответствовать производный
класс (Meyers, 1998).

22. Применение наследования

• Проектируйте и документируйте классы с учетом возможности
наследования или запретите его
• Соблюдайте принцип подстановки Лисков - «Клиенты должны
иметь возможность использования подклассов через интерфейс
базового класса, не замечая никаких различий»
• Убедитесь, что вы наследуете только то, что хотите
наследовать(реализацию или только интерфейс)
• Перемещайте общие интерфейсы, данные и формы поведения на
как можно более высокий уровень иерархии наследования

23.

Наследование часто противоречит
управлению сложностью

24.

Методы классов
• Включайте в класс как можно меньше методов
• Блокируйте неявно сгенерированные методы и операторы,
которые вам не нужны
• Избегайте опосредованных вызовов методов других классов
Func1().Func2().Func3()
• Минимизируйте сотрудничество класса с другими классами

25. Причины создания классов

Моделирование объектов реального мира;
Моделирование абстрактных объектов;
Снижение сложности;
Изоляция сложности;
Сокрытие деталей реализации;
Ограничение влияния изменений;
Облегчение повторного использования кода

26. Итоги презентации

Уделяем внимание предварительным требованиям и
архитектуре
Стараемся свести сложность к минимуму
Класс должен формировать согласованную абстракцию
Скрываем особенности реализации

27. Источник

Стив Макконнелл. Совершенный код

28. Спасибо за внимание!