├── .gitignore ├── C-C++ ├── Java junior plan.xlsx ├── LICENSE ├── README.md ├── common ├── RolesAndResponsibilities.md └── TeamAndSoftwareDevelopment.md ├── interview └── algorithms_basics.md ├── introduction.md ├── links.md ├── meetups.md ├── meetups ├── Docker │ └── Кратко о Docker. 2021.pdf ├── Многопоточность и асинхронность │ ├── Многопоточность и асинхронность.docx │ └── Многопоточность и асинхронность.pptx └── Профессиональное развитие в IT │ └── Self_development_in_IT.pptx ├── python └── roadmap.md ├── qa ├── interview_questions.md ├── links.md └── testing_theory.md ├── resources ├── 0intro.md ├── C++.md ├── CSharp-.NET.md ├── algo.md ├── databases.md ├── interviews.md └── python.md └── z_attachments ├── placeholder.txt ├── Английский язык.pptx └── Особенности IT в Польше.pptx /.gitignore: -------------------------------------------------------------------------------- 1 | /.obsidian/ 2 | -------------------------------------------------------------------------------- /C-C++: -------------------------------------------------------------------------------- 1 | Цитата из чата 2 | "Я бы сказал, что в первую очередь для С/С++ важнее всего знать сам язык, стандартную библиотеку и устройство памяти. Все остальное вторично. 3 | 4 | Если по порядку: 5 | 1. git — тут всё стандартно, ожидания от джуна аналогичны как в любом другом стеке (clone/pull/push/commit/checkout/аааа-я-сломал-репозиторий-памагити) 6 | 2. Процесс сборки: 7 | 2.1. Этапы сборки. 8 | 2.1.1. Препроцессинг, компиляция, линковка. 9 | 2.1.2. Что такое Multiply definition, Undefined reference 10 | 2.1.3. Как работают инклюды и для чего они нужны 11 | 2.2. Неплохо уметь вызывать компилятор напрямую, понимать какие у него есть основные ключики. 12 | 3. Системы сборки. Хорошо бы понимать как работает хотя бы одна-две системы сборки (make, cmake, ninja), если ты умеешь запускать программу только нажатием на зеленый треугольник в Visual Studio и не понимаешь как она собирается под капотом — это плохо. 13 | 4. Устройство памяти. 14 | 4.1. Стек, куча, статическая память: зачем нужны, чем отличаются, как работают 15 | 4.2. Как хранятся данные в памяти, что такое Big-Endian, Little-Endian, как хранятся вещественные числа, как хранятся строки, как хранятся структуры, что такое выравнивание 16 | 4.3. Размеры данных в памяти, что обеспечивает стандарт, а что нет 17 | 4.4. Адреса, арифметика указателей. Что будет если вместо array[10] написать 10[array]? 18 | 4.5. Примерно понимать что такое стек-фрейм, как на нем хранятся данные. Почему возвращать из функции указатель на локальную переменную плохо. 19 | 4.6. Понимать что такое сегфолт и почему он происходит. 20 | 5. ОС. Тут специфично, требования к виндовой, линуксовой и эмбеддед разработке могут значительно отличаться. Но я бы выделил такие плюс-минус общие пункты: 21 | 5.1. Что такое процесс, какой у него жизненный цикл, как появляется, как уничтожается, что в себе хранит. 22 | 5.2. Виртуальная память. Не надо прям досконально знать как происхоидт маппинг страниц, но в целом понимать что виртуальная память != физическая и что происходит отображение виртуальных адресов на физические знать нужно. 23 | 5.3. Сигналы. 24 | 25 | Ну вот вкратце как-то так. То что я перечислил — это скорее джун+, миддл-, это больше чем нужно джуну в базовой комплектации. 26 | https://github.com/evlinsky/cpp/tree/master/SPbU_F19-S20" 27 | -------------------------------------------------------------------------------- /Java junior plan.xlsx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Entering-IT/documentation/aeaced424f65df913285833d4fc388ab94303922/Java junior plan.xlsx -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2021 Entering IT 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Содержание 2 | 3 | ## Что и зачем 4 | 5 | Наша организация нацелена на помощь тем, кто интересуется темой IT. 6 | 7 | ## Назначение репозитория 8 | 9 | В этом репозитории мы храним полезные статьи и ссылки, которые помогут вам не всех ступенях в становлении вас, как начинающего IT специалиста. 10 | 11 | ## С чего начать? 12 | 13 | Мы рекомендуем начать с [этого документа](introduction.md), но это не является требованием, вы можете выбирать любые материалы, что вам будут интересны. 14 | 15 | ## FAQ 16 | 17 | [Часто задаваемые вопросы](https://github.com/Entering-IT/documentation/discussions/categories/q-a) 18 | 19 | 20 | ## Карта документов 21 | 22 | Ссылки на документы в этом репозитории. 23 | 24 | - [Введение](introduction.md) 25 | - Выбор направления 26 | - [Роли и обязанности в разработке ПО](common/RolesAndResponsibilities.md) 27 | - [Групповая разработка ПО](common/TeamAndSoftwareDevelopment.md) 28 | - [Ссылки на материалы для обучения](links.md) 29 | - [Структурированные материалы с отзывами "из первых рук"](resources/0intro.md) 30 | - [Видео встречи (архив)](meetups.md) 31 | 32 | ## Программы обучения 33 | - [Наш канал YouTube](https://www.youtube.com/channel/UCW0TBEyJDtY1pwq3S_pMDFQ) 34 | - [Pyhon разработчик](python/roadmap.md) 35 | - [Java, изучение через создание проекта](https://www.youtube.com/watch?v=TpxGzbn2_x4&list=PLyxk-1FCKqockmP-fXZmHQ7UlYP3qvZRa) 36 | 37 | ## Подготовка к собеседованиям 38 | 39 | - [Алгоритмы (FAANG)](interview/algorithms_basics.md) 40 | 41 | ### Тестовые собеседования 42 | 43 | - [Подать заявку](https://forms.gle/p8TuT9zb31eXYuHr5) 44 | - [Список заявок](https://docs.google.com/spreadsheets/d/1XskAWtyP95B-Mb9-acj2n2_xFxbfRirfL99d4Tq2DiA/edit?usp=sharing) 45 | -------------------------------------------------------------------------------- /common/RolesAndResponsibilities.md: -------------------------------------------------------------------------------- 1 | # Роли и обязанности в разработке ПО 2 | 3 | Итак, вот примерно роли и их описание. Я расскажу, как я это вижу, потому в других компаниях это может отличаться. 4 | 5 | ## Разработчики 6 | 7 | - интерн - временный девелопер, делает какой-то маленький проект под присмотром прикрепленного старшего товарища. 8 | - джуниор - наносит небольшую, но постоянную пользу проекту/компании, также под присмотром. Делает всю самую простую и скучную работу. Может взять на себя реализацию небольшой фичи. 9 | - мидл - может взять на себя один проект / сервис полностью, сделать его сам или в составе команды 10 | - сеньор - обычно отвечает за продукт/набор продуктов, помогает всем, кто ниже по рангу, отвечает на все технические вопросы по продукту (или сервису). Определяет все технические решения для команды или группы команд. Короче, властелин кода и архитектуры уровня продукта. В идеале, у каждой команды свой сеньор, в реале у сеньора может быть несколько команд. В общем, если есть проект/продукт/задача, любой технический вызов, который команда не вывозит, привлекается сеньор. Сеньор при желании может вытянуть проект любой сложности из жопы в релиз. Серьор помогает команде работать эффективно. Другими словами, если всё плохо, то зовут сеньора и все становится хорошо. Также сеньор может вывезти проект в одного, при желании. Определяет различные инициативы внутри своей вотчины, ведет презентации. Подчиняется Senior SDM, плотно работает с принципал девелопером. 11 | - принципал девелопер - отвечает за набор продуктов, руководит сеньорами (ну как руководит, сотрудничает :)), определяет то, как продукты/сервисы могут взаимодейсвовпть между собой. 12 | - архитектор - определяет линию партии, обычно привлекается, когда требуется руководство для создания нового о продукта / сервиса, определяет дизайны высокого уровня, документы с диаграммами - его основной инструмент. Если честно, полезный архитектор - птица редкая. 13 | 14 | ## Менеджмент 15 | 16 | - SDM - Software Develoment Manager - менеджер, который владеет командой и продуктами. Привязан к одной команде. Определяет общий приоритет проектов. Следит за командой, решает организационные задачи, помогает всем, чем может. aka Начальник отдела. 17 | - Senior SDM - руководитель для SDM, руководит по сути всем, что происходит в его юристдикции, определяет вектор развития всего своего департамента, решает все организационные вопросы на своем уровне. aka Глава департамента. 18 | - Project Manager - руководит проектами, может иметь 10-20 проектов параллельно. Может не вдуплять техническую часть вообще, его работа - организовать работу проекта, организовать кросс-командные взаимодействия, сделать за проектом, решать все орг. вопросы, подготовить все необходимые документы, отвечает также за планирование проекта. В общем, он переживает за проект больше всех, ведет проект от начала до конца. Для понимания, у команды может быть несколько проектов одновременно, у проекта может быть несколько команд одновременно. Потому у проекта должен быть один ответсвенный человек и это project manager. 19 | - Product manager - тот, кто отвечает за конкретный продукт или продукты. Определяет как продукт будет работать с точки зрения бизнеса. Определяет вектор развития продукта с точки зрения бизнеса. Не вдупляет в тех. часть, но лушче всех знает как его продукт работает, какие в нем есть фичи, кто и как его использует и т.д. 20 | - BA - Business Analyst - это аналитик, его задача - обычно оценка новых фич, по уровню знания примерно как Product Manager, но ничего не определяет, но отвечает на вопросы девелоперов типа "а как юзер должен взаимодействовать с продуктом в фиче Х продукта У?" 21 | 22 | ## Универсальный солдат 23 | 24 | - Team Lead. Когда я был тимлидом, я совмещал сеньора, девелопера, скрам мастера, прожект менеджера. Короче, когда я стал тимлидом, ко мне подошел директор, показал пальцем на команду, на заказчика и попросил сделать хорошо. Все остальное делаешь сам, то есть: работа с заказчиком, понимание проблемы, дизайн, вся необходимая документация, набор/тренинг команды, выстраивание процесса (agile, scrum, что хочешь вообще), выстраиваешь SDLC процесс, руководишь проектом, работаешь с дизайнерами, тренируешь доевеперов, если команда не вывозит тех. задачу - делаешь сам. В общем, организуешь всё, максимум независимости. 25 | 26 | 27 | ## Качество ПО 28 | 29 | Бытует мнение, что QA это просто сидишь и тыкаешь в продукт, пока не найдешь баг. Это не так. 30 | Есть рядовые QA, обычно являются частью команды. Работа такого QA - это управление качеством каждого продукта, которым они владеют. 31 | 32 | Эти QA: 33 | - определяют планы тестирования для продуктов. 34 | - для каждой задачи, QA должны не только понять суть задачи с точки зрения бизнеса, но и убедиться, что задача решена девелопером именно так, как задумано, и что никакой другой функционал не поломан при этом. По сути задача не считается законченной, пока QA не дал на это согласие. Мало того, тестирование каждой задачи документируется, с указанием как именно тестирование было проведено и почему оно считается успешным. 35 | - QA умеет выполнять и выполняет регрессионное тестирование перед каждым релизом. Следовательно QA определяет план регрессионного тестирования вплоть до мелких подробностей для каждого из тестов. 36 | - Если может в автоматизацию, то пишет автоматизированные регрессионные тесты. 37 | - Юнит тесты пишут девелоперы, QA обычно вообще не интересны юнит тесты. Если это, конечно, не Software Development Engineer in Test (SDET), которых я не видел никогда. 38 | - Помимо регрессионных тестов, выполняет все остальные виды тестов (например, smoke testing, etc) 39 | - так как количество QA обычно сильно меньше, чем девелоперов, то QA владеют общей картиной гораздо лучше сраднего девелопера, разбираются и в задачах, поставленных девелоперам, и в продукте. QA плотно работают и с девелоперами и с бизнес аналитиками. 40 | - QA - это последняя линия защиты от багов и задач, реализованных ненадлежащим образом. 41 | 42 | Есть Lead QA - обычно управляют качеством проектов, то есть это такие, типа, Project Manager, только в проектах они отвечают за качество. Например, они отвечают за интеграционное тестирование кросс-комндных фич. Вообще все вопросы по качеству проекта адресуют Lead QA, Lead QA работает вплотную с QA команд. 43 | 44 | Многие компании отказываются от QA и перекладывают ответственность QA на девелопера, Lead QA на Project Manager. 45 | 46 | 47 | ## Немножко про UX. 48 | 49 | Я встречал заблуджение, что UI/UX дизайнер бездумно клепает дизайны форм и не парится. Я расскажу из моего опыта работы с UI/UX дизайнерами здорового человека. 50 | 51 | UI/UX дизайнер начинает работу задолго до девелопера. Он опеределяет то, как конечный юзер будет взаимодействовать с продуктом. Да, все элементы интерфейса определены дизайнером. 52 | UI/UX дизайнер в идеале участвует во всех обсуждениях новых фич на уровне бизнеса. 53 | 54 | Казалось бы, что тут сложного? Но! 55 | 56 | - Чтобы нарисовать интерфейс, надо понять, что именно юзер хочет сделать и зачем. То есть дизайнер должен понимать бизнес задачу до самых мелких деталей. Интерфейс, который не нужен или излишен, будет являться фейлом работы UI/UX дизайнера. 57 | - Юзер не будет использовать интерфейс, который ему не нравится. Все элементы интерфейса должны быть гармоничными и логичными для юзера и задачи, которую он решает. Но юзер не знает заранее, что для него логично, а что нет. Но юзер не знает заранее, что для него гармонично, а что нет. Попробуйте решить такую задачу. 58 | - Зачастую, реализация фронта и API бекенда отталкиватеся от UI. А значит и оценка фронта работ отталкивается отуда же. Девы смотрят на дизайн страницы, но видят в нем что то вроде "вот тут надо подгрузить товары для грида, тут надо АПИ для кнопки". Девы обычно не видят работы, которая стоит за дизайном и не задаются вопросом "а зачем тут грид и кнопка? что она дает заказчику?". Хорошие девы таким вопросом задаются и быстро становятся сеньорами. Пример - дизайнер может придумать такой элемент управления, который будет очень простой для юзера, но очень сложный для реализации девелоперам. Дизайнер будет защищать UI experience, он выступает как адвокат юзера в таких случаях. 59 | - UI/UX дизайнер должен хорошо знать дизайн продукта и все фичи продукта, чтобы дорабатывать дизайн своими наработками. Если ты поставил кнопку, а такая кнопка уже есть в другом месте и там её нажимать удобней - ты об этом узнаешь скорее всего уже от юзера. Удачи пояснить Project Manager, SDM, девелоперам и QA почему ты профукал их время на работу, которая не нужна. 60 | - UI/UX вдадеет так называемой концепцией продукта, то есть все решения, что были вынесены для дизайна, все концепции дизайна, всё это вотчина дизайнера. 61 | 62 | UI/UX дизайнеры плотно работают со всеми, от бизнеса до девелоперов. 63 | 64 | Зачастую ролью дизайнера пренебрегают, и тогда эту роль дают программистам. Так и рождаются формы с миллиардами бессмысленных полей. 65 | 66 | ---- 67 | 68 | В небольших компаниях ролей будет минимум, но каждая роль будет более универсальной. 69 | В больших компаниях ролей будет много, специализация будет выше. 70 | 71 | Для понимания, это не какое то жесткое разделение, есть некоторые девиации. Например, сеньор может вполне работать в паре с джуном или выступать как скрам мастер для команды или организовать кросс-департаментное взаимодействие. Также и для других ролей. 72 | Например, если есть крупный проект, на него могут назначить сильного мидла вместо сеньора. Тогда мидл будет работать на уровне серьора и может это использовать для своего повышения. 73 | Ну и другие девиации возможны. Обычно всё сильно зависит от скиллов, SDM может совмешать Project manager работу и т.д. Потому писанина выше - это просто ориентир, но не какие-то жесткие правила. 74 | -------------------------------------------------------------------------------- /common/TeamAndSoftwareDevelopment.md: -------------------------------------------------------------------------------- 1 | # Групповая разработка ПО 2 | 3 | Что нужно сделать для того, чтобы проект можно было разрабатывать небольшой командой? 4 | 5 | В этом моменте я считаю, что у вас уже есть техзадание или представление о том, как должен выглядеть конечный результат. 6 | 7 | ## Концепт / дизайн / архитектура 8 | 9 | Первым и важным шагом к командной разработке является сформулированный концепт или дизайн верхнего уровня, если можно так выразиться. Когда работаешь один, ты все время держишь в голове общую картину: какое приложение должно появиться на выходе, из каких модулей оно будет состоять, какие вообще критерии качества и законченности есть у проекта. Когда работаешь в команде, важно, чтобы это представление было консистентно для всех участников разработки. Например, разделение на модули "Логина юзера", "Корзины заказов", "Главного списка товаров", и тд. То есть это должно быть задокументировано и зафиксировано. Этот документ и все следующие можно положить рядом с исходным кодом. 10 | 11 | ## Сопряжение модулей 12 | 13 | Когда модули определены, важно зафиксировать способы, как они между собой взаимодействуют. Хотя бы в общих чертах. Это нужно для того, чтобы написание модуля было более-менее изолированной задачей. Например, вы раздаете ответственности за эти модули своим коллегам и вдруг один из них не справился - при этом желательно, чтобы фейл одного разработчика оказал минимальное воздействие на остальные модули, ну и зафейленный модуль можно было бы просто переписать заново, не трогая кодовую базу остальных модулей. 14 | 15 | ## Core сервисы 16 | 17 | Скорее всего, когда вы будете писать модули, вы будете использовать какой то общий код, общую библиотеку, например для логгирования, для обращения к БД, для управления доступом юзеров. Это очень важная часть, я бы рекомендовал это доверить самому опытному разработчику (или разработчикам). Здесь также можно посоветовать заранее подготовить уже программный интерфейс (то есть просто сесть, и, совместно с командой, накидать интерфейсы таких сервисов). Имея заранее подготовленные интерфейсы, обязанности по имплементации этих интерфейсов вы уже можете разделить между разработчиками. Иметь интерфейсы в этом случае очень важно, так как 18 | 19 | 1. Эти сервисы затрагивают все модули, а значит фейл в сервисе означает переделку всех модулей. Имея интерфейс, мы декларируем возможности сервиса, но фейл при имплементации будет локализован, а сама имплементация сервиса может быть заменена. 20 | 2. Наличие интерфейсов core сервисов позволяет начать разработку модулей немедленно. Нет смысла ждать имплементации, когда есть интерфейс, который, если имплементация не готова, всегда можно закрыть моком/стабом/фейком. 21 | 22 | ## Образец 23 | 24 | Эта задача также для группы или для самых опытных разработчиков - подготовить примерный концепт или пример реализации модуля. Цель этого - показать шаблон для других разработчиков, как писать ваши модули, из каких частей они должны состоять. Например, если вы планируете 3-уровневую архитектуру, то вы можете продемонстрировать, как её реализовывать в сопряжении описанных выше core сервисов. Кстати говоря, тут вы и делаете выбор по вашей архитектуре, будет ли она состоять из слоев или представлять собой CQRS или что то иное. 25 | 26 | ## Задачи 27 | 28 | Итак, у вас есть интерфейсы основных сервисов, у вас есть высокоуровневая архитектура. Теперь вы можете приступить к списку задач. Список задач нужен для многих вещей, например, чтобы знать примерный объем работы. Формируйте список задач вместе с командой. Важный момент здесь - чтобы каждый член команды понимал для чего так или иная задача. Вы можете ещё не понимать, как конкретно задачи будут выполнены, но вы должны понимать, зачем эти задачи вообще нужны. 29 | 30 | 1. Здесь постарайтесь избегать технических задач, по крайне мере в самом начале. Пример плохой задачи: "Написать репозиторий для заказа, чтобы его можно было использовать в модуле заказов". Эта задача по сути ничего не говорит о том, какую ценность она несет и как её выполнять. Пример задачи получше: "В модуле личного кабинета юзера добавить возможность видеть список его активных заказов с полями (поля) со ссылкой на переход на страницу конкретного заказа." - То есть формируя список задач я бы советовал в первую очередь отталкиваться от того, как система будет использоваться теми людьми, что с ней работают. Такие user story, если хотите. 31 | 32 | 2. Избегайте больших задач, делите задачи так, чтобы любую из них можно было бы выполнить за максимум несколько дней. Желательно также при создании задачи примерно указывать время на её реализацию. 33 | 34 | 3. Разделяйте задачи правильно. Не пишите кросс-модульные задачи - если задача требует вовлечения нескольких модулей - делите её на несколько задач. 35 | 36 | 4. Старайтесь держать задачи изолированно, если это возможно. Имейте ввиду, что любая задача может быть зафейлена программистом, это должно иметь минимальные последствия для вас и вашей системы, вы просто перепоручаете задачу другому программисту и он её выполняет. 37 | 38 | ## Соглашения по коду 39 | 40 | Итак, у вас есть образец модуля, у вас есть задачи, у вас есть core модули. Вы почти готовы. Но вы должны понимать, что помимо четкого разделения на модули / задачи / ответственности, было бы очень хорошо, чтобы были какие то соглашения по коду. Это нужно, так как у каждого программиста своё представление о том, как называть переменные и классы, когда надо перехватывать/создавать исключения, и прочее и прочее. Старайтесь держать проект примерно в одном и том же стиле. Например, у меня были разные случаи и требования, начиная от того, что каждый файл в проекте не должен иметь даже предупреждений от Решарпера, заканчивая многостраничным трактатом об именовании типов. Поскольку вы пишете на C#, могу вам посоветовать начинать [отсюда](https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/). Модули, написанные в одном и том же стиле, легче понять. 41 | 42 | ## Процесс разработки 43 | 44 | Имея всё перечисленное выше, вы можете приступать к работе. Есть много разных методик, как начинать командную работу и я бы не хотел говорить, что одна методика лучше другой. Я просто опишу, что было в моем опыте и что сработало. 45 | 46 | Я в последние годы использую [Scrum](https://ru.wikipedia.org/wiki/SCRUM), но описание этой методологии выходит далеко за пределы ответа. 47 | 48 | Поскольку у вас в команде будет всего несколько человек, я просто дам базовые понятия, что стоит делать и как организовать работу. Это будет полезным, даже если вы работаете вдвоём или вообще один. 49 | 50 | Начать я рекомендую с определения интервалов работки. Спринтов, если хотите. То есть минимальный период времени, в конце которого вы будете показывать результат работы команды. Это обычно неделя или две недели. То есть в начале спринта вы, с командой и (возможно) вместе с заказчиком берете набор самых важных на текущий момент задач, которые вы выполните за время спринта. Так как каждая задача уже имеет сроки её выполнения, то будет несложно набрать задач на неделю-две. К тому же, я советую брать задач на хотя бы 70% времени, не больше. То есть для 1 недели берите задач на 4 рабочих дня, для 2 недель - на 8 дней для всей команды. Это нужно, чтобы у вас оставалось время на маневры, а если задачи кончатся раньше, то вы всегда сможете взять ещё. В конце спринта вы эти задачи демонстрируете заказчику, подводите итоги спринта, обсуждаете что было хорошо, что можно улучшить в процессе и планируете следующий спринт. По идее, тут все понятно, кроме демонстрации заказчику. Смотрите, планирование спринта вначале и демонстрация работы в конце очень важны, это не только помогает команде увидеть результат, но и также помогает понять, является ли то, что вы делаете, именно той работой, что нужна заказчику. Это нельзя переоценить, я видел слишком много случаев, когда программисты решали задачи, которые заказчику были не нужны или решались не тем способом, который заказчик ожидал. Если вы только начинаете разработку и не уверены в своих силах, вы можете даже приглашать заказчика на ежедневные летучки (о них ниже) и собирать с заказчика обратную связь. 51 | 52 | После этого каждый разработчик берет себе задачу и начинает её выполнение. Старайтесь, чтобы сильно связанные задачи выполнял один разработчик, а слабо связанные - разные разработчики. Это необходимо, чтобы разработчики работали над разной кодовой базой и как можно меньше пересекались, чтобы они не ждали друг друга и не работали с одними и теми же классами. 53 | 54 | В течении спринта, я бы рекомендовал иметь небольшие летучки каждый день, чтобы иметь информацию о том, кто и что делает, нет ли у кого проблем. Для разработчиков типичные моменты, когда он что то ждет и теряет время, но знает о проблеме только он. Старайтесь такого избегать. 55 | 56 | Также необходимо иметь доску задач, которые были взяты в спринт, чтобы любой (в том числе и заказчик) в любой момент времени мог бы поглядеть на эту доску и понять, какие задачи в работе, какие закончены, а какие ещё не начаты. 57 | 58 | Разделение на задачи, создание досок с задачами и прочее можно делать на обычной доске в офисе (если вся команда и заказчик находятся рядом), либо есть специальные инструменты для этого в интернете. 59 | 60 | ## Работа с кодом 61 | 62 | Работа с кодом это тоже сложная тема. 63 | 64 | В командной разработке обычно подразумевается, что вся команда должна работать с одной и той же кодовой базой. Вы всегда должны иметь возможность скачать самую свежую версию исходников и собрать билд. 65 | 66 | Я, после того, как перешел на GIT, уже не вижу дороги назад, хотя у меня есть опыт и с SVN, SourceSafe, TFS-CVS, Mercurial и даже папочками на расшаренном ресурсе. 67 | 68 | Говоря о GIT, есть разные инструменты (например, я использую бесплатный [SourceTree](https://www.atlassian.com/software/sourcetree)) и модели, как с ним работать. Я предпочитаю держать отдельно основную ветку (master), отдельно ветку разработки (develop), отдельно ветки для задач (feature/задача), отдельно ветки релизов, хотфиксов и тд. Но для маленькой команды это оверхед. Есть вполне себе простая методика [GIT feature branching](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow). Идея тут максимально проста: 69 | 70 | 1. Когда девелопер 1 начинает свою задачу, он создает ветку от текущей мастер ветки 71 | 2. Когда девелопер 1 заканчивает свою задачу, он создает pull request - это просто намерение добавить изменения в основую ветку из ветки для задачи, он также назначает человека (девелопер 2), который этот pull request будет проверять 72 | 3. Девелопер 2 проверяет pull request, и если необходимо, просит девелопера 1 внести больше изменений, написать тесты и прочее. 73 | 4. Девелопер 1 вносит нужные изменения 74 | 5. Девелопер 2 проверяет снова и либо снова просит внести изменения, либо дает добро на слияние изменений в основную ветку 75 | 6. Обычно, в моей практике, девелопер 2 выполняет слияние изменений, но бывает что это делает и девелопер 1. 76 | 7. Изменения тестируются, проверяются, после этого задача либо требует новых изменений (новый pull request), либо задача закрывается. 77 | 78 | Конечно, тут неизбежны конфликты, когда несколько программистов работают над одним и тем же файлом. GIT никак не помогает избежать таких конфликтов, он помогает только их разрешать. Что помогает из избегать, так это разделение на независимые модули и несвязанные задачи. Если вы заметили, то выше мы везде старались разделить код на модули, а где этого не было возможности сделать - то хотя бы разделить интерфейс и реализацию. Чем больше ваш код изолирован от остального кода, тем меньше вероятности получения конфликтов, так как в этом случае, чтобы получить конфликт, программисты должны работать на сильно связанными задачами, чего я выше советовал избегать. 79 | 80 | ## [Непрерывная интеграция (continuous integration)](https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BF%D1%80%D0%B5%D1%80%D1%8B%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B8%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F) 81 | 82 | Имея общий репозиторий исходного кода, очень важно следить за тем, что код всё ещё компилируется, собираются, что тесты не падают, что в любой момент времени вы можете скачать самый свежий билд, не дожидаясь никого. По сути, это и называется непрерывная интеграция. Каждый раз, когда кто то вносит изменения в общую ветку разработки, сервер непрерывной интеграции должен создать новый билд вашей программы и прогнать все автоматические тесты. 83 | 84 | ## Тестовый стенд 85 | 86 | Чтобы иметь представление, работает ваша программа или нет, вам желательно иметь возможность не только собрать билд, но и развернуть ваше приложение на каком-либо тестовом окружении. Например, если вы пишете веб сайт, у вас должен быть тестовый сервер, где вы сможете нажатием одой кнопочки на билд-сервере развернуть ваш код и поглядеть, как ваша система выглядит. В идеале, желательно иметь даже 2 тестовых окружения, одно для вас, второе для заказчика. Чтобы во время каждого демо в конце спринта, вы могли развернуть ваше приложение в тестовом окружении для заказчика и чтобы заказчик мог сам, без вашего ведома, заходить в свое окружение (например, на свой вебсайт) и проверять реализованный функционал. 87 | 88 | ## Почти конец 89 | 90 | Я попробовал пробежать по самым азам командной разработки. Большинство тем я не рассматривал в деталях, но я надеюсь, у вас появилось какое то базовое представление о том, как и что должно работать. 91 | 92 | ## Инструменты 93 | 94 | Есть уже готовые к работе сервисы, которые содержат в себе уже и списки задач, и доски для планирования спринтов, и возможности по управлению исходным кодом, и билд серверы. 95 | 96 | Например, 97 | 98 | Если вы не хотите морочиться с собственными серверами (а вы не хотите :) 99 | 100 | 1. [Visual Studio Online](https://app.vssps.visualstudio.com/) - это сервис - решение всё в одном. 101 | 2. [Github](https://github.com/) - это всё, кроме build сервера. Однако, его легко связать с бесплатными build серврами, например с [Travis](https://travis-ci.org/) или [AppVeyor](https://www.appveyor.com/) 102 | 3. У компании [Atlassian](https://www.atlassian.com/) есть множество сервисов, например доски задач [Jira](https://www.atlassian.com/software/jira) или [Trello](https://www.atlassian.com/software/trello), сервис хранения исходных кодов [BitBucket](https://www.atlassian.com/software/bitbucket), билд сервер [Bamboo](https://www.atlassian.com/software/bamboo) и многое другое. 103 | 4. У компании JetBrains есть доска задач [YouTrack](https://www.jetbrains.com/youtrack/) и билд сервер [TeamCity](https://www.jetbrains.com/teamcity/) 104 | 5. [GitLab](gitlab.com) - тут решение просто все в одном. 105 | 106 | Есть ещё много-много других инструментов, которые доступны и как сервисы, и как hosted решения. Но, так как вас всего 3 человека, то я бы посоветовал много не выдумывать и создать репозиторий на: 107 | 108 | 1. Если не планируете четвертого разработчика, то на [Github](https://github.com/pricing) приватный репозиторий для команды до 3 человек бесплатно. 109 | 2. Если будет до 5 человек, то на [BitBucket](https://bitbucket.org/product/pricing) до 5 человек бесплатно. 110 | 3. Если больше, то можно поглядеть на [Gitlab](https://about.gitlab.com/pricing/) 111 | -------------------------------------------------------------------------------- /interview/algorithms_basics.md: -------------------------------------------------------------------------------- 1 | # Алгоритмы 2 | 3 | Ниже я привожу материалы, что я использовал для подготовки к собеседованиям по алгоритмам в FAANG. 4 | 5 | Для начала вот самая полезная книга для подготовки к собеседованиям 6 | - Cracking the Coding Interview: 189 Programming Questions and Solutions 6th Edition 7 | https://www.amazon.com/Cracking-Coding-Interview-6th-Edition/dp/0984782850?SubscriptionId=0ENGV10E9K9QDNSJ5C82&tag=care02-20&linkCode=xm2&camp=2025&creative=165953&creativeASIN=0984782850 8 | 9 | Ищи последнюю редакцию. 10 | 11 | 12 | ## Если времени в обрез: 13 | 1) Самая короткая из полезных книг 14 | Алгоритмы 15 | С. Дасгупта, Х. Пападимитриу, У. Вазирани 16 | https://www.ozon.ru/context/detail/id/27676529/ 17 | 2) Онлайн задачники 18 | - https://www.hackerrank.com/ тут есть Interview Preparation Kit, который можно прорешать, с объяснениями 19 | - https://leetcode.com/ задачник с решениями 20 | Если освоишь книгу, Interview Preparation Kit и решишь задачек 100 (разных уровней), то считай, что база у тебя какая то будет. 21 | 22 | ## Если время всё ещё осталось, то 23 | 24 | Самая полезная из всех книг по алгоритмам, что я читал, очень хорошо дополнена курсами. 25 | 26 | Седжвик https://algs4.cs.princeton.edu/home/ (http://www.ozon.ru/context/detail/id/18319699/) 27 | 28 | Курсы по Седжвику (англ) от курсеры из 2 частей 29 | - https://www.coursera.org/course/algs4partI 30 | - https://www.coursera.org/course/algs4partII 31 | 32 | ## Если времени дофига 33 | 34 | ### Книги 35 | - Скиена http://www.ozon.ru/context/detail/id/6290126/ - Полезно для поннимания, как выбрать алгоритм для задачи 36 | - Кормен http://www.ozon.ru/context/detail/id/2429691/ - сложно и долго, только для специалистов по алгоритмам, содержит много теории, не является обязательной к прочтению. 37 | 38 | ### Курсы 39 | Онлайн русские 40 | - Алгоритмы: теория и практика. Методы https://stepik.org/course/217 41 | - Алгоритмы: теория и практика. Структуры данных https://stepik.org/course/1547 42 | 43 | ### Онлайн видосы 44 | Мне понравились видосы http://rutracker.org/forum/viewtopic.php?t=3994045 - автор и содержание то же, что на степике, только тут одни видосы, без презентаций, задач и тестов. 45 | ### Тестовые системы 46 | Можно порешать - потренироваться на задачках разной сложности. Я юзал вот эти (в порядке приоритета) 47 | - http://codeforces.ru/ 48 | - https://www.hackerrank.com/ 49 | - https://leetcode.com/ 50 | - http://acm.timus.ru/ 51 | --- 52 | ## Темы, что желательно покрыть 53 | - Big-O notation 54 | - Сортировки, пару простых квадратичных, пару за NLogN (обычно это Сортировка вставками, пузырьком, слиянием и быстрая сортировка). Уметь закодить и знать сложность и когда какую применять. Допольнительно к этому я смотрел сортировки кучей, Шелла, подсчетом, Radix сортировки типа LSD/MSD 55 | - Хеш таблицы, варианты имплементации, время работы операций. Быть способным написать свою примитивную, но работающую хеш таблицу 56 | - Деревья, ваианты обхода, n-арные деревья, trie - деревья, сбалансированные деревья поиска (то есть хотя бы знать что за, например, красно-черное древо / AVL / Сплей деревья, время работы операций и зачем вообще балансировать деревья). Никто не попросит тебя это имплементировать, но надо знать что это, зачем это и как быстро это работает и за счет чего оно так быстро работает. 57 | - Варианты обхода деревьев / графов, например BFS/DFS/PreOrder/InOrder/PostOrder - знать как имплементировать и что и когда используется. 58 | - Графы - must know, что такое, какие варианты представления в памяти, обходы графов (выше уже писал про DFS/BFS), сложность (время) на операции обхода графа 59 | - Остальные структуры данных, типа Стеки / Очереди / Деки / Связанные списки / Множества / Кучи и прочке. 60 | - NP задачи, что такое, как понять, что решаешь NP задачу, как их решать 61 | 62 | Также теорию надо закреплять практикой, необходимо решать задачи по каждой теме. Чтобы быть на более-менее нормальном уровне, нужно прорешать минимум задач 100, но желательно как можно больше. -------------------------------------------------------------------------------- /introduction.md: -------------------------------------------------------------------------------- 1 | # Введение 2 | 3 | Если вы ищете способ войти в IT с минимумом усилий и максимумом результатов, то найдёте здесь несколько советов, с чего можно начать. 4 | 5 | Обычно, первоначальная цель любого начинающего - это получение работы на уровне junior. 6 | 7 | К собеседованию надо готовиться как к проекту - собрать требования, разделы, что вам надо знать. Вам ничего не мешает поискать вакансии, там требования расписаны - вот вам и необходимые технологии. Информации по вопросам на собеседованиях море. Можете готовиться к конкретной вакансии, можете готовиться к массе собеседований. Выберите несколько вакансий, попробуйте пройти собеседования, запишите вопросы, что вам задавали, попросите от компании фидбек, что вам надо подучить. 8 | 9 | Junior разработчики испытывают сейчас жесткую конкуренцию. Поэтому, чем лучше вы подготовитесь, тем больше у вас шансов найти работу. Но если вы расчитываете, что потыкав палкой в java/python/etc пару месяцев, компании начнуть сами за вас бороться, вас ждет разочарование. 10 | 11 | Кругозор берется из опыта работы. Чем больше проектов у вас было, тем больше проблем вы решили. Вы можете также поискать другие источники кругозора - например, исследуя чужой код, исследуя SDK код, даже банально если вы на этом сайте будете решать вопросы, писать ответы, то вы также наберете с этого опыта. 12 | 13 | Если же вы строите себе какое то IT образование и у вас полно времени, то выбирайте онлайн курсы или ищите образовательную программу по вашей предпочитаемой специальности, стройте свой фундамент знаний. Без фундаментальных вещей ваше чтение документации не имеет особой пользы. Зная, как работают алгоритмы, структуры данных, память, процессор, имея представление об основах БД, архитектуре, паттернах, принциах, и т.д. вы не только сможете запомнить как и что написано в JDK или в каких то проектах, так ещё и осознаете почему оно написано именно так, а не иначе. 14 | -------------------------------------------------------------------------------- /links.md: -------------------------------------------------------------------------------- 1 | # Ссылки на полезные материалы 2 | - [Алгоритмы: теория и практика. Структуры данных](https://stepik.org/course/1547/promo) 3 | - [Базовый курс SQL](https://stepik.org/course/63054/promo) 4 | 5 | 6 | ## Книги 7 | 8 | 9 | ### Подборки книг 10 | 11 | 12 | ### [Stack Overflow на русском](https://ru.stackoverflow.com/a/454684/181472) 13 | 14 | - [Книги и учебные ресурсы по фундаментальным знаниям и навыкам разработчика](https://ru.stackoverflow.com/q/474415/) 15 | - [Книги и учебные ресурсы по Android](https://ru.stackoverflow.com/q/692639/) 16 | - [Книги и учебные ресурсы по C#](https://ru.stackoverflow.com/q/416584) 17 | - [Книги и учебные ресурсы по С++](https://ru.stackoverflow.com/q/454263) 18 | - [Где взять стандарт C++?](https://ru.stackoverflow.com/q/417797) 19 | - [Книги, документация, статьи и курсы по Go](https://ru.stackoverflow.com/q/436505) 20 | - [Книги и учебные ресурсы по HTML и CSS](https://ru.stackoverflow.com/q/924441/262779) 21 | - [Книги и учебные ресурсы по Java](https://ru.stackoverflow.com/q/416634) 22 | - [Книги и учебные ресурсы по JavaScript](https://ru.stackoverflow.com/q/474385) 23 | - [Книги и учебные ресурсы по Kotlin](https://ru.stackoverflow.com/questions/732964) 24 | - [Книги и учебные ресурсы по Linux](https://ru.stackoverflow.com/q/582544) 25 | - [Книги и учебные ресурсы по PHP](https://ru.stackoverflow.com/questions/458485) 26 | - [Книги и учебные ресурсы по Python](https://ru.stackoverflow.com/q/420125) 27 | - [Книги и учебные ресурсы по языку R](https://ru.stackoverflow.com/q/506597) 28 | - [Книги и учебные материалы по SVG](https://ru.stackoverflow.com/q/784137/213987) 29 | - [Книги и учебные ресурсы по проектированию БД: SQL && NoSQL](https://ru.stackoverflow.com/q/924356/262779) 30 | - [Книги и учебные ресурсы по Unity3D](https://ru.stackoverflow.com/q/609900) 31 | - [Книги по теме "Алгоритмы"](https://ru.stackoverflow.com/q/576507) 32 | - [Источники по безопасному (Secure) программированию](https://ru.stackoverflow.com/q/471356) 33 | - [Книги и учебные ресурсы по машинному обучению](https://ru.stackoverflow.com/q/678970) 34 | - [Книги и другие учебные материалы по тестированию](https://ru.stackoverflow.com/q/451404) 35 | 36 | 37 | ### [Stack Overflow на английском](https://ru.stackoverflow.com/a/454724/181472) 38 | 39 | - [What is the single most influential book every programmer should read](https://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read) 40 | - [Language Books/Tutorials for popular languages](https://stackoverflow.com/q/22873/10743113) 41 | - [How do I get started with Node.js](https://stackoverflow.com/questions/2353818/how-do-i-get-started-with-node-js/5511507) 42 | - [Best resources to learn JavaScript](https://stackoverflow.com/questions/11246/best-resources-to-learn-javascript) 43 | - [Good books for learning D3.js](https://stackoverflow.com/questions/16930748/a-good-book-for-learning-d3-js/16931395#16931395) 44 | - [The Definitive C++ Book Guide and List](https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list) 45 | 46 | -------------------------------------------------------------------------------- /meetups.md: -------------------------------------------------------------------------------- 1 | 2 | (25.09.2021) [Презентация по форматам хранения данных](https://disk.yandex.ru/i/jWXZpYQg3SeldA) 3 | 4 | (18.09.2021) [Особенности ОС Linux](https://youtu.be/AbmZ2hlDV6Y) 5 | 6 | [Code-style. Что это и зачем](https://youtu.be/A7Dk1AU6Y3g) 7 | 8 | (09.09.2021) [Решение задачи "Сортировка вставкой" с HackerRank](https://youtu.be/vl9sxs2DUQA) -------------------------------------------------------------------------------- /meetups/Docker/Кратко о Docker. 2021.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Entering-IT/documentation/aeaced424f65df913285833d4fc388ab94303922/meetups/Docker/Кратко о Docker. 2021.pdf -------------------------------------------------------------------------------- /meetups/Многопоточность и асинхронность/Многопоточность и асинхронность.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Entering-IT/documentation/aeaced424f65df913285833d4fc388ab94303922/meetups/Многопоточность и асинхронность/Многопоточность и асинхронность.docx -------------------------------------------------------------------------------- /meetups/Многопоточность и асинхронность/Многопоточность и асинхронность.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Entering-IT/documentation/aeaced424f65df913285833d4fc388ab94303922/meetups/Многопоточность и асинхронность/Многопоточность и асинхронность.pptx -------------------------------------------------------------------------------- /meetups/Профессиональное развитие в IT/Self_development_in_IT.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Entering-IT/documentation/aeaced424f65df913285833d4fc388ab94303922/meetups/Профессиональное развитие в IT/Self_development_in_IT.pptx -------------------------------------------------------------------------------- /python/roadmap.md: -------------------------------------------------------------------------------- 1 | # Программа обучения для Python разработчика 2 | https://docs.google.com/document/d/1cpoFC7MVIvmhtV_0-rpdsw3hFEvS_hEEj2iqx-d5Djg/edit# 3 | -------------------------------------------------------------------------------- /qa/interview_questions.md: -------------------------------------------------------------------------------- 1 | ## Вопросы и ответы для собеседования на тестировщика 2 | 3 | 4 | Основано на вопросах к QA компании ОЗОН 5 | Ссылка на изначальный документ: https://job.ozon.ru/events/33 6 | 7 | 8 | 9 | ### QA. Подготовка к интервью 10 | 11 | 🔹 **Теория тестирования** 12 | Мы ожидаем, что вы можете объяснить, каким образом оптимизировать тестовое покрытие, используя техники тест-дизайна, какие бывают методы, этапы и метрики тестирования. А если вы знаете, что означают термины «flaky-тесты», «shift-left testing» и какой стороной нужно повернуть пирамиду тестирования, то нам будет проще разговаривать на одном языке :) 13 | 14 | ❗️ В зависимости от задач на конкретной позиции мы можем спрашивать вас по backend-, frontend- и mobile-тестированию. 15 | 16 | 🔹 **Backend-тестирование** 17 | Бэкенд Ozon — это микросервисная архитектура со сложной бизнес-логикой, поэтому для нас важно, чтобы вы представляли: 18 | 19 | - как работают сетевые протоколы (у нас используется HTTP/GRPC); 20 | 21 | - что происходит в тот момент, когда вы вбиваете в поисковую строку браузера запрос, и куда он отправляется дальше, как устроено взаимодействие между клиентом и сервером; 22 | 23 | - какие существуют методы и коды ответов; 24 | 25 | - что такое cookie. 26 | 27 | 28 | 🔹 **Frontend-тестирование** 29 | Основной сайт ozon.ru — это нагруженное приложение, написанное на Node.js и Vue, реализующее множество пользовательских механик. Кроме него, есть не уступающий ему по сложности B2C кабинет для наших селлеров и десятки других проектов. Мы ожидаем: 30 | 31 | - навыки кроссбраузерного тестирования; 32 | 33 | - умение заглянуть в консоль разработчика в браузере и найти там нужную для воспроизведения информацию; 34 | 35 | - hands-on в автоматизации: уверенное использование локаторов, декомпозиции кода с использованием Page Object и понимания, какие возможности дают и чем отличаются Chrome DevTools и WebDriver протоколы. 36 | 37 | 38 | 39 | 🔹 **Mobile-тестирование** 40 | 41 | На мобильные приложения приходится большинство заказов в Ozon, поэтому мы много внимания уделяем как их разработке, так и тестированию. От вас мы ожидаем понимание: 42 | 43 | - как проверять UI в мобильном приложении; 44 | 45 | - почему баги могут встречаться на специфических устройствах; 46 | 47 | - как работать с трафиком, который проходит через мобильное устройство; 48 | 49 | - какие есть полезные для тестирования возможности от платформ; 50 | 51 | - как получить артефакты, которые помогут в исправлении багов. 52 | 53 | 54 | 🔹 **Программирование** 55 | От каждого тестировщика в Ozon мы ждём участия в написании автотестов. Для бэкенда мы пишем автотесты на языке сервиса (Go, С#) или на Python. Но если вы имеете опыт написания тестов на другом языке и готовы разобраться с нашим стеком, мы поделимся своим опытом. На интервью мы спрашиваем о структурах данных и методах работы с ними, проверяем знание стандартной библиотеки. Также важно умение работать с фреймворком для написания тестов и его инструментарием. Например, для Python это обязательно будут Pytest и фикстуры: важно понимать, как их запускать, отлаживать и настраивать. 56 | 57 | 58 | 🔹 **Базы данных** 59 | В Ozon используются разнообразные базы данных: PostgreSQL, ClickHouse, Cassandra, Redis и другие. Необязательно разбираться в специфике каждой из них (у разных команд свои требования), однако наверняка потребуется знание основных концепций и умение выполнить SQL-запрос как минимум с запросом данных из нескольких таблиц. Важно понимать, что такое индекс, зачем нужны транзакции и почему не нужно делать count(*) на больших таблицах. 60 | 61 | 62 | 🔹 **CI/CD** 63 | Большой объём релизов Ozon был бы невозможен без налаженного конвейера доставки релизов в production-окружение. Принципы, которых мы придерживаемся, позволяют нам поддерживать высокий уровень качества. QA активно участвуют в этом процессе, поэтому для нас важно, чтобы вы: 64 | 65 | - умели работать с Git. Все тесты должны быть написаны с тем расчётом, что они рано или поздно будут запускаться в пайплайне, а работа с кодом обязательно подразумевает работу с системой контроля версий. Как минимум нужно уметь отличать push от pull, знать, как создать/переключиться на новую ветку и уметь решать конфликты, возникающие при слиянии; 66 | 67 | - умели работать с консолью как минимум на уровне взаимодействия с папками и директориями; 68 | 69 | - вся наша инфраструктура живёт в docker-контейнерах. У нас есть выделенная команда релиз-инженеров, которая занимается задачами деплоя, однако умение заглянуть в контейнер за логами может пригодиться. 70 | -------------------------------------------------------------------------------- /qa/links.md: -------------------------------------------------------------------------------- 1 | # Ссылки на полезные материалы 2 | 3 | По мотивам статьи "Как обучить джунов QA за 3 дня (сборник материалов)" 4 | Ссылка на изначальный документ: https://habr.com/ru/company/hflabs/blog/596993/ 5 | 6 | ### Содержание 7 | 1. [Процессы](#1-процессы) 8 | 9 | 2. [Идеи тестов](#2-идеи-тестов) 10 | 11 | 3. [Чек-листы](#3-чек-листы) 12 | 13 | 4. [Тест-кейсы](#4-тест-кейсы) 14 | 15 | 5. [Тест-дизайн](#5-тест-дизайн) 16 | 17 | 6. [Баг-трекинг](#6-баг-трекинг) 18 | 19 | 7. [Другое полезное](#7-другое-полезное) 20 | 21 | ### 1. Процессы 22 | **Видео — общее** 23 | 24 | 1. [Клиент-серверная архитектура в картинках (Ольга Назина)](https://youtu.be/wLHuviTWnuY). 25 | 26 | 2. [Тестировщик с нуля / Урок 11. Клиент-серверная архитектура. Веб-сайт, веб-приложение и веб-сервис (Артем Русов)](https://youtu.be/00z-6hyIvG0). 27 | 28 | **Видео — API** 29 | 30 | 1. [Введение в SOAP и REST: что это и с чем едят (Ольга Назина)](https://youtu.be/2YWfJHDNQy0). 31 | 32 | 2. [Тестирование API простыми словами за 8 минут / Тестировщик API (Артем Русов)](https://youtu.be/kUPWQMalWNk). 33 | 34 | 3. [Тестировщик с нуля / Урок 18. Как тестировать API с помощью Postman, SoapUI. Отличия GET и POST (Артем Русов)](https://youtu.be/VqjaDULOYOM). 35 | 36 | 4. [Как отправить REST-запрос за 5 минут (Ольга Назина)](https://youtu.be/U7-8ZmCBiPI). 37 | 38 | 5. [Как отправить SOAP-запрос в Soap Ui (Ольга Назина)](https://youtu.be/00c19IBwsqQ). 39 | 40 | 6. [УРОК 1 / Postman для тестировщика. С чего начать? (Артем Русов)](https://youtu.be/Qe-kDHq-Vw4). 41 | 42 | 7. [Пишем первый автотест в Postman (Ольга Назина)](https://youtu.be/ymuLE76ZXaM). 43 | 44 | **Статьи — общее** 45 | 46 | 1. [Что такое VCS (система контроля версий)](https://habr.com/ru/post/552872/). 47 | 48 | 2. [Что такое База Данных (БД)](https://habr.com/ru/post/555760/). 49 | 50 | 3. [Что такое CI (Continuous Integration)](https://habr.com/ru/post/508216/). 51 | 52 | 4. [Клиент-серверная архитектура в картинках](https://habr.com/ru/post/495698/). 53 | 54 | **Статьи — API** 55 | 56 | 1. [Что такое API](https://habr.com/ru/post/464261/). 57 | 58 | 2. [Что такое JSON](https://habr.com/ru/post/554274/). 59 | 60 | 3. [Что такое XML](https://habr.com/ru/post/524288/). 61 | 62 | **Квест из HFLabs** 63 | 64 | [Помогаем выплыть: как ввести новичков в сложный проект](https://habr.com/ru/company/hflabs/blog/420967/). 65 | 66 | ### 2. Идеи тестов 67 | **Видео** 68 | 69 | 1. [Как накидать тестов на что-нибудь (Ольга Назина)](https://youtu.be/cmlI5aJxdwE). 70 | 71 | 2. [Тестирование карандаша / Как тестировать карандаш (Артем Русов)](https://youtu.be/qpSEsGEGYg8). 72 | 73 | **Статьи** 74 | 75 | 1. [Где брать идеи для тестов (подборка полезных ссылок)](https://habr.com/ru/post/524784/). 76 | 77 | ### 3. Чек-листы 78 | **Видео** 79 | 80 | 1. [Лекция 5. Тестовая документация. Тест-план, чек-листы, отчёты по тестированию (Алексей Петров)](https://youtu.be/cHysXyQrqAw). 81 | 82 | 2. [Чек-листы: полная лекция из ШНАТ (Ольга Назина)](https://youtu.be/UOhg7moss9U). 83 | 84 | **Статьи** 85 | 86 | 1. [Зачем в чек-листе нужны примеры](https://okiseleva.blogspot.com/2020/09/blog-post.html). 87 | 88 | 2. [Какой результат писать в чек-листе](https://okiseleva.blogspot.com/2015/03/blog-post_33.html). 89 | 90 | ### 4. Тест-кейсы 91 | **Видео** 92 | 93 | 1. [Лекция 5. Тестовая документация. Тест-план, чек-листы, отчёты по тестированию (Алексей Петров)](https://youtu.be/cHysXyQrqAw). 94 | 95 | 2. [Тест-кейсы: полная лекция из ШНАТ (Ольга Назина)](https://youtu.be/0xuOOlhb5SQ). 96 | 97 | **Статьи** 98 | 99 | 1. [Что такое тест-кейс и как его писать](https://okiseleva.blogspot.ru/2014/08/blog-post.html). 100 | 101 | 2. [Тест-кейс проверяет, а не доверяет](https://okiseleva.blogspot.ru/2018/02/blog-post_49.html)! 102 | 103 | 3. [Тест должен быть конкретным](http://okiseleva.blogspot.com/2018/04/blog-post_12.html)! 104 | 105 | 4. [У теста есть результат](https://okiseleva.blogspot.com/2020/06/blog-post_25.html). 106 | 107 | И другие из главы 2 [онлайн-книги по тестированию](http://testbase.ru/book-beginner). 108 | 109 | ### 5. Тест-дизайн 110 | **Видео — полные лекции** 111 | 112 | 1. [Тестировщик с нуля / Урок 9. Техники тест-дизайна. Классы эквивалентности и граничные значения (Артем Русов)](https://youtu.be/HJPF5qJx7jg). 113 | 114 | 2. [Лекция 6. Тест-дизайн. Классы эквивалентности. Тест-кейсы и тестовые матрицы (Алексей Петров)](https://youtu.be/R0l9ncLEdCQ). 115 | 116 | **Видео — кусочки лекций** 117 | 118 | 1. [Что такое тест-дизайн (Ольга Назина)](https://youtu.be/qAbcy6tUhFQ). 119 | 120 | 2. [Что такое классы эквивалентности (Ольга Назина)](https://youtu.be/YinFxIYfiJA). 121 | 122 | 3. [Эффект Золушки для выделения классов эквивалентности](https://youtu.be/lkoSvXR8mHE). 123 | 124 | **Видео — примеры выделения классов эквивалентности** 125 | 126 | 1. [Тест-дизайн в тестировании ПО. Задача "Треугольник" (Илья Комендантов)](https://youtu.be/m0Rf2pqsyfw). 127 | 128 | 2. [HFLabs Education Day. Тест-дизайн на примере треугольника (Ольга Назина)](https://youtu.be/4PgrF-n80KE). 129 | 130 | 3. [Классы эквивалентности в турнире Empires & Puzzles](https://youtu.be/zHavcR7JzLk). 131 | 132 | **Статьи — классы эквивалентности** 133 | 134 | 1. [Классы эквивалентности: будни Золушки](http://okiseleva.blogspot.ru/2015/07/blog-post_87.html). 135 | 136 | 2. [Класс эквивалентности «Ноль-не ноль»](http://okiseleva.blogspot.ru/2016/12/blog-post_15.html). 137 | 138 | 3. [Классы эквивалентности для строки, которая обозначает дату](http://okiseleva.blogspot.ru/2018/04/blog-post_14.html). 139 | 140 | 4. [Классы эквивалентности для имен](https://okiseleva.blogspot.com/2019/10/blog-post_20.html). 141 | 142 | 5. [Классы эквивалентности для населенных пунктов в адресах](https://okiseleva.blogspot.com/2019/10/blog-post_30.html). 143 | 144 | 6. [Чек-лист для тестирования числового поля](https://habr.com/ru/post/525192/). 145 | 146 | **Статьи — границы** 147 | 148 | 1. [Типы границ на примере стиральной машинки](https://okiseleva.blogspot.ru/2018/04/blog-post_19.html). 149 | 150 | 2. [Как найти границы на клиенте и сервере](https://habr.com/ru/post/510458/). 151 | 152 | **Статьи — инструменты** 153 | 154 | 1. [Как сгенерить большую строку, инструменты](https://okiseleva.blogspot.ru/2015/08/blog-post_8.html). 155 | 156 | 2. [Мнемоника БМВ для поиска граничных значений](https://okiseleva.blogspot.com/2018/08/blog-post_28.html). 157 | 158 | ### 6. Баг-трекинг 159 | **Видео — полные лекции** 160 | 161 | 1. [Тестировщик с нуля / Урок 10. Отчет о дефекте (баг-репорт) в Jira. Severity и Priority. ЖЦ дефекта (Артем Русов)](https://youtu.be/6YrgKBTzb5o). 162 | 163 | 2. [Лекция 8. Багтрекинг. Как, зачем, для чего и почему? (Алексей Петров)](https://youtu.be/LWtPwlAllMg). 164 | 165 | **Видео — выдержки** 166 | 167 | 1. [Типичные баги в ПО (Ольга Назина)](https://youtu.be/3-jTLRvw7jc). 168 | 169 | 2. [Плейлист по баг-трекингу (Ольга Назина)](https://www.youtube.com/playlist?list=PLzy4cPXOwbY5M9fVMyWAqY3vZlFAAx8wC). 170 | 171 | **Статьи — общее** 172 | 173 | 1. [Как искать баги](http://testbase.ru/bugs). 174 | 175 | 2. [Когда мнение миллионов нытиков — не баг](https://okiseleva.blogspot.com/2019/10/blog-post_4.html). 176 | 177 | **Статьи — локализация** 178 | 179 | 1. [Принцип лопаты](https://okiseleva.blogspot.com/2018/10/blog-post_89.html). 180 | 181 | 2. [Метод бисекционного деления в тестировании](https://habr.com/ru/post/468087/). 182 | 183 | **Статьи — оформление** 184 | 185 | 1. [Как заводить задачи в баг-трекер](http://okiseleva.blogspot.ru/2015/02/blog-post_19.html). 186 | 187 | 2. [Эмоций в баге быть не должно](https://okiseleva.blogspot.com/2019/01/blog-post_13.html)! 188 | 189 | 3. [4 типичные ошибки оформления бага новичком](https://okiseleva.blogspot.com/2018/09/4.html). 190 | 191 | 4. [Шаблон бага](http://okiseleva.blogspot.com/2015/05/blog-post_25.html). 192 | 193 | 5. [Шаблон улучшения](http://okiseleva.blogspot.com/2015/10/blog-post_16.html). 194 | 195 | **Статьи — шаги, правила оформления** 196 | 197 | 1. [Нужна авторизация? Дай данные](https://okiseleva.blogspot.com/2019/09/blog-post_2.html). 198 | 199 | 2. [Воспроизводится ли баг по твоим шагам? Проверь](https://okiseleva.blogspot.com/2019/07/blog-post_28.html)! 200 | 201 | 3. [Опиши и приложи](https://okiseleva.blogspot.com/2019/11/blog-post.html). 202 | 203 | 4. [Не пишите в баге «Ввести 6,9»](https://okiseleva.blogspot.com/2016/06/69.html)! 204 | 205 | **Статьи — результат** 206 | 207 | 1. [В баге есть фактический и ожидаемый результаты](https://okiseleva.blogspot.com/2020/01/blog-post_9.html). 208 | 209 | 2. [Сначала фактический результат в баге, потом ожидаемый](https://okiseleva.blogspot.com/2020/02/blog-post.html). 210 | 211 | 3. [Паттерны и антипаттерны обоснования задач](https://okiseleva.blogspot.com/2019/01/blog-post_3.html). 212 | 213 | **Статьи — аттачи** 214 | 215 | 1. [Первое правило аттачей в багах — говорящее название](https://okiseleva.blogspot.com/2019/08/blog-post_97.html)! 216 | 217 | 2. [Вложил аттач? Сошлись на него по тексту бага](https://okiseleva.blogspot.com/2020/03/blog-post_18.html). 218 | 219 | 3. [Как грамотно вложить скриншот в задачу](https://okiseleva.blogspot.com/2019/09/blog-post.html). 220 | 221 | И другие ссылки из главы 5 онлайн-книги http://testbase.ru/book-beginner. 222 | 223 | ### 7. Другое полезное 224 | 1. [Хороший сайт с большим количеством различных материалов](http://testbase.ru/) 225 | 2. [Сборник теории 1](http://www.protesting.ru/), [cборник теории 2](https://qastart.by/). 226 | 3. [Видео об интеграционном тестировании](https://www.youtube.com/watch?v=dflmpqh_oRc). 227 | 4. [Заголовки запросов и ответов в HTTP](https://code.tutsplus.com/ru/tutorials/http-headers-for-dummies--net-8039). 228 | 5. [Про REST API](https://highload.today/rest-api-soap/). 229 | 6. [Библия QA](https://vladislaveremeev.gitbook.io/qa_bible/) (очень много материалов), ([гит проекта](https://github.com/VladislavEremeev/QA_bible)). 230 | 7. [Лекции Алексея Петрова целиком](https://habr.com/ru/company/vk/blog/260105/). Выше в разделах есть ссылки на отдельные лекции, а тут они все собраны в один курс. Удобно. 231 | 8. [Ютуб-канал Артема Русова](https://www.youtube.com/channel/UCiDbqnoBNx3pRHyYAgrnwBg). Новички из чата https://t.me/qajuniors активно хвалят этот канал как лучший из бесплатный материалов. 232 | + в составе этого канала есть [плейлист "Тестировщик с нуля"](https://www.youtube.com/playlist?list=PLKbJd47Kcbju2Vhi-FL7AI14vItVmGYk-), - освещено большинство тем 233 | 9. [Ютуб-канал Ольги Назиной](https://www.youtube.com/c/okiseleva). Там она публикует кусочки из своих тренингов и просто полезняшки по разным темам тестирования. 234 | 235 | 236 | **Книги:** 237 | 238 | 1. Ольга Назина, «Что такое тестирование. Курс молодого бойца» — подробно разобраны все темы, кроме процессов. 239 | 240 | 2. Роман Савин, «Тестирование dot com» — кратко о том же, зато быстро читается. 241 | 242 | 3. Святослав Куликов, «Тестирование программного обеспечения. Базовый курс» — тоже подробно разобраны все темы, но немного другой стиль повествования. 243 | 244 | 245 | **Telegram-чаты:** 246 | 1. https://t.me/qa-ru - общий чат по тестированию 247 | 2. https://t.me/qajuniors - чат для бесед и вопросов от джуниоров 248 | 3. https://t.me/qa_bad_company - отзывы о компаниях от тестировщиков 249 | 4. https://t.me/qa_fin - разговоры о финансовой составляющей работы тестировщика 250 | 5. https://t.me/qa_automation - вопросы об автоматизации тестирования без выраженной языковой направленности 251 | 6. https://t.me/testing_in_python - автоматизация на python 252 | 7. https://t.me/js_for_testing - сообщество js/ts-тестировщиков 253 | 8. https://t.me/qa_load - чат о тестировании производительности 254 | -------------------------------------------------------------------------------- /qa/testing_theory.md: -------------------------------------------------------------------------------- 1 | ## Теория тестирования 2 | - [Что такое тестирование](#Что-такое-тестирование) 3 | - [Виды тестирования](#Виды-тестирования) 4 | - [STLC и SDLC](#STLC-и-SDLC) 5 | - [Техники тест-дизайна](#техники-тест-дизайна) 6 | - [Методы тестирования](#Методы-тестирования) 7 | - [Этапы тестирования](#Этапы-тестирования) 8 | - [Метрики тестирования](#Метрики-тестирования) 9 | - [Содержание баг репорта](#Содержание-баг-репорта) 10 | - [Жизненный цикл дефекта](#Жизненный-цикл-дефекта) 11 | - [Приоритет и серьёзность бага](#Приоритет-и-серьёзность-бага) 12 | - [Flaky-тесты](#Flaky-тесты) 13 | - [Shift-left testing](#Shift-left-testing) 14 | - [Пирамида тестирования](#Пирамида-тестирования) 15 | 16 | ## Backend-тестирование 17 | - [Как работают сетевые протоколы (HTTP/GRPC)](#Как-работают-сетевые-протоколы-(HTTP/GRPC)) 18 | - [Что происходит в тот момент, когда вы вбиваете в поисковую строку браузера запрос, и куда он отправляется дальше, как устроено взаимодействие между клиентом и сервером](#Что-происходит-в-тот-момент,-когда-вы-вбиваете-в-поисковую-строку-браузера-запрос,-и-куда-он-отправляется-дальше,-как-устроено-взаимодействие-между-клиентом-и-сервером) 19 | - [Что такое REST](#Что-такое-REST) 20 | - [Методы и коды ответов](#Методы-и-коды-ответов) 21 | - [Что такое cookie](#Что-такое-cookie) 22 | 23 | ## Frontend-тестирование 24 | - [Что такое кроссбраузерное тестирование](#Что-такое-кроссбраузерное-тестирование) 25 | - [Как пользоваться консолью разработчика в браузере](#Как-пользоваться-консолью-разработчика-в-браузере) 26 | - [Заголовки запроса/ответа](#Заголовки-запроса/ответа) 27 | - [Как использовать локаторы](#Как-использовать-локаторы) 28 | - [Декомпозиции кода с использованием Page Object](#Декомпозиции-кода-с-использованием-Page-Object) 29 | - [Какие возможности дают и чем отличаются Chrome DevTools и WebDriver протоколы](#Какие-возможности-дают-и-чем-отличаются-Chrome-DevTools-и-WebDriver-протоколы) 30 | 31 | ## Mobile-тестирование 32 | - [Как проверять UI в мобильном приложении](#Как-проверять-UI-в-мобильном-приложении) 33 | - [Почему баги могут встречаться на специфических устройствах](#Почему-баги-могут-встречаться-на-специфических-устройствах) 34 | - [Как работать с трафиком, который проходит через мобильное устройство](#Как-работать-с-трафиком,-который-проходит-через-мобильное-устройство) 35 | - [Какие есть полезные для тестирования возможности от платформ](#Какие-есть-полезные-для-тестирования-возможности-от-платформ) 36 | - [Как получить артефакты, которые помогут в исправлении багов](#Как-получить-артефакты,-которые-помогут-в-исправлении-багов) 37 | 38 | ## Программирование 39 | - [Структуры данных и методы работы с ними](#Структуры-данных-и-методы-работы-с-ними) 40 | - [Pytest](#Pytest) 41 | - [Фикстуры: как их запускать, отлаживать и настраивать](#Фикстуры:-как-их-запускать,-отлаживать-и-настраивать) 42 | 43 | ## Базы данных 44 | - [Что такое индекс](#Что-такое-индекс) 45 | - [Зачем нужны транзакции](#Зачем-нужны-транзакции) 46 | - [Почему не нужно делать count(\*) на больших таблицах](#Почему-не-нужно-делать-count(\*)-на-больших-таблицах) 47 | 48 | ## CI/CD 49 | - [Git](#Git) 50 | - [Консоль](#Консоль) 51 | - [Docker](#Docker) 52 | 53 | ## Полезные ссылки 54 | 55 | 56 | ## Теория тестирования 57 | ### Что такое тестирование 58 | --- 59 | **Тестирование программного обеспечения** - проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis). 60 | 61 | **Верификация** - оценка системы или её части на текущий момент. Т.е. проверка выполнения целей, сроков, задач по разработке проекта, определенных в начале текущей фазы. 62 | 63 | **Валидация** - определение соответствия разрабатываемого ПО требованиям. Т.е. итоговое подтверждение о готовности продукта, продукт соответствует требованиям заказчика. 64 | ### Виды тестирования 65 | --- 66 | Все виды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы: 67 | - функциональные 68 | - нефункциональные 69 | - связанные с изменениями 70 | 71 | **Функциональные виды тестирования** 72 | Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: 73 | - **компонентном или модульном** - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция, небольшие библиотеки, отдельные части приложения. Как правило их можно исследовать изолированно друг от друга 74 | - **интеграционном** - тестируются интерфейсы между компонентами, подсистемами или системами. Направлено на проверку взаимодействия между несколькими частями приложения (каждая из которых была проверена на модульной стадии тестирования) 75 | - **системном** - тестируется интегрированная система на её соответствие требованиям. Направлено на проверку всего приложения, как единого целого, собранного из частей, проверенных на модульном и интеграционном уровнях. 76 | - **приемочном** - это формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится, с целью определения удовлетворяет ли система приемочным критериям и вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет. Приемочное тестирование выполняется на основании набора типичных тестовых случаев и сценариев, разработанных на основании требований к данному приложению. 77 | 78 | **Функциональное тестирование** - это вид тестирования, при котором выявляется некорректная /неправильная работа функционала программы. Проверка функций и характеристик разрабатываемого ПО. 79 | **Тестирование безопасности** - проверка надежности системы от возможных рисков и угроз (потеря, конфиденциальность, целостность и доступность данных). 80 | **Тестирование взаимодействия** - это тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости и интеграционное тестирование. 81 | 82 | **Нефункциональные виды тестирования** 83 | Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает. Далее перечислены основные виды нефункциональных тестов: 84 | 85 | Все виды тестирования производительности: 86 | нагрузочное тестирование (Performance and Load Testing) 87 | стрессовое тестирование (Stress Testing) 88 | тестирование стабильности или надежности (Stability / Reliability Testing) 89 | объемное тестирование (Volume Testing) 90 | Тестирование установки (Installation testing) 91 | Тестирование удобства пользования (Usability Testing) 92 | Тестирование на отказ и восстановление (Failover and Recovery Testing) 93 | Конфигурационное тестирование (Configuration Testing) 94 | Тестирование безопасности (Security and Access Control Testing) 95 | Связанные с изменениями виды тестирования 96 | После проведения необходимых изменений, таких как исправление бага/дефекта, программное обеспечение должно быть пере тестировано для подтверждения того факта, что проблема была действительно решена. Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта: 97 | 98 | Дымовое тестирование (Smoke Testing) 99 | Регрессионное тестирование (Regression Testing) 100 | Тестирование сборки (Build Verification Test) 101 | Санитарное тестирование или проверка согласованности/исправности (Sanity Testing) 102 | ### STLC и SDLC 103 | --- 104 | ### Техники тест-дизайна 105 | --- 106 | ### Методы тестирования 107 | --- 108 | ### Этапы тестирования 109 | --- 110 | ### Метрики тестирования 111 | --- 112 | ### Содержание баг репорта 113 | --- 114 | ### Жизненный цикл дефекта 115 | --- 116 | ### Приоритет и серьёзность бага 117 | --- 118 | ### Flaky-тесты 119 | --- 120 | ### Shift-left testing 121 | --- 122 | ### Пирамида тестирования 123 | --- 124 | 125 | ## Backend-тестирование 126 | ### Как работают сетевые протоколы (HTTP/GRPC) 127 | ### Что происходит в тот момент, когда вы вбиваете в поисковую строку браузера запрос, и куда он отправляется дальше, как устроено взаимодействие между клиентом и сервером 128 | ### Что такое REST 129 | ### Методы и коды ответов 130 | ### Что такое cookie 131 | 132 | ## Frontend-тестирование 133 | ### Что такое кроссбраузерное тестирование 134 | ### Как пользоваться консолью разработчика в браузере 135 | ### Заголовки запроса/ответа 136 | ### Как использовать локаторы 137 | ### Декомпозиции кода с использованием Page Object 138 | ### Какие возможности дают и чем отличаются Chrome DevTools и WebDriver протоколы 139 | 140 | ## Mobile-тестирование 141 | ### Как проверять UI в мобильном приложении 142 | ### Почему баги могут встречаться на специфических устройствах 143 | ### Как работать с трафиком, который проходит через мобильное устройство 144 | ### Какие есть полезные для тестирования возможности от платформ 145 | ### Как получить артефакты, которые помогут в исправлении багов 146 | 147 | ## Программирование 148 | ### Структуры данных и методы работы с ними 149 | ### Pytest 150 | ### Фикстуры: как их запускать, отлаживать и настраивать 151 | 152 | ## Базы данных 153 | ### Что такое индекс 154 | ### Зачем нужны транзакции 155 | ### Почему не нужно делать count(\*) на больших таблицах 156 | 157 | ## CI/CD 158 | ### Git 159 | ### Консоль 160 | ### Docker 161 | -------------------------------------------------------------------------------- /resources/0intro.md: -------------------------------------------------------------------------------- 1 | # Основные направления ресурсов 2 | - [C++](C++.md) 3 | - [C#/.NET](CSharp-.NET.md) 4 | - [Python](python.md) 5 | - [Алгоритмы](algo.md) 6 | - [Собеседования](interviews.md) 7 | - [Базы данных](databases.md) -------------------------------------------------------------------------------- /resources/C++.md: -------------------------------------------------------------------------------- 1 | # Junior 2 | 3 | # Middle 4 | [Скотт Майерс - Эффективное использование C++. 55 верных советов улучшить структуру и код ваших программ](https://www.ozon.ru/product/effektivnoe-ispolzovanie-c-55-vernyh-sposobov-uluchshit-strukturu-i-kod-vashih-programm-139822616) 5 | Читать стоит как только вы добрались до уровня Middle, т.к. если позже - вы уже знаете больше половины написанного, раньше - будет ничего не понятно. 6 | Полезна как "настольная книга", чтобы быстро найти пример как лучше писать тот или иной функционал (например, конструктор копирования) 7 | 8 | 9 | # Senior -------------------------------------------------------------------------------- /resources/CSharp-.NET.md: -------------------------------------------------------------------------------- 1 | Полезные ссылки по C# и .NET 2 | 3 | # Junior 4 | - [Видео курс по разработке на C#](https://www.youtube.com/c/RomanTrufanovDev) 5 | # Middle 6 | - [ProblemBook.NET - Задачник по дотнету](https://andreyakinshin.gitbook.io/problembookdotnet/) 7 | # Senior 8 | 9 | -------------------------------------------------------------------------------- /resources/algo.md: -------------------------------------------------------------------------------- 1 | # Заголовок 2 | - [Грокаем алгоритмы](https://www.ozon.ru/product/grokaem-algoritmy-illyustrirovannoe-posobie-dlya-programmistov-i-lyubopytstvuyushchih-211433683/?sh=cUHpbik2) 3 | Простая для понимания книга описывающая работу основных алгоритмов, включая их сложность и используемые структуры данных. Начинать стоит с неё 4 | - -------------------------------------------------------------------------------- /resources/databases.md: -------------------------------------------------------------------------------- 1 | - [Видео по Astra DB](https://youtu.be/Ae4GABykRoM) 2 | астра - это кассандра*, но головная боль обслуживания у моих коллег. При небольших-средних нагрузках можно использовать бесплатно, расходы до 25 баксов в месяц покрывает датастакс. А это довольно много, типа несколько десятков миллионов запросов в месяц, около сорока гигабайт дискогого пространства и т.д. 3 | -------------------------------------------------------------------------------- /resources/interviews.md: -------------------------------------------------------------------------------- 1 | # Общее 2 | - [Cracking the Coding Interview (Карьера программиста)](https://www.ozon.ru/product/karera-programmista-6-e-izdanie-227305313) 3 | У меня стоит в очереди, на сколько я понял по рекомендациям - здесь описан общий подход к прохождению собеседований. 4 | Список возможных общих вопросов 5 | Расскажите о проекте? Как устроен продукт? 6 | Когда начался? Какие временные рамки? На какой стадии находится? 7 | Какой стек технологий применяется в проекте? Какие технологии планируются к добавлению в проект? 8 | Сколько человек задействовано на проекте? Когда следующий релиз? А что будет, если завтра прекратится финансирование? 9 | Кто заменяет членов команды, когда они отсутствуют? 10 | Как долго члены команды работают здесь? 11 | Откуда пришла команда? 12 | Людей с какими навыками вам не хватает в команде? 13 | Кто в команде: роли, кол-во человек? Будет ли команда расширяться? 14 | Какую задачу или проблему придется решать на новой позиции в самом начале работы? Какие ресурсы есть для этого? 15 | Как измеряется продуктивность? Как определяются достижения? 16 | Что я буду делать в первый месяц на работе? Какие артефакты ждут от ___________? 17 | Каких результатов ожидает руководитель к концу испытательного срока? 18 | 19 | # Вопросы по языкам 20 | ## Python 21 | ### Junior 22 | 23 | ### Middle 24 | 25 | ### Senior 26 | 27 | ## Java 28 | - [Вопросы с собеседований по Java](https://github.com/enhorse/java-interview) 29 | Plain list без разделения на грейды 30 | ## C++ 31 | 32 | ## C#/.NET 33 | - [Вопросы с собеседований по грейдам](https://docs.google.com/spreadsheets/d/1xRdCFNC4iffknGyiUCVYnKYdbkNFt2TUn-iFecOCELo/edit#gid=677176728) 34 | - 35 | -------------------------------------------------------------------------------- /resources/python.md: -------------------------------------------------------------------------------- 1 | # Junior 2 | - [Марк Лутц - Изучаем Python](https://www.ozon.ru/product/izuchaem-python-tom-1-156082566) 3 | Must-have книга для входящих в Python. 4 | # Middle 5 | - [Искусство написания циклов на Python](https://habr.com/ru/company/vdsina/blog/560916/) 6 | # Senior 7 | -------------------------------------------------------------------------------- /z_attachments/placeholder.txt: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Entering-IT/documentation/aeaced424f65df913285833d4fc388ab94303922/z_attachments/placeholder.txt -------------------------------------------------------------------------------- /z_attachments/Английский язык.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Entering-IT/documentation/aeaced424f65df913285833d4fc388ab94303922/z_attachments/Английский язык.pptx -------------------------------------------------------------------------------- /z_attachments/Особенности IT в Польше.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Entering-IT/documentation/aeaced424f65df913285833d4fc388ab94303922/z_attachments/Особенности IT в Польше.pptx --------------------------------------------------------------------------------