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

  • 2,305 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,305
On Slideshare
0
From Embeds
0
Number of Embeds
11

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Отсутствие прозрачных процедур сборки и установкиНе структурированный кодОтсутсвие тестов, как следствие не тестируемый код
  • 1. билд в один клик2. деплой в один клик3. тест-тим строит и деплоит IR
  • Разработчик не ведает что творит (только вот эта маленькая фича и она ничего не сломает)
  • Но иногда ведаем что творим, но приходится идти осознано
  • Что именно делает код — не важно. Для тестирования важно только как код структурирован.
  • Что именно делает код — не важно. Для тестирования важно только как код структурирован.
  • Что именно делает код — не важно. Для тестирования важно только как код структурирован.
  • Что именно делает код — не важно. Для тестирования важно только как код структурирован.
  • 1. Unit тестирование без модулей2. Интеграционное когда нечего интегрировать3. Не возможно рефакторить без тестов4. Системные тесты дают нам уверенность
  • 1. Системные тесты сложны в поддержке2. Выполняются долго и редко3. Переворачиваем пирамиду

Transcript

  • 1. XP практики в проектахс тяжелой наследственностью Oleg Klymenko Java Developer @ Sigma Ukraine oklym@meta.ua
  • 2. Начало
  • 3. Развитие
  • 4. Agile-манифест разработки программного обеспечения Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования контрактаГотовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всѐ таки больше ценим то, что слева. Идея
  • 5. Процесс
  • 6. Ожидание
  • 7. Реальность
  • 8. Демотивация
  • 9. Первый шаг
  • 10. Анализ1. Страсть (избыток проектирования)2. Чревоугодие (неспособность к рефакторингу)3. Жадность (соревнование между командами разработки)4. Лень (отсутствие проверки входных данных)5. Гнев (отсутствие практики комментировать код)6. Зависть (не использование систем управления версиями)7. Гордость (отсутствие юнит-тестирования) Neil McAllister8. Оптимизм9.10.
  • 11. Новая фича
  • 12. Новая фича
  • 13. Тест разработчика
  • 14. $ Вызов DT
  • 15. 1. Я пишу пользовательский интерфес2. Трудно сопровождать3. Они не ловят новые “баги”4. Они медленные5. Это скучно6. Это дело тест-тима7. У меня легаси код8. Мне нужно делать фичи9. Отговорки
  • 16. 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; }}
  • 17. 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; }}
  • 18. 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; }}
  • 19. 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; }}
  • 20. 1. Смешивание инстанциирования с логикой2. Смешивание патерна Lookup с логикой3. Выполнение целевой логики в конструкторе4. Глобальная видимость полей класса5. Использование патерна Singleton6. Статические методы7. Глубокая иерархия наследования8. Смешивание сервисов с общей логикой Антипатерн
  • 21. 1. Сбалансированный ООП дизайн. 2. Внедрение внешних зависимостей (DI). 3. Отслеживание ошибок смешивания логики. 4. Соблюдение закона Деметры. 5. Юнит тесты (TDD).Тестируемость
  • 22. НормаСистемные тестыФункциональные и интеграционные тестыUnit тесты
  • 23. Переворот
  • 24. Время
  • 25. Человеческий фактор
  • 26. Архитектура и Дизайн Комментарии Дублирование Исходный кода Стандарты код кодирования Юнит тесты Потенциальные Сложность ошибкиКонтроль
  • 27. Итоговый план1. Налаживаем сборку/инсталяцию.2. Определяем поведенческие требования.3. Создаем покрытие функциональными тестами.4. Выполняем рефакторинг.5. Покрываем юнит тестами.6. Налаживаем инспекцию кода.7. Убираем излишние функциональные тесты.8. Оставляем мир лучше чем был до нас :)
  • 28. Пять минут...
  • 29. 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/