Как инженерные практики помогают экономить бизнесу
Ребров Андрей
О чем этот доклад
Для кого этот доклад
Если вы…
• dev (qa, ops) и хотите что-то внедрить
• менеджер и вам постоянно что-то «впаривают»
• коуч/консультант и никак не можете объяснить, что команде нужно что-то внедрить
…то вы пришли по адресу!
Пришло время историй
История 1. Про Selenium • Есть классный фреймворк – Selenium!
Давайте его использовать у нас!
• У нас есть проработанная система на TestComplete.
• TestComplete - $#$&#!
• …
Don`t!
• Никогда не говори, что текущие наработки – ерунда
• Новизна технологии – не аргумент
• То, что технологию используют «вот эти ребята» не аргумент, даже если это Google
Как сработало
• Привлекай «ручных» тестировщиков на свою сторону – они твои заказчики
• Делай демо своих наработок как можно чаще – так ты покажешь, что фреймворк прост в использовании
• Во время демо создай позитивную обстановку – принеси чай и печеньки
• Тренируйся в обучении своему фреймворку
Как продали бизнесу
• Удешевляем разработку, так как быстрее находим баги
• Долгое время не понадобятся новые тестировщики – есть автотесты
• Можем брать больше задач в итерацию
• Можем быстрее выходить в релиз
Новые безопасны и дают преимущество
История 2. Про TDD • Ребята, вам нужно TDD – оно
рулит!
• Но нам придется переписать весь наш проект, чтобы можно было тестировать!!!
• Ну и что, зато у вас будут тесты!
• …
Don`t! • TDD ради тестов и TDD – самый
глупый аргумент
• TDD ради всеобщего блага – еще более глупый аргумент
• То, что TDD используют «вот эти ребята» - ну вы поняли…
Как сработало
• Просвещение в виде видео
• Личный пример – сделал, засек временя, не нашел багов, повторил
• Conding Dojo – пробовать что-то новое самому _ВСЕГДА_ страшно, лучше бояться вместе
Как продали бизнесу
Партизанский TDD:
• Применяем в течении 3-4 недель
• Показываем, что ситуация (метрики по SLA, баги, wtf/sec) улучшилась
• фиксируем договоренности
TDD позволяет писать код эффективно
История 3. Про Refactoring
• Давайте отрефакторим вон тот модуль!
• Зачем? Он же работает!
• Но там спагетти-код и масса нарушений в коде
• …
Don`t! • Когда ты говоришь о рефакторинге –
ты оскорбляешь чей-то код, будь готов к сопротивлению
• Переписать, потому что так написано в книге – очередной глупый аргумент
• Сразу говорю, убеждать, что на рефакторинг нужен сразу месяц не стоит
Как сработало
• Визуализация проблем – поставь Sonar, менеджеров пугают цифры
• Рассказать про технический долг и как он влияет в перспективе
• Подготовить план рефакторинга с объяснением почему в определенный момент времени мы переделываем именно этот код
Как продали бизнесу • Показать график
• Рассказать, что делают с должниками =)
Рефакторинг позволяет не бояться долгов
История 4. Про автоматизацию
• Дима, давай автоматизируем тестирование!
• И зачем нам это?
• Ну, мы сможем заниматься интересными задачами и будет круто!
• …
Don`t! • Автоматизация ради автоматизации – как
TDD ради TDD, а это мы уже прошли
• Не говори, что автоматизация ничего не стоит – будешь выглядеть дураком
• Запомни! Не бывает бесплатных инструментов, как минимум они стоят твое рабочее время
• Не стоит бежать к лиду, как только прочитал про инструмент, попробуй сам
Как сработало
• Показать концепт как оно работает
• Знать о преимуществах и недостатках
• Показать, разные варианты использования – чем больше выбор, тем больше вероятность, что хоть один подойдет
Как продали бизнесу
• Посчитать ROI автоматизации
• Показать, что поддержка стоит дешевле, чем отдельный человек, который будет делать все вручную
• Показать стоимость ОШИБКИ, которую может допустить такой человек
Хорошие роботы спасут в беде
История 5. Про Feature Toggling и ветки
• Нужно перестать делать ветки под каждую новую ветку!
• Почему?
• Так завещал Martin Fowler!
• …
Don`t! • Не все знают, кто такой Фаулер =)
• Прочти Фаулера сначала сам
• Не стоит кидаться терминами cherry pick, feature branch и так далее – вы будете выглядеть как колдун вуду
• Говорить, что «feature toggle это как if, но не if, а по другому» тоже не стоит
Как сработало
• Экономим время на merge`ах веток – теперь их нет
• У всех разработчиков всегда последний код – все видят картину целиком
• В разы проще становится настройка Continuous Integration (о нем ниже)
Как продали бизнесу
• Теперь в любой момент мы можем выключить тот или иной элемент функционала – у нас есть набор конфигов для этого
Не плодим сущностей без необходимости
История 6. Про Continuous Integration
• Нам срочно нужен Continuous Integration, чтобы мы знали, что ничего не сломали!
• А почему ты не проверяешь на своем компьютере?
• А зачем?
• …
Don`t!
• Никогда, еще раз, никогда не говорите, что CI будет находить ваши ошибки – вы выставляете себя в плохом свете
• CI не просто штука, которая запускает тесты – если ваш менеджер технарь, ему не стоит такое говорить
Как сработало • CI позволяет делать регрессионное
тестирование на уровне кода – снимаем нагрузку с тестировщиков
• Можем автоматизировать наши процессы (см. пункт 4)
• Не требует поддержки
Как продали бизнесу
• Так же, как автоматизацию
• Сказали, что это путь к непрерывной поставке (будет дальше)
CI заботится о стабильности в коде
История 7. Про DevOps
• Давайте настроим Nagios, Chef, Graphite и Logstash и станем DevOps`ами!
• А как это поможет?
• Ну мы просто будем делать все быстрее
• …
Don`t!
• Не продавай инструменты – проблему процессов ими не решишь, а фейл за тобой останется
• Построение DevOps процесс долгий – не говори, что за неделю все станет здорово
• Не решай проблему админов за них самих – они обидятся
Как сработало
• Визуализация процесса – все увидят, что творится что-то не ладное и появляется поддержка всей команды
• «Затуши пожар» в течении недели - быстрая победа добавляет очков
• Как обычно, показать прототипы не помешает
Как продали бизнесу
• Процесс поставки становится прозрачным и управляемым
• Поставка делается за пару часов, а не дней
• Мы не потеряем данные пользователей
• Мы сможем стать «фабрикой по производству фич»
DevOps позволяет нам быть первыми на рынке
В качестве эпилога