Slideshare.net (beta)

 
Post: 
Myspace Hi5 Friendster Xanga LiveJournal Facebook Blogger Tagged Typepad Freewebs BlackPlanet gigya icons

All comments

Add a comment on Slide 1

If you have a SlideShare account, login to comment; else you can comment as a guest


Showing 1-50 of 0 (more)

Antipatterns in software (ru)

From borys, 1 month ago

My presentation about antipatterns in summer 2007 accordingly to S more

68 views  |  0 comments  |  0 favorites  |  1 download
 

Tags

No tags to display

 
 

Groups/Events

Not added to any group/event

 
 

Privacy InfoNew!

This slideshow is Public

 
Embed in your blog
Embed (wordpress.com)

Slideshow Statistics
Total Views: 68
on Slideshare: 68
from embeds: 0* * Views from embeds since 21 Aug, 07

Slideshow transcript

Slide 1: Анти-паттерны Чего в ИТ следует боятся? Автор: Борис Лебеда

Slide 2: Паттерны и антипаттерны Паттерн – типовое архитектурное решение характерных задач. Антипаттерн – часто принимаемое решение, которое приводит к негативным последствиям.

Slide 3: Классификация антипаттернов  Антипаттерны разработки  Антипаттерны архитектуры  Антипаттерны менеджмента

Slide 4: Описание антипаттерна Характерные признаки Причины Решение Профилактика Исключения

Slide 5: Базовые причины неправильных решений в ИТ  Поспешность  Узкий кругозор  Лень  Недальновидность  Профессиональное самолюбие  Стремление к сложности

Slide 6: Факторы успеха ИТ-проектов  Контроль функциональности  Контроль производительности  Контроль сложности  Контроль модификаций  Управление ресурсами  Управление технологиями

Slide 7: Антипаттерны разработки Макаронный код Blob (God class) Застывшая лава Полтергейст Copy-Paste programming Серебряная пуля Минное поле Call super Singletonitis Error hiding Exception handling Магические числа Hard code

Slide 8: Макаронный код (Spaghetti code) Характерные признаки: Причины: Слабая архитектура: Методы Лень, Недальновидность зависимы от процесса в котором они принимают Решение: участие, чаще всего вызываются только в Зачистка кода, рефакторинг единственном случае Злоупотребление глобальными Профилактика: переменными, Контроль сложности и ограниченность сигнатур изменений методов Как следствие: слабая Исключения: возможность повторного использования кода wrapping внешнего сложного интерфейса

Slide 9: Blob (God class) Характерные признаки: Причины: Реализация значительной Лень, Спешка части функциональности в одном классе при наличии Решение: нефункциональных классов сателитов. делегирование Раздутый интерфейс класса функциональности (нет ограничений в области сателитам. Защищённое видимости) программирование Профилактика: Контроль функциональности, производительности и сложности Исключения: нет. Всегда плохо

Slide 10: Blob (God class)

Slide 11: Застывшая лава (Lava flow) Характерные признаки: Причины: Наличие значительного количества Профессиональное недокументированного или рудиментарного кода. самолюбие, лень Связан с таким понятием как постоянное устаревание Решение: улучшение процесса разработки Профилактика: Контроль модификаций, технологий Исключения: разработка прототипов на выброс или временных утилит

Slide 12: Застывшая лава (Lava flow)

Slide 13: Полтергейст Характерные признаки: Причины: Класс связанный с лень соответствующим процессом. Решение: инкапсуляция ClassA ClassB «привидений» Профилактика: Контроль функциональности, сложности Исключения: нет

Slide 14: Copy-Paste programming Характерные признаки: Причины: Наличие дупликаций кода лень Обнаружение похожих дефектов Возрастание числа строк кода Решение: практика использования кода как чёрного ящика Профилактика: Контроль функциональности, сложности Исключения: повторное использование в независимых продуктах, бранчинг

Slide 15: Серебряная пуля(Golden hammer) Характерные признаки: Причины: Склонность принимать одно и тоже профессиональное решение в разных ситуациях Привязанность к инструменту, а не самолюбие, узкий технологии кругозор Решение: расширение кругозора Профилактика: Управление технологиями Исключения: нет

Slide 16: Call super Singletonitis Характерные признаки Call Характерные признаки super: Singletonitis: Вызов дочерними классами Неоправданное применение класса родителя, паттерна Singleton. сосредоточение Приводит к потере контроля функциональности в над загрузкой/созданием родительском (super) классе. отдельных объектов Приводит к сложной логике в последнем

Slide 17: Error hiding / Exception handling Характерные признаки Error Характерные признаки Hiding: Exception Handling: Скрытие ошибок посредством Использование применения нулевых исключительных ситуаций в обработчиков событий. логике программы. Последствия: Последствия: функциональности системы снижение падают молча, не оставляя производительности, шансов понять причины сложная и непонятная возникающих ошибок. логика, неправильная обработка исключительных ситуаций

Slide 18: Магические числа/Hard code Характерные признаки Характерные признаки Hard магических чисел: code: Применение Жестко прописанный алгоритм, недокументированных или непредусматривающий непонятных числовых кастомизацию. констант в коде Последствия: Примеры: Тяжело повторно 0x4D546864 – так использовать, требуется рефакторинг начинается MIDI файл Последствия: Непонятная логика кода

Slide 19: Антипаттерны архитектуры Острова автоматизации Дымоход Vendor Lock-In Волчий билет Вторичная архитектура Design by Committee Швейцарский нож и Interface bloat Изобретение велосипеда Абстракционизм (The Grand Old Duke of York) Overengineering

Slide 20: Острова автоматизации Характерные признаки: Причины: Повторение функционала в разных лень модулях приложение Решение: Создание общей оснастки, обеспечение универсальных интерфейсов Профилактика: Контроль функциональности, управление технологиями

Slide 21: Острова автоматизации

Slide 22: Дымоход (Stovepipe) Характерные признаки: Причины: Очень большая степень профессиональное связности модулей самолюбие, узкий кругозор (N*N) Решение: расширение кругозора Профилактика: Управление модификациями

Slide 23: Vendor Lock-In Характерные признаки: Причины: Сильная зависимость от узкий кругозор, сторонних компонент недальновидность Решение: создание промежуточных слоёв (wrapper) Профилактика: Управление технологиями Исключение: Долгосрочное стратегическое партнёрство

Slide 24: Волчий билет Характерные признаки: Причины: Приведение архитектуры узкий кругозор, к стандарту при профессиональная влюблённость неясности стратегических целей. Решение: Или стремление разработка архитектуры удовлетворять этим согласно целям проекта стандартам Профилактика: Управление технологиями

Slide 25: Design by Committee Характерные признаки: Причины: Архитектуру разрабатывает профессиональная большой контингент влюблённость специалистов Решение: Коллективная ответственность за Выделение ответственностей в комитете архитектуру Профилактика: Управление ресурсами Исключения: Комитет относительно небольшой и сплочённый

Slide 26: Антипаттерны менеджмента Минное поле Синдром морского корпуса Analysis Paralysis Дым и зеркала Графическое управление Смерть от планирования Трудный подросток (Corncob) Снобизм (Intellectual Violence) Склочный коллектив (The Feud) Tester driven development

Slide 27: Путь камикадзе (Death March Project)  Нехватка времени более чем на 50%  Нехватка ресурсов более чем на 50%  Нехватка бюджета более чем на 50%  Количество планируемого функционала больше чем на 50% (По Эду Йордану)

Slide 28: Минное поле Характерные признаки: Причины: Очень много дефектов в профессиональное выпущенной версии продукта самолюбие, спешка Решение: инвестирование в QA Профилактика: контроль функциональности, производительности Исключения: нет

Slide 29: Синдром морского корпуса (Hero-mode) Характерные признаки: Причины: График проекта профессиональное самолюбие, спешка составляется с расчётам на сверхчеловеческие Решение: способности членов получение прагматических команды. или даже пессимистических оценок, создание резервов Профилактика: Управление ресурсами Исключения: нет

Slide 30: Analysis Paralysis Характерные признаки: Причины: Излишний перфекционизм профессиональное самолюбие, спешка при обработке требований, разработки архитектуры и графика Решение: проекта. разделение ролей при анализе требований и Применение водопадной проектировании модели в мобильных(agile) проектах Профилактика: Управление ресурсами, управление технологиями Исключения: нет

Slide 31: продолжение следует …

Slide 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)