SlideShare a Scribd company logo
Анти-паттерн ы Чего в ИТ следует боятся ? Автор: Борис Лебеда
Паттерн ы и антипаттерны Паттерн  – типовое архитектурное решение характерн ых задач. Антипаттерн  –  часто принимаемое решение, которое приводит к негативным последствиям .
Классификация антипаттернов Антипаттерны разработки Антипаттерны архитектуры Антипаттерны менеджмента
Описание антипаттерна Характерные признаки Причины Решение Профилактика Исключения
Базов ые причины неправильных решений в ИТ Поспешность Узкий кругозор Лень Недальновидность Профессиональное самолюбие Стремление к сложности
Факторы успеха ИТ-проектов Контроль функциональности Контроль производительности Контроль сложности Контроль модификаций Управление ресурсами Управление технологиями Разработчики Архитекторы Менеджеры Топ менеджеры
Антипаттерны разработки Макаронный код Blob  ( God class) Застывшая лава Полтергейст Copy-Paste programming Серебряная пуля Минное поле Call super Singletonitis Error hiding Exception handling Магические числа Hard code
Макаронный код ( Spaghetti code) Характерные признаки : Слабая архитектура: Методы зависимы от процесса в котором они принимают участие, чаще всего вызываются только в единственном случае Злоупотребление глобальными переменными, ограниченность сигнатур методов Как следствие: слабая возможность повторного использования кода Причины : Лень,  Недальновидность Решение : Зачистка кода, рефакторинг Профилактика : Контроль сложности и изменений Исключения :  wrapping  внешнего сложного интерфейса
Blob (God class) Характерные признаки : Реализация значительной части функциональности в одном классе при наличии нефункциональных классов сателитов. Раздутый интерфейс класса (нет ограничений в области видимости) Причины : Лень,  Спешка Решение : делегирование функциональности сателитам. Защищённое программирование Профилактика : Контроль функциональности, производительности и сложности Исключения : нет. Всегда плохо
Blob (God class)
Застывшая лава ( Lava flow) Характерные признаки : Наличие значительного количества недокументированного или рудиментарного кода. Связан с таким понятием как постоянное устаревание Причины : Профессиональное самолюбие, лень Решение : улучшение процесса разработки Профилактика : Контроль модификаций, технологий Исключения : разработка прототипов на выброс или временных утилит
Застывшая лава ( Lava flow)
Полтергейст Характерные признаки : Класс связанный с соответствующим процессом. Причины : лень Решение : инкапсуляция «привидений» Профилактика : Контроль функциональности, сложности Исключения : нет ClassA ClassB
Copy-Paste programming Характерные признаки : Наличие дупликаций кода Обнаружение похожих дефектов Возрастание числа строк кода Причины : лень Решение : практика использования кода как чёрного ящика Профилактика : Контроль функциональности, сложности Исключения : повторное использование в независимых продуктах, бранчинг
Серебряная пуля( Golden hammer) Характерные признаки : Склонность принимать одно и тоже решение в разных ситуациях Привязанность к инструменту, а не технологии Причины : профессиональное самолюбие, узкий кругозор Решение : расширение кругозора Профилактика : Управление технологиями Исключения : нет
Call super Singletonitis Характерные признаки  Call super : Вызов дочерними классами класса родителя, сосредоточение функциональности в родительском ( super)  классе. Приводит к сложной логике в последнем Характерные признаки  Singletonitis : Неоправданное применение паттерна  Singleton . Приводит к потере контроля над загрузкой/созданием отдельных объектов
Error hiding  / Exception handling Характерные признаки  Error Hiding : Скрытие ошибок посредством применения нулевых обработчиков событий. Последствия: функциональности системы падают молча, не оставляя шансов понять причины возникающих ошибок. Характерные признаки  Exception Handling : Использование исключительных ситуаций в логике программы. Последствия: снижение производительности, сложная и непонятная логика, неправильная обработка исключительных ситуаций
Магические числа/ Hard code Характерные признаки магических чисел : Применение недокументированных или непонятных числовых констант в коде Примеры: 0x4D546864 – так начинается  MIDI  файл Последствия: Непонятная логика кода Характерные признаки  Hard code : Жестко прописанный алгоритм, непредусматривающий кастомизацию. Последствия: Тяжело повторно использовать, требуется рефакторинг
Антипаттерны архитектуры Острова автоматизации Дымоход Vendor Lock-In Волчий билет Вторичная архитектура Design by Committee Швейцарский нож и Interface bloat Изобретение велосипеда Абстракционизм ( The Grand Old Duke of York ) Overengineering
Острова автоматизации Характерные признаки : Повторение функционала в разных модулях приложение Причины : лень Решение : Создание общей оснастки, обеспечение универсальных интерфейсов Профилактика : Контроль функциональности, управление технологиями
Острова автоматизации
Дымоход ( Stovepipe) Характерные признаки : Очень большая степень связности модулей  (N*N) Причины : профессиональное самолюбие, узкий кругозор Решение : расширение кругозора Профилактика : Управление модификациями
Vendor Lock-In Характерные признаки : Сильная зависимость от сторонних компонент Причины : узкий кругозор, недальновидность Решение : создание промежуточных слоёв  (wrapper) Профилактика : Управление технологиями Исключение : Долгосрочное стратегическое партнёрство
Волчий билет Характерные признаки : Приведение архитектуры к стандарту при неясности стратегических целей. Или стремление удовлетворять этим стандартам Причины : узкий кругозор, профессиональная влюблённость Решение : разработка архитектуры согласно целям проекта Профилактика : Управление технологиями
Design by Committee Характерные признаки : Архитектуру разрабатывает большой контингент специалистов Коллективная ответственность за архитектуру Причины : профессиональная влюблённость Решение : Выделение ответственностей в комитете Профилактика : Управление ресурсами Исключения : Комитет относительно небольшой и сплочённый
Антипаттерны менеджмента Минное поле Синдром морского корпуса Analysis Paralysis Дым и зеркала Графическое управление Смерть от планирования Трудный подросток  (Corncob) Снобизм ( Intellectual Violence ) Склочный коллектив (The Feud) Tester driven development
Путь камикадзе ( Death March Project) Нехватка времени более чем на 50% Нехватка ресурсов более чем на 50% Нехватка бюджета более чем на 50% Количество планируемого функционала больше чем на 50% (По Эду Йордану)
Минное поле Характерные признаки : Очень много дефектов в выпущенной версии продукта Причины : профессиональное самолюбие, спешка Решение : инвестирование в  QA Профилактика : контроль функциональности, производительности Исключения : нет
Синдром морского корпуса   ( Hero-mode) Характерные признаки : График проекта составляется с расчётам на сверхчеловеческие способности членов команды.  Причины : профессиональное самолюбие, спешка Решение : получение прагматических или даже пессимистических оценок, создание резервов Профилактика : Управление ресурсами Исключения : нет
Analysis Paralysis Характерные признаки : Излишний перфекционизм при обработке требований, разработки архитектуры и графика проекта.  Применение водопадной модели в мобильных (agile)  проектах Причины : профессиональное самолюбие, спешка Решение : разделение ролей при анализе требований и проектировании  Профилактика : Управление ресурсами, управление технологиями Исключения : нет
продолжение следует …
Полезные ссылки AntiPatterns (Refactoring Software, Architectures and Projects in Crisis) Scott J. Thomas, William J. Brown, Hays W. "Skip" McCormick, Raphael C. Malveau, Dr. Thomas J. Mowbray http://www.antipatterns.com/ http://en.wikipedia.org/wiki/AntiPatterns "Design Patterns : Elements of Reusable Object-Oriented Software" Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Death March : The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects by Edward Yourdon, Paul D. Becker (Editor)

More Related Content

PDF
Введение в профессию исследователя приложений без исходных кодов
PDF
10_tips_for_become_qa
PDF
Олексій Брошков "Мистецтво Дослідницького Тестування"
PDF
Разработка через ADD
PDF
Pandoras white box
PPTX
DaKiRY_BAQ2016_QADay_Круглий стіл: "Чи помре ручне тестування з часом" Учасни...
PPTX
Grammarly Test Club#2. Выступление Алексея Лупана (SysIQ, Inc.): "Без тест-ке...
PPT
Testing mistakes
Введение в профессию исследователя приложений без исходных кодов
10_tips_for_become_qa
Олексій Брошков "Мистецтво Дослідницького Тестування"
Разработка через ADD
Pandoras white box
DaKiRY_BAQ2016_QADay_Круглий стіл: "Чи помре ручне тестування з часом" Учасни...
Grammarly Test Club#2. Выступление Алексея Лупана (SysIQ, Inc.): "Без тест-ке...
Testing mistakes

What's hot (15)

PPTX
SWP'12. PMARCOR. Техногенные манипуляции
PPT
сергей андреев
PPTX
Требования по безопасности в архитектуре ПО
PDF
Обеспечение качества перевода
PPTX
Что общего у CTF и тестов на проникновение?
PDF
Андрей Уразов - Методы раннего обнаружения ошибок
PPTX
Severity и Priority для неначинающих: очевидное и невероятное
PDF
Ярослав Пернеровский (QA Factory/GlobalLogic):"Рукописи не горят, но и не тон...
PDF
Высоцкий Неортодоксальный дизайн тестов
PDF
Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
PPTX
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
PPTX
Дов Німрац “Що таке проблемний продукт і як з цим боротись?” Kharkiv Project ...
PDF
Метод No-Test-Cases: избавьтесь от тест-кейсов в тестировании
PDF
Требования по безопасности в архитектуре ПО
PDF
андрей дмитриев взгляд со стороны разработчика
SWP'12. PMARCOR. Техногенные манипуляции
сергей андреев
Требования по безопасности в архитектуре ПО
Обеспечение качества перевода
Что общего у CTF и тестов на проникновение?
Андрей Уразов - Методы раннего обнаружения ошибок
Severity и Priority для неначинающих: очевидное и невероятное
Ярослав Пернеровский (QA Factory/GlobalLogic):"Рукописи не горят, но и не тон...
Высоцкий Неортодоксальный дизайн тестов
Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...
Дов Німрац “Що таке проблемний продукт і як з цим боротись?” Kharkiv Project ...
Метод No-Test-Cases: избавьтесь от тест-кейсов в тестировании
Требования по безопасности в архитектуре ПО
андрей дмитриев взгляд со стороны разработчика
Ad

Viewers also liked (6)

PDF
ук 03.003.01 2011
PPT
Шаблоны разработки ПО. Часть 1. Введние
PPT
Шаблоны проектирования баз данных — Введение
PPT
Шаблонизируй это. Как паттерны требований облегчают жизнь аналитика
PPTX
Gof design patterns
ук 03.003.01 2011
Шаблоны разработки ПО. Часть 1. Введние
Шаблоны проектирования баз данных — Введение
Шаблонизируй это. Как паттерны требований облегчают жизнь аналитика
Gof design patterns
Ad

Similar to Antipatterns in software (ru) (20)

PPT
Щаблоны разработки ПО. Антипаттерны
PPTX
Практические аспекты разработки ПО #3
PPTX
Cемь смертных грехов в управлении проектами
PPT
Архитектура в Agile проекте
PPT
2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте
PPTX
Agile. Эвридики
PPTX
Agile мёртв (!|?) / Александр Сидоров (Яндекс)
PPT
Работа с требованиями в Agile
PDF
Проектирование программных систем. Занятие 6
PPTX
Представление знаний в технических системах
PDF
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
PPTX
ПиАПС, Лекция №1а - Роль архитектора, гибкая архитектура
PPT
Как поддерживать и развивать пачку "похожих" проектов. Кластер или конгломера...
PPTX
Agile Death March Projects: путь ниндзя
PDF
Design & Process Models
PDF
кривошеев евгений - как нужно уметь думать специалистам
PDF
Разработка веб-сервисов осень 2013 лекция 7
PDF
Проектирование больших ИС в Agile (статья)
PDF
Обзор Feature-Driven Development и Domain-Driven Design
PDF
Архитектура как функция от ?. Что мы не учитываем и убиваем проекты.
Щаблоны разработки ПО. Антипаттерны
Практические аспекты разработки ПО #3
Cемь смертных грехов в управлении проектами
Архитектура в Agile проекте
2013-04-06 01 Максим Юнусов. Архитектура в agile-проекте
Agile. Эвридики
Agile мёртв (!|?) / Александр Сидоров (Яндекс)
Работа с требованиями в Agile
Проектирование программных систем. Занятие 6
Представление знаний в технических системах
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
ПиАПС, Лекция №1а - Роль архитектора, гибкая архитектура
Как поддерживать и развивать пачку "похожих" проектов. Кластер или конгломера...
Agile Death March Projects: путь ниндзя
Design & Process Models
кривошеев евгений - как нужно уметь думать специалистам
Разработка веб-сервисов осень 2013 лекция 7
Проектирование больших ИС в Agile (статья)
Обзор Feature-Driven Development и Domain-Driven Design
Архитектура как функция от ?. Что мы не учитываем и убиваем проекты.

Antipatterns in software (ru)

  • 1. Анти-паттерн ы Чего в ИТ следует боятся ? Автор: Борис Лебеда
  • 2. Паттерн ы и антипаттерны Паттерн – типовое архитектурное решение характерн ых задач. Антипаттерн – часто принимаемое решение, которое приводит к негативным последствиям .
  • 3. Классификация антипаттернов Антипаттерны разработки Антипаттерны архитектуры Антипаттерны менеджмента
  • 4. Описание антипаттерна Характерные признаки Причины Решение Профилактика Исключения
  • 5. Базов ые причины неправильных решений в ИТ Поспешность Узкий кругозор Лень Недальновидность Профессиональное самолюбие Стремление к сложности
  • 6. Факторы успеха ИТ-проектов Контроль функциональности Контроль производительности Контроль сложности Контроль модификаций Управление ресурсами Управление технологиями Разработчики Архитекторы Менеджеры Топ менеджеры
  • 7. Антипаттерны разработки Макаронный код Blob ( God class) Застывшая лава Полтергейст Copy-Paste programming Серебряная пуля Минное поле Call super Singletonitis Error hiding Exception handling Магические числа Hard code
  • 8. Макаронный код ( Spaghetti code) Характерные признаки : Слабая архитектура: Методы зависимы от процесса в котором они принимают участие, чаще всего вызываются только в единственном случае Злоупотребление глобальными переменными, ограниченность сигнатур методов Как следствие: слабая возможность повторного использования кода Причины : Лень, Недальновидность Решение : Зачистка кода, рефакторинг Профилактика : Контроль сложности и изменений Исключения : wrapping внешнего сложного интерфейса
  • 9. Blob (God class) Характерные признаки : Реализация значительной части функциональности в одном классе при наличии нефункциональных классов сателитов. Раздутый интерфейс класса (нет ограничений в области видимости) Причины : Лень, Спешка Решение : делегирование функциональности сателитам. Защищённое программирование Профилактика : Контроль функциональности, производительности и сложности Исключения : нет. Всегда плохо
  • 11. Застывшая лава ( Lava flow) Характерные признаки : Наличие значительного количества недокументированного или рудиментарного кода. Связан с таким понятием как постоянное устаревание Причины : Профессиональное самолюбие, лень Решение : улучшение процесса разработки Профилактика : Контроль модификаций, технологий Исключения : разработка прототипов на выброс или временных утилит
  • 13. Полтергейст Характерные признаки : Класс связанный с соответствующим процессом. Причины : лень Решение : инкапсуляция «привидений» Профилактика : Контроль функциональности, сложности Исключения : нет ClassA ClassB
  • 14. Copy-Paste programming Характерные признаки : Наличие дупликаций кода Обнаружение похожих дефектов Возрастание числа строк кода Причины : лень Решение : практика использования кода как чёрного ящика Профилактика : Контроль функциональности, сложности Исключения : повторное использование в независимых продуктах, бранчинг
  • 15. Серебряная пуля( Golden hammer) Характерные признаки : Склонность принимать одно и тоже решение в разных ситуациях Привязанность к инструменту, а не технологии Причины : профессиональное самолюбие, узкий кругозор Решение : расширение кругозора Профилактика : Управление технологиями Исключения : нет
  • 16. Call super Singletonitis Характерные признаки Call super : Вызов дочерними классами класса родителя, сосредоточение функциональности в родительском ( super) классе. Приводит к сложной логике в последнем Характерные признаки Singletonitis : Неоправданное применение паттерна Singleton . Приводит к потере контроля над загрузкой/созданием отдельных объектов
  • 17. Error hiding / Exception handling Характерные признаки Error Hiding : Скрытие ошибок посредством применения нулевых обработчиков событий. Последствия: функциональности системы падают молча, не оставляя шансов понять причины возникающих ошибок. Характерные признаки Exception Handling : Использование исключительных ситуаций в логике программы. Последствия: снижение производительности, сложная и непонятная логика, неправильная обработка исключительных ситуаций
  • 18. Магические числа/ Hard code Характерные признаки магических чисел : Применение недокументированных или непонятных числовых констант в коде Примеры: 0x4D546864 – так начинается MIDI файл Последствия: Непонятная логика кода Характерные признаки Hard code : Жестко прописанный алгоритм, непредусматривающий кастомизацию. Последствия: Тяжело повторно использовать, требуется рефакторинг
  • 19. Антипаттерны архитектуры Острова автоматизации Дымоход Vendor Lock-In Волчий билет Вторичная архитектура Design by Committee Швейцарский нож и Interface bloat Изобретение велосипеда Абстракционизм ( The Grand Old Duke of York ) Overengineering
  • 20. Острова автоматизации Характерные признаки : Повторение функционала в разных модулях приложение Причины : лень Решение : Создание общей оснастки, обеспечение универсальных интерфейсов Профилактика : Контроль функциональности, управление технологиями
  • 22. Дымоход ( Stovepipe) Характерные признаки : Очень большая степень связности модулей (N*N) Причины : профессиональное самолюбие, узкий кругозор Решение : расширение кругозора Профилактика : Управление модификациями
  • 23. Vendor Lock-In Характерные признаки : Сильная зависимость от сторонних компонент Причины : узкий кругозор, недальновидность Решение : создание промежуточных слоёв (wrapper) Профилактика : Управление технологиями Исключение : Долгосрочное стратегическое партнёрство
  • 24. Волчий билет Характерные признаки : Приведение архитектуры к стандарту при неясности стратегических целей. Или стремление удовлетворять этим стандартам Причины : узкий кругозор, профессиональная влюблённость Решение : разработка архитектуры согласно целям проекта Профилактика : Управление технологиями
  • 25. Design by Committee Характерные признаки : Архитектуру разрабатывает большой контингент специалистов Коллективная ответственность за архитектуру Причины : профессиональная влюблённость Решение : Выделение ответственностей в комитете Профилактика : Управление ресурсами Исключения : Комитет относительно небольшой и сплочённый
  • 26. Антипаттерны менеджмента Минное поле Синдром морского корпуса Analysis Paralysis Дым и зеркала Графическое управление Смерть от планирования Трудный подросток (Corncob) Снобизм ( Intellectual Violence ) Склочный коллектив (The Feud) Tester driven development
  • 27. Путь камикадзе ( Death March Project) Нехватка времени более чем на 50% Нехватка ресурсов более чем на 50% Нехватка бюджета более чем на 50% Количество планируемого функционала больше чем на 50% (По Эду Йордану)
  • 28. Минное поле Характерные признаки : Очень много дефектов в выпущенной версии продукта Причины : профессиональное самолюбие, спешка Решение : инвестирование в QA Профилактика : контроль функциональности, производительности Исключения : нет
  • 29. Синдром морского корпуса ( Hero-mode) Характерные признаки : График проекта составляется с расчётам на сверхчеловеческие способности членов команды. Причины : профессиональное самолюбие, спешка Решение : получение прагматических или даже пессимистических оценок, создание резервов Профилактика : Управление ресурсами Исключения : нет
  • 30. Analysis Paralysis Характерные признаки : Излишний перфекционизм при обработке требований, разработки архитектуры и графика проекта. Применение водопадной модели в мобильных (agile) проектах Причины : профессиональное самолюбие, спешка Решение : разделение ролей при анализе требований и проектировании Профилактика : Управление ресурсами, управление технологиями Исключения : нет
  • 32. Полезные ссылки AntiPatterns (Refactoring Software, Architectures and Projects in Crisis) Scott J. Thomas, William J. Brown, Hays W. "Skip" McCormick, Raphael C. Malveau, Dr. Thomas J. Mowbray http://www.antipatterns.com/ http://en.wikipedia.org/wiki/AntiPatterns "Design Patterns : Elements of Reusable Object-Oriented Software" Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Death March : The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects by Edward Yourdon, Paul D. Becker (Editor)