XP практики в проектах с тяжелой наследственностью
Upcoming SlideShare
Loading in...5
×
 

XP практики в проектах с тяжелой наследственностью

on

  • 2,622 views

Олег Клименко, разработчик, компания Sigma Ukraine

Олег Клименко, разработчик, компания Sigma Ukraine

Statistics

Views

Total Views
2,622
Views on SlideShare
521
Embed Views
2,101

Actions

Likes
1
Downloads
0
Comments
0

10 Embeds 2,101

http://odjug.blogspot.com 2012
http://odjug.blogspot.ru 53
http://odjug.blogspot.nl 18
http://odjug.blogspot.de 5
http://translate.googleusercontent.com 4
http://odjug.blogspot.in 3
http://odjug.blogspot.cz 2
http://odjug.blogspot.co.il 2
http://odjug.blogspot.co.at 1
http://odjug.blogspot.com.au 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Отсутствие прозрачных процедур сборки и установкиНе структурированный кодОтсутсвие тестов, как следствие не тестируемый код
  • 1. билд в один клик2. деплой в один клик3. тест-тим строит и деплоит IR
  • Разработчик не ведает что творит (только вот эта маленькая фича и она ничего не сломает)
  • Но иногда ведаем что творим, но приходится идти осознано
  • Что именно делает код — не важно. Для тестирования важно только как код структурирован.
  • Что именно делает код — не важно. Для тестирования важно только как код структурирован.
  • Что именно делает код — не важно. Для тестирования важно только как код структурирован.
  • Что именно делает код — не важно. Для тестирования важно только как код структурирован.
  • 1. Unit тестирование без модулей2. Интеграционное когда нечего интегрировать3. Не возможно рефакторить без тестов4. Системные тесты дают нам уверенность
  • 1. Системные тесты сложны в поддержке2. Выполняются долго и редко3. Переворачиваем пирамиду

XP практики в проектах с тяжелой наследственностью XP практики в проектах с тяжелой наследственностью Presentation Transcript

  • XP практики в проектахс тяжелой наследственностью Oleg Klymenko Java Developer @ Sigma Ukraine oklym@meta.ua
  • Начало
  • Развитие
  • Agile-манифест разработки программного обеспечения Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования контрактаГотовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всѐ таки больше ценим то, что слева. Идея
  • Процесс
  • Ожидание
  • Реальность
  • Демотивация
  • Первый шаг
  • Анализ1. Страсть (избыток проектирования)2. Чревоугодие (неспособность к рефакторингу)3. Жадность (соревнование между командами разработки)4. Лень (отсутствие проверки входных данных)5. Гнев (отсутствие практики комментировать код)6. Зависть (не использование систем управления версиями)7. Гордость (отсутствие юнит-тестирования) Neil McAllister8. Оптимизм9.10.
  • Новая фича
  • Новая фича
  • Тест разработчика
  • $ Вызов DT
  • 1. Я пишу пользовательский интерфес2. Трудно сопровождать3. Они не ловят новые “баги”4. Они медленные5. Это скучно6. Это дело тест-тима7. У меня легаси код8. Мне нужно делать фичи9. Отговорки
  • public class Validator { private static Validator instance = new Validator(FeatureFactory.get()); private Subscription subscr; private final Player player; public static Validator getInstance() {return instance;} private Validator(FeatureFactory ff) { player = ff.getPlayer(); if (player instanceof GamePlayer) subscr = ff.findSubscription(player); } public boolean check(Round round) { SyncService sync = Repository.lookup(SyncService.class); boolean result = false; Date time = new Date(); if(!round.isActiveInTime(time)) { try { sync.lock(round); Ticket ticket = new SubscriptionTicket(subscr); result = round.subscribe(ticket, player); } finally { sync.unlock(round); } } return result; }}
  • public class Validator { private static Validator instance = new Validator(FeatureFactory.get()); private Subscription subscr; private final Player player; public static Validator getInstance() {return instance;} private Validator(FeatureFactory ff) { player = ff.getPlayer(); if (player instanceof GamePlayer) subscr = ff.findSubscription(player); } public boolean check(Round round) { SyncService sync = Repository.lookup(SyncService.class); boolean result = false; Date time = new Date(); if(!round.isActiveInTime(time)) { try { sync.lock(round); Ticket ticket = new SubscriptionTicket(subscr); result = round.subscribe(ticket, player); } finally { sync.unlock(round); } } return result; }}
  • public class V { private static V instance = new V(FF.get()); private S s; private final P p; public static V getInstance() {return instance;} private V(FF ff) { p = ff.getP(); if (player instanceof GamePlayer) s = ff.findS(player); } public boolean do(R r) { SS sync = Repository.lookup(SS.class); boolean result = false; Date time = new Date(); if(!round.timeDependentRoutine(time)) { try { sync.lock(round); T t = new ST(s); result = round.s(t, player); } finally { sync.unlock(round); } } return result; }}
  • public class Validator { private final Subscription subscr; private final Player player; private final SyncService sync; public Validator(Player player, Subscription subscr, SyncService sync) { this.player = player; this.subscr = subscr; this.sync = sync; } public boolean check(Round round, Date time) { boolean result = false; if(!round.isActiveInTime(time)) { try { sync.lock(round); Ticket ticket = new SubscriptionTicket(subscr); result = round.subscribe(ticket, player); } finally { sync.unlock(round); } } return result; }}
  • 1. Смешивание инстанциирования с логикой2. Смешивание патерна Lookup с логикой3. Выполнение целевой логики в конструкторе4. Глобальная видимость полей класса5. Использование патерна Singleton6. Статические методы7. Глубокая иерархия наследования8. Смешивание сервисов с общей логикой Антипатерн
  • 1. Сбалансированный ООП дизайн. 2. Внедрение внешних зависимостей (DI). 3. Отслеживание ошибок смешивания логики. 4. Соблюдение закона Деметры. 5. Юнит тесты (TDD).Тестируемость
  • НормаСистемные тестыФункциональные и интеграционные тестыUnit тесты
  • Переворот
  • Время
  • Человеческий фактор
  • Архитектура и Дизайн Комментарии Дублирование Исходный кода Стандарты код кодирования Юнит тесты Потенциальные Сложность ошибкиКонтроль
  • Итоговый план1. Налаживаем сборку/инсталяцию.2. Определяем поведенческие требования.3. Создаем покрытие функциональными тестами.4. Выполняем рефакторинг.5. Покрываем юнит тестами.6. Налаживаем инспекцию кода.7. Убираем излишние функциональные тесты.8. Оставляем мир лучше чем был до нас :)
  • Пять минут...
  • 1. Miško Hevery. Writing Testable Code http://misko.hevery.com/code-reviewers-guide/2. Wiktor Żołnowski. Reversed Tests Pyramid http://xpdays.com.ua/materials/legacy-code/3. Neil McAllister. 7 deadly sins of software development http://gigaom.com/2012/06/02/the-7-deadly-sins-of-software-development/