Записки айтишника

Уже на следующей неделе (26 февраля) стартует конференция Podlodka QA Crew #11 🥳 Завтра я проведу открытую сессию «Публичное собеседование на позицию Head of QA» Возможно, вы уже являетесь частью команды QA или только задумываетесь о входе в эту область. Независимо от вашего опыта, мок-собеседование представляет собой ценную возможность углубить знания. Можно посмотреть видео на ютубе и понять, что от тебя ожидают на реальном собеседовании. Но найти интервью Head of QA или Principal QA Enginner несколько сложнее. Кто это такие? Каковы их обязанности? Что требуется, чтобы войти в их ряды? Заинтересовало? Приходи и послушай! Обсудим реальные кейсы и поделимся полезной обратной связью с обеих сторон. Ссылка на стрим: https://youtube.com/live/GjXkgf4EqM0 А если вы дочитали до этой строчки и очень хотите попасть на конференцию, то у меня есть две бесплатные проходки! Для этого просто напишите мне в личку. Кто первый встал, того и ... ну вы поняли. Да, вот так просто 🙃 upd. больше промокодов нет

Привет! На связи Podlodka QA Crew🐞. 26 февраля стартует новый сезон и мы приготовили для вас кое-что особенное. Бесконечно можно смотреть на огонь, воду и извечный баттл между «знать только то, с чем сталкиваешься в работе ежедневно» и «не знать теорию — ограничить себя только известными способами решения проблем». Мы считаем, что хорошая теоретическая база – то, что отличает обычного QA-инженера от крутого. Приглашаем специалистов тестирования вместе вдохновиться теорией и начать использовать её на практике: 🔹 выясним, как эффективно выстраивать экосистему тестовой документации; 🔹начнём правильно применять SCRUM-методологию в работе тестировщика; 🔹научимся обеспечивать качество тестирования, повышать скорость и точность выполнения задач с помощью матанализа и алгоритмов; 🔹избавимся от страха программировать и заставим тезис «писать код может каждый» работать в реальной жизни; 🔹обсудим главные теоретические вопросы собеседований на уровень middle+ и выше, узнаем как правильно на них отвечать. Ну и хватит пока теории на один анонс :) Отправляйтесь на сайт за билетом и вперед практиковаться: https://podlodka.io/qacrew Реклама. ИП Толстая Елена Петровна ИНН:507503278104 erid:2SDnjd7Ahck

Буду в программном комитете одной из самых уютных конференций! Скоро еще пару новостей :)

Исследование зарплат IT-специалистов за второе полугодие 2023 от Хабр Карьеры Читать статью

📚 10 полезных книг по системному дизайну 1. "System Design Interview" Alex Xu 2. "Learning Domain-Driven Design" Vlad Khononov 3. "Implementing Domain-Driven Design" Vaughn Vernon 4. "Domain-Driven Design: Tackling Complexity in the Heart of Software" Eric Evans 5. "Hands on Domain-Driven Design" Michael Plod 6. "Fundamentals of Software Architecture" Mark Richards, Neal Ford 7. "Building Microservices" Sam Newman 8. "Monolith to Microservices" Sam Newman 9. "Architecting for Scale" Lee Atchison 10. "Building Evolutionary Architectures" Neal Ford, Rebecca Parsons, Patrick Kua

📚 Принципы разработки 📍 DRY (Don't Repeat Yourself) Если находите в двух и более местах одинаковый код — смело убирайте дублирование. Этот принцип еще иногда называют WET (Write Everything Twice или We Enjoy Typing) 📍 KISS (Keep it simple, stupid) Большинство систем работают лучше всего, если их сохранять простыми, а не усложнять 📍 SOLID — S (Single Responsibility Principle) – Каждый модуль или класс должен отвечать только за одну конкретную функцию или задачу — O (Open/Closed Principle) – Модули, классы и функции, должны быть открыты для расширения, но закрыты для модификации — L (Liskov Substitution Principle) – Объекты в программе должны быть заменяемыми экземплярами их базовых типов, не нарушая логику — I (Interface Segregation Principle) – Клиенты не должны зависеть от интерфейсов, которые они не используют — D (Dependency Inversion Principle) – Классы должны зависеть от абстракций, а не от конкретных реализаций 📍 YAGNI (You Ain't Gonna Need It) Пишите только тот код, который будете использовать. Не надо следовать подходу "он может пригодиться позже" 📍 Бритва Оккама Не следует привлекать новые сущности без крайней на то необходимости 📍 DSDM (Dynamic Systems Development Method) Три базовых принципа, которые мы можем учитывать заранее и влиять на них: время, цена и качество. Более развернуто описаны в методе, как "взаимодействие с пользователем", "частые релизы", "самостоятельное принятие решений", "тестирование на всех этапах цикла" и т.д. 📍 BDUF (Big Design Up Front) Сначала необходимо все спроектировать и только после этого приступать к реализации 📍 APO (Avoid Premature Optimization) Не надо заниматься оптимизацией/рефакторингом без необходимости этого

🎄С новым годом🎄 Поздравляю вас с наступающим новым годом! Пусть он будет лучше текущего, а все ваши мечты и желания исполняются 💫 Кстати, получается завтра новый год, новый месяц, новая неделя, понедельник, первое число. Больше отложить ничего не получится. Сошлись все звезды 😅

В основном люди говорят о победах, достижениях и успешном успехе. Это интересно, это вдохновляет. А признавать ошибки сложно. Но мы тут вместе с Виталиком и Катей подумали, набрались смелости и решили рассказать про наши поражения, неудачи и как зарабатывался опыт. Моя история ниже: Примерно 6 лет назад я пробовал запустить маркетплейс услуг в сфере мероприятий. Даже статья на VC сохранилась 😌 В тот момент, в этой нише было трудно найти качественных исполнителей без агентств, опыта в ивент сфере, либо сарафанки. Идея казалась гениальной: люди заходят, оставляют заявку, а исполнители откликаются и предлагают цену. Ох, как я ошибался и какой крутой опыт я купил 😬 Делюсь: 📍Стратегия выхода на рынок важнее продуктовых гипотез и надо готовиться к худшему сценарию. Сгенерировать тонну прикольных идей и фичей — элементарно, а вот эффективно решить проблему пользователя — сложно 📍 Упаковка продукта. Нужен прям хороший акцент, моего было недостаточно. Надо лучше понимать как влюбить и удерживать пользователя 📍 Перфекционизма быть не должно. Не надо вылизывать код, продукт, дизайн и т.п. до идеала. Получать фидбек пользователей важнее. А когда уже вы поняли курс, то нужно будет сесть и закрыть ошибки "нас из прошлого" 📍 Определитесь с тем, что такое MVP. Четкий список функционала и никакой торговли с самим собой. Всегда хочется побольше и круче, но не надо. Все улучшайзинги и "приколюшки" тоже потом 📍 Pet-проекты нужны. Они позволяют научиться смотреть на задачу с разных сторон, т.к. вы будете прокачивать разные навыки (маркетинг, дискавери, деливери, экономика, архитектура, кодинг и т.д. и т.п.) Если было полезно и интересно — ставьте лайк 👍, кидайте друзьям 🔥, это поможет понять о чем писать в будущем! Еще больше историй: ➡️ Вперед Sharovatov

📋 Матрица RACI Инструмент визуализации проектирования процесса. Матрица позволяет наглядно отобразить задачи и распределение зон ответственности. В колонках указываются люди или роли, а в строках указываются задачи. На пересечениях расставляют зоны ответственности R, A, C, или I, где: R (Responsible) — Ответственный. Он выполняет задачу, знает текущее состояние и все подводные камни A (Accountable) — Подотчетный. Отвечает за исполнение задачи, чаще всего менеджер С (Consulted) — Консультирующий. Дает рекомендации до исполнения, валидирует работу перед сдачей I (Informed) — Информируемый. Человек или группа людей, которым сообщают о ходе выполнения и завершении работ Бывают и другие вариации матрицы: - RASCI ("S" — Support, помогает выполнять задачу) - RACIQ ("Q" — Quality, тот кто проверяет качество работы) - RACI-VS ("V" — Verifier, проверяет результат. "S" — Signatory, отвечает за сдачу) При помощи матрицы можно выявлять следующие ошибки: 📍 Если у сотрудника нет R и A ролей, то возможно этот сотрудник не требуется для этого проекта 📍 Если у задачи нет R и/или A, то задачу либо не сделают, либо никто не отвечает за результат 📍 Если много C и I для одной задачи, то могут быть усложнены процессы информирования и обмена знаниями 📍 Если много A для одной задачи, то процесс согласования может стать узким местом 📍 Если на многих задачах стоит одинаковый сотрудник R, то он может быть перегружен 📍 Если много букв в одной клетке, то это может говорить про отсутствие зон ответственности