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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

2,378

Published on

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

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,378
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
1
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/

    ×