У нас лайв, подключайтесь к трансляции 🍻
https://youtu.be/f9ftUwV2Erc

Опубликовали новую статью на Хабре — рассказываем, как написать хорошие требования к ПО. Алёна, наш бизнес-аналитик, собрала распространенные ошибки при написании критериев приемки к пользовательской истории, с примерами и антипримерами. 🧚🏿‍♂️

Избегаем повторений, не используем слова с субъективной оценкой, — и еще 9 рекомендаций по проверке качества требований уже в свежем материале!

Читайте по ссылке: https://habr.com/ru/post/684416/

🤔 Как развеять страх перед программированием и начать что-то делать?

Привет! На связи Рин, Java-разработчик Red Collar. Заметила, что многие так и оставляют свою мечту стать программистом или кем-нибудь еще, потому что понятия не имеют, как подступиться к процессу обучения, чтобы и толк был, и тошнить не начало.

Большие подробные книги, туториалы на 9000 часов на ютубе — это все, конечно, классно, но какова эффективность такого способа обучения? Спойлер: 2%, если параллельно не отрабатывать теорию на практике.

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

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

Так же работает с любой другой задачей всякой степени сложности. Поэтому не нужно бояться ставить перед собой, на первый взгляд, непосильные задачи. Их тоже можно декомпозировать на задачи простые, разобраться в том, как решать каждую из них, и так решить одну большую. Но не нужно сразу набрасываться на сложные задачи. Хотите написать бэкенд? Тоже декомпозируйте, двигайтесь от сложного к простому. 😎

Рассмотрим в качестве примера бэкенд на Spring Boot.

🤯 Каков план действий, если вообще ничего не понятно?

Базовое приложение на Spring Boot, собранное через Spring Initializr, не содержит в себе ничего, кроме класса, благодаря которому оно стартует. Вроде бы ничего интересного, на первый взгляд. А почему оно вообще стартует как веб-приложение? Что за аннотации висят над этим классом? А что за файл pom.xml и зачем он нужен? Такие вопросы — это маленькие подзадачи задачи под названием «Что это и как оно работает?». Да, это тоже практическая задача, но исследовательского характера.

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

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

💻 Так, со временем накопится не только портфолио где-нибудь на гитхабе, но и понимание того, что делать и зачем. Такой алгоритм обучения работает для любого стека технологий, и не только в программировании. Главное в этом деле - регулярность и дисциплина.

Требования к безопасности веб-приложения

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

Есть один классный гайд — OWASP Web Security Testing Guide. В нем описаны различные уязвимости и способы защиты от них. Чтобы не получилось такой ситуации, что клиент будет вынужден заказывать полный пентест системы, а потом в панике просить залатать все найденные дыры в безопасности, в идеале пентест должен быть в течение всего жизненного цикла разработки ПО. Это означает, что любая фича должна тестироваться на потенциально имеющиеся в ней уязвимости, а не только на соответствие заданной бизнес-логике.

Что еще является хорошими практиками безопасной разработки:

0️⃣ Перед началом разработки нужно определиться с гайдлайнами, которым будет следовать команда.

1️⃣ Во время проектирования однозначно определяются требования, касающиеся механизмов аутентификации, авторизации, конфиденциальности и целостности данных, контроля сессий, соответствия стандартам и законодательству.

2️⃣ Дизайн и архитектура приложения подробно документируются для раннего выявления потенциальных уязвимостей, проработки сценариев атак и прозрачности разработки.

3️⃣ После развертывания проводятся дополнительные проверки, касающиеся метода развертывания инфраструктуры и деталей конфигурации, которые могут быть потенциально уязвимы.

4️⃣ Во время технического обслуживания и эксплуатации регулярно проводятся проверки работоспособности и health-check на предмет доступности сервисов приложения.

Всем привет!

На связи Сергей Чистяков, CTO Red Collar

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

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

💥 Для чего нужны системы контроля версий?

💥 Сколько репозиториев нужно проекту?

💥 Сколько веток должно быть в репозитории? (тут спойлер)

Ну и для самых упорных два поста про Trunk Based Development

раз и два

Прежде чем критиковать gitflow, давайте разберем, что же это такое?

gitflow - революционная в свое время система управления ветками в Git, предложенная аж в 2010 году.

Заслуга gitflow в том, что она систематизировала опыт индустрии на тот момент. В этой модели управления ветками были описаны действия, для многих типичных ситуаций - процессы релизов, изоляции отдельных фичей, действия в случае необходимости хотфикса в текущем релизе.

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

А пока давайте перерисуем классическую картинку Винсента Дриссена горизонтально и вспомним основную цветовую маркировку.

🟡 develop - желтая ветка - используется в качестве хранилища рабочей версии проекта.

🟣 От нее создают feature-ветки. В этих ветках ведется изолированная разаботка фичей и в классическом gitflow они живут довольно долго.

🟢 Зеленые релизные ветки нужны для того, чтобы изолировать код, готовый к релизу для регрессионного тестирования и стабилизации. после релиза они вливаются и в master и в develop

🔵 Синяя ветка - master содержит код, доступный пользователю, все изменения попадают туда в момент релиза.

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

Давайте продолжим.

Какие могут быть недостатки у подхода gitflow?

1. Множество долгоживущих веток.
Две очевидные "вечные" ветки - master и develop 🟡.
При этом фича-ветки в классическом gitflow тоже не ограничены по времени жизни. Разрабатывайте свою фичу хоть три года, куда спешить.
Если релизные ветки создаются под каждый релиз и потом закрываются, это еще полбеды. Совсем плохо, когда команда проекта использует отдельную долгоживущую ветку releases 🟢 просто потому, что они так поняли картинку, но текстовое описание флоу не прочитали 🤦‍♀️
Это могло бы показаться шуткой, если бы не повторялось десятки раз

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

На картинке, если коммит из hotfix 🔴 попадает в develop 🟡 с конфликтом из-за того, что там уже произошли какие-то изменения после релиза, то это неизбежно приведет к расхождению master 🔵 и develop 🟡 с непредсказуемым результатом в будущем.

При использовании gitflow обычно к каждой ветке привязано свое окружение и этим объясняется необходимость долгоживущих веток. Например, весь код из develop 🟡 собирается и попадает на стенд разработки, из releases 🟢 - на stage для тестирования, из master 🔵 - на продакшн. Вроде бы логично, понятно и удобно, если вас не смущает то, что на стейдже вы тестируете один код, а на продакшн выкладываете другой 🤷

Итак, что мы хотим?

Нам нужно переизобрести процесс разработки так, чтобы выполнялись условия

1. Минимизировать количество долгоживущих веток

2. Взять все плюсы gitflow: работу с релизами и хотфиксами

3. Постараться выкатывать в продакшн полностью оттестированный код

Скажу честно, за основу мы взяли методологию trunk based development aka магистральная разработка, о которой я когда-то писал, но методом проб и ошибок адаптировали ее к своим реалиям, о чем и расскажу в следующих постах.

Коллеги, закинули инвайт на субботнюю встречу. Собираемся 17 августа в центре Воронежа на конференцию «Код на крыше».

Level up для разработчиков: для тех, кто устал говорить про общее и ждёт от докладов конкретику. Подойдёт техническим экспертам, которые решили вкачивать харды.

В плане мероприятия 3 секции для разных профессиональных комьюнити. Объединяем людей из разных направлений: менеджеры, технические эксперты и дизайнеры.

О разработке расскажут спикеры из Авто.ру, Red Collar, ex-OBI и #NDA:

- Дмитрий Панычев, ex ИТ-директор OBI и vprok.ru
«Архитектура не нужна?»

- Евгений Ефанов, старший мобильный разработчик Red Collar
«Разработка для Apple TV: SwiftUI и Focus Engine»

- Артём Михайлёв, старший Android-разработчик Авто.ру
«Функциональный подход к созданию дизайн-систем»

И один доклад о проекте под жестким #NDA, про который расскажем позже.

А еще круглый стол на тему, которую выберите вы сами, карьерный центр на крыше и афтепати.

Подробнее о программе и регистрация: rooftopcode.ru

UPD: Конференция перенесена! Новая дата будет анонсирована позже.