Привет! Продолжаем цикл постов про чистый код по мотивам видеолекций Дяди Боба, первая часть тут. В этом посте поговорим про структуру функций и не только.

Передача булевых аргументов

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

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

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

Дядя Боб считает, что единственный способ быстро двигаться в разработке — делать хорошо, поэтому чистота кода очень важна. 

Всем привет! Меня зовут Ольга Болотова, и я Developer Advocate в QIWI. Сейчас я представляю интересы разработчиков, но до этого я была фронтенд-разработчицей, и пять лет работала с новичками, стажёрами и их наставниками. А потом на позиции руководительницы запустила программу стажировок во фронтенд-направлении в моей прошлой компании.

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

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

Эти сертификаты имеют срок годности, они выпускаются не на 100 лет (технически это возможно, но по понятным причинам вариант не пользуется популярностью), а обычно на год. И частенько они просрочиваются – срок сертификата подходит к концу, об этом забывают и пропускают его смену, что приводит к потере денег или времени. Боль, на самом деле, повсеместная, и немногие пытаются успешно с ней бороться. У нас это получилось, и мы хотим поведать вам о нашем пути, который еще не закончен.

Привет! В одном из недавних постов ребята из Додо разбирали устройство интернет‑платежей и в самом конце текста задались десятком вопросов по теме. Меня зовут Антон, я IT‑менеджер в продукте Эквайринга, и мне удалось собрать знающих ребят в QIWI, чтобы довольно подробно ответить на эти вопросы.

Предложение пообщаться

Я думаю, что немного сомневаться в своих решениях и ресёрчить новые возможности просто необходимо на постоянной основе. У меня накопилась целая куча вопросов относительно интернет‑платежей, ответы на которые я пока для себя не нашёл.

@aurokk

Что получилось — под катом.

Зачем? Это странно...

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

Проблематика прошлого

Когда‑то у QIWI была довольно популярная структура. У нас были отделы разработки, аналитики, тестирования и прочее. Ребята из этих отделов объединялись в проектные команды и занимались проектом.

При этом одной из целей нашей компании — «Поставлять всё возрастающее количество качественных инкрементов, способствующих развитию приоритетных продуктов, не забывая при этом о людях в командах«.

И в рамках этой цели у нас в фокусе всегда было две вещи:

Привет! Меня зовут Тимофей, я IT lead в QIWI. Но так было не всегда — например, год назад я в рамках того же продукта, что и сейчас, был продуктовым разработчиком в части бэкенда. Передо мной (так я был старожилом) поставили занятную задачку — собрать новую команду. В этом посте я хочу рассказать про ролевую модель Белбина, почему она (на мой взгляд) очень полезна для работы и для построения команд. А ещё о том, какие проблемы могут возникать в вашей компании, если в ней нет определенных ролей.

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

Я понял, что у меня как у программиста понимание этой модели (почему некоторые команды складываются, а некоторые — вообще никак) почти никакого нет. Когда я был больше программистом, большинство моих вопросов мог решить Stack Overflow. Однако с вопросом «Как мне собрать идеальную команду, чтобы она здорово перформила?» даже он не смог мне помочь.

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

Привет! Меня зовут Пётр, я менеджер по отказоустойчивости в QIWI. В этом посте мы поговорим про выбор новых классов продуктов. Как-то раз мы с одним разработчиком из другой компании стали обсуждать, почему бы не выбрать для работы какую-то распределенную СУБД, поддерживающую SQL? Из этой дискуссии родился мой доклад для нашей QIWI Server Party. Представляю вам его текстовую версию.

Привет! Меня зовут Александр Пронин, я занимаюсь тестированием более пяти лет, последние полгода из которых — в QIWI, проект ContactPay. Мы делаем платежную систему для международного рынка, она состоит из микросервисов, которые написаны на Python и живут в Google Cloud. Проект существует на рынке более двух лет, на данный момент среди наших клиентов уже есть компании-единороги. 

Так что в этом посте мы рассмотрим изменения процессов тестирования и доставки новых фич, проделанные нами за полгода, с точки зрения того, как в ContactPay это было раньше, что изменили и к каким результатам это привело.

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

Всем привет! Есть такое понятие, как I-shaped специалист — человек, который является экспертом в какой-то области и развивает свои знания в ее рамках. А еще есть понятие дженералист — этот человек уже разбирается во многих областях, но при этом не является ни в одной из них экспертом. В восьмидесятых-девяностых годах появилось понятие “T-shaped специалист”, тот, кто является экспертом в какой-то одной области и имеет поверхностные знания в одной или нескольких других. Сразу оговорюсь, что мы в продукте Кошелька под областями понимаем платформы разработки — бэкенд, QA, IOS, Web и так далее. 

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

Поэтому я люблю метрики — они помогают убедиться в том, что все идет хорошо. О метриках отношений микросервисов и будет этот пост. Меня зовут Алексей Лашнев, я продуктовый разработчик в QIWI.

Привет!

Вчера прошёл наш QIWI Server Party SOFT EDITION (кстати, вот тут запись трансляции). А 29 сентября мы проведём вторую часть митапа, которая будет уже про техническую сторону. 

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

Итак, вот что вас ждёт на HARD EDITION:

Привет!

Мы открываем восьмой сезон QIWI Server Party, митапов для бэкенд-разработчиков и не только. В этот раз мы поделили митап на два самостоятельных дня, посвятив первый день софтовой части, а второй — хардам и желающим заглянуть под капот (его анонс будет чуть позже).

Всем привет! Сегодня мы поговорим об интеграционном тестировании платежного шлюза, но перед этим расскажу немного про нашу команду и наш проект. Мы (ContactPay) — самостоятельный финтех-стартап внутри QIWI, строим высокопроизводительный отказоустойчивый платежный шлюз и соответствуем стандартам безопасности PCI DSS. 

Как платежный шлюз мы интегрированы со множеством внешних API, это могут быть и платежные системы, и сторонние сервисы мониторинга, антифрода, KYC (know your customer) и так далее. 

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

Мы стараемся писать корректный код с наименьшим количеством  багов. Код должен быть читаемым, самодокументируемым и поддерживаемым. Кроме того, он должен быть безопасным, так как мы  финтех и у нас PCI DSS, это накладывает определенные требования к безопасности. А ещё код должен быть тестируемым. 

Сегодня мы поговорим о двух метриках — корректность и тестируемость. Одна метрика напрямую влияет на другую, через тестируемость мы добиваемся корректности в том числе, мы проверяем, насколько код ожидаемо работает. 

Перед тем как говорить об интеграционном тестировании, нужно понять, какой процесс мы будем тестировать. Рассмотрим сценарий интеграционного тестирования из жизни. Это сценарий выставления счета, на самом деле процесс проходит в несколько этапов, но мы рассмотрим в посте первые две стадии этого сценария.