Рубрика «Блог компании QIWI» - 2

Предлагаем вам перевод поста «Unit Testing is Overrated» от Alex Golub, чтобы подискутировать на тему юнит-тестов. Действительно ли они переоценены, как считает автор, или же являются отличным подспорьем в работе? Опрос — в конце поста

Юнит-тесты переоценены - 1


Результаты использования юнит-тестов: отчаяние, мучения, гнев

Важность тестирования в современной разработке ПО сложно переоценить. Для создания успешного продукта недостаточно выпустить его и сразу забыть, это долгий итеративный процесс. После изменения каждой строки кода программа должна сохранять свою функциональность, что подразумевает необходимость тщательного тестирования.

В процессе развития отрасли разработки ПО совершенствовались и методики тестирования. Они постепенно сдвигались в сторону автоматизации и повлияли на саму структуру ПО, порождая такие «мантры», как «разработка через тестирование» (test-driven development), делая упор на такие паттерны, как инверсия зависимостей (dependency inversion), и популяризируя построенные на их основе высокоуровневые архитектуры.

Сегодня автоматизированное тестирование настолько глубоко связано в нашем сознании с разработкой ПО, что одно сложно представить без другого. И поскольку оно, в конечном итоге, позволяет нам быстро создавать ПО, не жертвуя при этом его качеством, то трудно спорить о полезности тестирования.

Однако, несмотря на существование различных подходов, современные «best practices» в основном подталкивают разработчиков к использованию конкретно юнит-тестирования. Тесты, область контроля которых находится в пирамиде Майка Кона выше, или пишутся как часть более масштабного проекта (часто совершенно другими людьми), или полностью игнорируются.

Преимущество такого подхода часть поддерживается следующим аргументом: юнит-тесты обеспечивают в процессе разработки наибольшую полезность, потому что способны быстро отслеживать ошибки и помогают применять упрощающие модульность паттерны разработки. Читать полностью »

Привет!

Пару недель назад мы бодренько перевелись на удаленку. Как и большинство из вас.

Главные сложности были в самые первые дни, когда в срочном режиме надо было быстро организовать удаленные рабочие места для многих пользователей. На сегодня у нас онлайн (читай «работают удалённо и в сети») в среднем 1100 пользователей. До всеобщего перехода на удаленку это число редко превышало 400.

Третья неделя удалёнки — полёт нормальный. Отзывы ребят из IT QIWI о полноценной работе из дома - 1

Мы собрали реальные отзывы наших сотрудников о работе в условиях удаленки, дабы узнать плюсы и минусы и сделать выводы. Для чистоты эксперимента обратная связь собиралась анонимно. Мнения сисадминов, ведущих разработчиков, QA и остальных — под катом. Вместе с опросом.
Читать полностью »

Привет!

Через 2 недели, 5 марта, мы проведем нашу новую QIWI Кухню.

Новая QIWI Кухня — уже 5 марта. Москва, AGLOFT - 1.
Как это было в 2019

В этот раз собираемся в AGLOFT, это м. Тульская, Варшавское шоссе, 33с3. Вход бесплатный, но регистрироваться лучше заранее (регистрация закрывается 29 февраля). Сделать это можно по ссылке.

Говорить будем о разном: о дизайне в целом и о том, как и зачем научить дизайну разработчика, как проводить встречи продуктивно, а не как всегда, про нетворкинг и HR. Собственно, мы даже в этот раз специально разделим пространство на 4 секции, чтобы вы могли выбрать нужные и интересные для вас темы. Вот как это будет.
Читать полностью »

Привет!

Сегодня поговорим на специфическую тему: автоматизация тестирования ПО для терминалов самообслуживания QIWI.

В теме автоматизации тестирования есть области, которые исхожены вдоль и поперек несколько раз, например, тестирование веб-сервисов. Для таких областей существуют отдельные инструменты, паттерны и best practices. Выдумывать ничего не нужно, риски минимальны, берешь и делаешь.

Бывают и обратные ситуации. Предметная область специфична, подглядеть готовые решения не у кого, инструментов нет, технологический стек продукта своеобразен. Приходится глубоко погружаться в предметную область, из палок и эээ… других подручных материалов мастерить себе инструменты и попутно собирать много-много грабель разной величины и убойной силы.

Вот о чем-то таком и хотелось рассказать сегодня. Статья подойдет тем, кто занимается разработкой и тестированием софта для банковских терминалов или автоматов самообслуживания. А также тем, кто хочет расширить свой технический кругозор примерами «а еще бывает вот так».

Автоматизация тестирования ПО QIWI-терминалов - 1
QIWI-терминал в 2020. На заднем фоне можно увидеть его начинку.
Читать полностью »

Привет.

Меня зовут Миша Бутримов, я хотел бы хотел немного рассказать про Cassandra. Мой рассказ будет полезен тем, кто никогда не сталкивался с NoSQL-базами, — у нее есть очень много особенностей реализации и подводных камней, про которые нужно знать. И если кроме Oracle или любой другой реляционной базы вы ничего не видели, эти вещи спасут вам жизнь.

Чем хороша Cassandra? Это NoSQL-база данных, cпроектированная без единой точки отказа, которая хорошо масштабируется. Если вам нужно добавить пару терабайт для какой-нибудь базы, вы просто добавляете ноды в кольцо. Расширить ее на еще один дата-центр? Добавляете ноды в кластер. Увеличить обрабатываемый RPS? Добавляете ноды в кластер. В обратную сторону тоже работает.

Cassandra. Как не умереть, если знаешь только Oracle - 1

В чем еще она хороша? В том, чтобы обрабатывать много запросов. Но много — это сколько? 10, 20, 30, 40 тысяч запросов в секунду — это немного. 100 тысяч запросов в секунду на запись — тоже. Есть компании, которые говорили, что они держат 2 млн. запросов в секунду. Вот им, наверное, придется поверить.

И в принципе у Cassandra есть одно большое отличие от реляционных данных — она вообще на них не похожа. И об этом очень важно помнить.
Читать полностью »

Привет! Меня зовут Паша Черняк, я ведущий разработчик в QIWI, и сегодня я хочу поговорить о неизбежном. О Legacy.

Начнем с вопроса: что такое Legacy-сервис? Legacy-сервис — это сервис, которого разработчик не касался уже неделю/месяц/год? Или это сервис, который был написан менее опытным программистом, например, конкретно вами, но год назад? А теперь-то вы круче и опытнее. Или все-таки, Legacy-сервис — это сервис, который вы решили никогда больше не коммитить и потихоньку готовите ему замену? В любом случае, оставлять такой сервис без присмотра и не обновлять — это бомба замедленного действия, которая может взорваться попозже.

Legacy-сервисы в вашей инфраструктуре - 1

Прежде чем переходить к тому, как мы в QIWI работаем с нашими Legacy-сервисами, я расскажу, как мы навели порядок с сервисами в Кошельке. Вот уже два года я отвечаю за его работоспособность. Если есть какая-то проблема, то всегда в первую очередь звонят мне. Мне обычно не хватает наглости в 11 часов вечера позвонить кому-то еще, поэтому приходилось садиться и разбираться во всех сервисах нашего домена.

Но я, как и любой человек, люблю спать по ночам, поэтому пытался разобраться с эксплуатацией: «Ребята, а почему вы мне звоните?». На что получил вполне лаконичный ответ вида «А кому еще?». Потому что я сервисы чиню, а еще ребята банально не знают, кому звонить.

Поэтому на одной из ретроспектив команды бекэнда Кошелька мы решили, что нужно составить табличку, на которой написан список наших сервисов, микросервисов и монолитов кошелька, и ответственных за них. Таблички это вообще полезно, в разумных пределах.
Читать полностью »

Изначально весь проект был написан на Objective-C и использовал ReactiveCocoa версии 2.0

Взаимодействие между View и ViewModel осуществлялось посредствам биндингов свойств вью модели, и все бы ничего, за исключением того, что отладкой такого кода заниматься было очень сложно. Все из-за отсутствия типизации и каши в стек-трейсе :(

И вот настало время использовать Swift. Поначалу мы решили попробовать вообще без реактивщины. Читать полностью »

Служба поддержки — это то место, в которое пользователи обращаются, чтобы помочь вам создать лучший продукт. Конечно, в том случае, если вы готовы их слушать. Ежемесячно нам поступает более 175 000 обращений в поддержку, что можно сравнить с населением целого Петропавловска-Камчатского.

Естественно, хочется снизить эту цифру, так как продукт с идеальным пользовательским опытом не нуждается в поддержке. Кроме того, отдельной статьей расходов компании является содержание нескольких колл-центров, каждый звонок обходится в определенную сумму. Анализ этих проблем может стать серьезной базой для наполнения продуктового беклога задачами улучшения процессов, функциональной логики и внедрения новых фич.

Летом 2018 команда QIWI Кошелька — разработчики, тестировщики, дизайнеры — разделилась на две группы и отправилась в колл-центры Калуги и Челябинска для того, чтобы узнать, с какими проблемами сталкиваются наши пользователи. Проводя аналогию, можно сказать, что прямой контакт команды разработки с пользователем это не тушение горящего пожара, это создание системы пожарной безопасности.

Поездка в call-центр и Product Backlog глазами разработчика - 1
На работу в поля
Жюль Бретон

Под катом я коротко расскажу о том, как это было, и почему полезно выбираться из офиса и смотреть, как твоим продуктом пользуются люди.
Читать полностью »

Большие компании частенько печалятся от проблемы адаптируемости и маневренности. Точнее, почти от полного отсутствия и того, и другого.

Представьте: все платформенные команды заняты одной фичей, а у бизнеса появляется срочное требование сделать что-то другое или скорректировать уже разрабатываемый функционал. И в этот момент останавливается работа над одной фичей и начинается работа над другой. В следующий момент появляются уже новые требования от бизнеса, а фича так и остается недоделанной. Разработчики в обиде и бизнес страдает.

От монолитов к модульности команд - 1

Вот еще ситуация: меняется API, нужно срочно бежать в отдел бэкенда узнавать подробности, потом обратно к фронтам (iOS / Android / web). Дальше, обсудив с фронтами свои корректировки, нужно идти обратно к бэку и говорить наши требования. Это очень изнуряло, терялось время команд, отдельного разработчика и нервы всех заинтересованных людей.

Меня зовут Валерий, наша команда занималась QIWI Кошельком под iOS. Но всегда нужно было держать коммуникации с другими командами, иначе получался полный рассинхрон. Что касается наших неудобств, то бизнес всегда идет навстречу и дает свободу для экспериментов. Поэтому встал вопрос об изменении существующей структуры. Благоприятной средой для тестирования наших идей по изменению был скрам. Каждые две недели мы внутри платформы могли редактировать курс, чтобы это хоть как-то согласовывалось с другими командами. На проверку теорий давалось много времени. От месяца до полугода. Какие варианты мы перепробовали:
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js