SDLC

• Gits
  • Что такое Git Flow
  • Что такое Git Rebase
  • Что такое Git Cherry pick
  • Что такое force push
  • Что такое pre-commit check
• CI/CD
• Методологии
  • Какая разница между Scrum и Kanban
• Что такое Code Debt и как с ним быть
• Other…
  • Как ты делаешь эстимацию задачи?
  • Были ли кейсы когда эстимации проваливались?
  • Почему так получалось?
  • Какое должно быть покрытие
  • Как их правильно писать
  • Что делаешь, если не можешь справиться со сложными задачами?
  • Была ли документация на проекте и как организована?
  • Lifecycle задачи
  • Что для тебя clean code
  • CORS
  • Троттлинг

Gits

Что такое Git Flow

Historical Branches Вместо использования только одной master ветки, этот workflow использует две ветки, для записи истории проекта. Master хранит официальную историю релизов, в development же ветке ведется активная разработка. Также важно тагать комиты в master ветки номерами версий.

Feature Branches Каждая новая фича должна разрабатываться отдельно - в своей ветке, которая должна пушиться в центральный репозиторий для сохранения работы или коллаборации с другими разработчиками. Для создания фичебранча используется development ветка. Когда разработка фичи закончена, она сливается в development. Фичи никогда не должны сливаться напрямую с master веткой.

Release Branches Как только development наберет достаточно фич для релиза (или в заранее определенную дату) создается release ветка из development ветки.

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

Как только релиз-ветка подготовлена, ее сливают с master и тагают новой версией. Также она должна быть слита и с development веткой, которая уже скорее всего убежала вперед, с момента инициализации релиза.

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

Hotfix Branches Hotfix ветки используются для быстрого патчинга релизов. Это единственная ветка, которая создается из master. Как только фикс готов, он должен быть слит как в master, так и в development (или в новый release, если она есть) и master должен быть тегирован новой версией (инкрементирована patch цифра. v.1.0.1, например) Это позволяет исправлять ошибки не прерывая весь воркфлоу или не дожидаясь следующего релиза, для выкатывания исправлений.

Reference:

• Gitflow Workflow
• Read Git Flow

Что такое Git Rebase

Итак git работает с комитами. Каждый комит — набор изменений. У каждого комита есть уникальный hash. Когда происходит слияние веток посредством merge:

$ git merge "another_branch"

то все комиты сохраняются — сохраняются комментарии комита, его hash + как правило добавляется еще один искусственный комит. При этом комиты могут чередоваться друг с другом. Это не всегда удобно. Допустим ваш комит решили откатить — выискивать в общем списке где ваш комит, а где не ваш не очень приятно. И вообще — в общей истории хочется видеть действительно важные изменения, а не «ой, я забыл поставить ;». Для того, чтобы несколько комитов склеивать в один можно использовать rebase. Хотя в интерфейсе GitHub есть кнопочка squash & commit — это когда вы создаете pull request (PR) из одной ветки в другую (как правило из вашей рабочей ветки в основную) и после прохождения всех формальностей можно нажать squash & commit, обновить комментарий и ваши изменения появятся в основной ветке как один комит.

Хочу написать о двух случаях использования rebase:

1. Когда изменения включаются из одну ветку в другую не посредством merge, а посредством rebase: $ git rebase "another_branch" Это позволяет ваши локальные комиты поставить после всех комитов, которые были внесены в ветку «another_branch». Хэши ваших комитов изменятся.
2. Когда можно руками отредактировать несколько ваших комитов — например склеить их, изменить коментарий: $ git rebase -i {HEAD~_commit_count_|commit_hash}

Итак вы все сделали в своей уютненькой веточки и решили поделиться этим комитом с миром, но мир хочет от вас только один комит. git rebase -i запустит редактор и предложит отредактировать комиты (порядок следования комитов — сверху вниз в отличие от git log). Можно оставить комит как есть, можно изменить комментарий, можно склеить с предыдущим. Как правило ваш первый комит надо оставить как есть, а все остальные изменить на pick "commit_hash" "comment" → fixup "commit_hash" "comment".

При этом все комментарии, которые были в fixup комитах потеряются и будет использоваться комментарий от первого комита. Если вам были дороги комментарии, то стоит использовать squash вместо fixup.

Но если процесс разработки был долог, то скорее всего вам приходилось делать merge основной ветки. И все ваши комиты перемешаются с общими комитами и склеивать ваши с не вашими будет задачей непростой. Поэтому перед тем, как делать git rebase -i <> стоит сделать git rebase. git rebase поставит все ваши комиты в конец списка всех комитов (в чем можно убедиться запустив git log) и после этого запустиь git rebase -i <HEAD~Количесво_ваших_комитов>, во всех строчках кроме первой заменить pick → {fixup|squash} и вуаля — у вас один комит.

Если в процессе редактирования комитов git rebase -i <> вы как-то накосячили, то не стоит жать Control+C — exit code выхода из редактора git не волнует. Он просто возьмет файл и сделает все по нему. Просто удалите или закомментируйте все строчки в файле. git поймет, что вы ничего не хотели.

После манипуляций с rebase потребуется push с опцией -F. Все это потому, что мы переписываем меняем историю комитов и git нас об этом честно предупреждает. $ git push -f

Что такое Git Cherry pick

Команда git cherry-pick используется для перенесения отдельных коммитов из одного места репозитория в другое, обычно между ветками разработки и обслуживания. Этот механизм отличается от привычных команд git merge и git rebase, которые переносят коммиты целыми цепочками.

git cherry-pick <commit-hash>

Что такое force push

Если вы поправили какие-нибудь старые коммиты в истории git, например: исправили имя автора или e-mail, или отменили последний коммит или воспользовались amend или revert, то при попытке push-а git справедливо «ругнётся»

Чтобы нам всё же запушить наши изменения, нам нужно выполнить либо

git push --force origin <имя_ветки>

Но в этом случае мы рискуем перетереть чьи-нибудь изменения, если с тех пор, как мы забирали изменения с сервера, кто-то успел запушить свои коммиты. Поэтому лучше использовать более безопасную команду:

git push --force-with-lease origin <имя_ветки>

Такой вариант лучше тем, что если кто-то успел запушить свои коммиты после того, как мы забирали изменения с сервера, то он не будет их перетирать, а выдаст нам ошибку, после чего мы сможем интегрировать чужие коммиты со своими изменениями и попытаться сделать push --force-with-lease ещё раз.

Что такое pre-commit check

Как и во многих других системах контроля версий, в Git’е есть возможность запускать собственные сценарии в те моменты, когда происходят некоторые важные действия. Существуют две группы подобных перехватчиков (hook): на стороне клиента и на стороне сервера. Перехватчики на стороне клиента предназначены для клиентских операций, таких как создание коммита и слияние. Перехватчики на стороне сервера нужны для серверных операций, таких как приём отправленных коммитов. Перехватчики могут быть использованы для выполнения самых различных задач. О некоторых из таких задач мы и поговорим.

Pre-commit check можно использовать например так:

• выполнять проверку кода на валидность (например: соответствие требованиям PEP8, наличие документации итд);
• выполнять комплексную проверку проекта (юнит-тесты итд);
• прерывать операцию commit’а в случае обнаружения ошибок и отображать подробный журнал для разбора полетов.

CI/CD

Continuous integration (непрерывная интеграция) Непрерывной интеграция заключается в следующем: все изменения, вносимые в код, объединяются в центральном репозитории (операция называется «слияние»). Слияние происходит несколько раз в день, и после каждого слияния в конкретном проекте срабатывает автоматическая сборка и тестирование.

Бывает, что перед сборкой и тестированием программу требуется скомпилировать (это зависит от языка, на котором она написана). Сегодня все чаще возникает необходимость упаковать приложение в контейнер Docker. Затем автоматические тесты проверяют конкретные модули кода, работу UI, производительность приложения, надежность API и пр. Все эти этапы в совокупности обычно называют «сборкой».

CI – это своеобразная страховочная сетка, позволяющая разработчикам избежать массы проблем перед сдачей проекта.

Continuous delivery (непрерывная доставка) Непрерывная доставка – это практика автоматизации всего процесса релиза ПО. Идея заключается в том, чтобы выполнять CI, плюс автоматически готовить и вести релиз к продакшену. При этом желательно добиться следующего: любой, кто обладает достаточными привилегиями для развертывания нового релиза может выполнить развертывание в любой момент, и это можно сделать в несколько кликов. Программист, избавившись практически от всей ручной работы, трудится продуктивнее.

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

Continuous deployment(непрерывное развёртываение) Непрерывное развертывание располагается «на уровень выше» непрерывной доставки. В данном случае все изменения, вносимые в исходный код, автоматически развертываются в продакшен, без явной отмашки от разработчика. Как правило, задача разработчика сводится к проверке запроса на включение (pull request) от коллеги и к информированию команды о результатах всех важных событий.

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

Разработчики, практикующие CI и желающие перейти к непрерывному развертыванию, для начала автоматизируют развертывание в обкаточную среду, а развертывание в продакшен продолжают делать вручную – одним кликом.

Резюме:

• Непрерывная интеграция (CI): короткоживущие функциональные ветки, команда сливает их с основной веткой разработки по несколько раз в день, процессы сборки и тестирования полностью автоматизированы, результат имеем в пределах 10 минут; развертывание выполняется вручную.
• Непрерывная доставка (CD): автоматизируется CI + весь процесс релиза ПО. Может состоять из нескольких этапов. Развертывание в продакшен выполняется вручную.
• Непрерывное развертывание: CI + CD + полностью автоматизированное развертывание в продакшен.

Reference: Непрерывная интеграция, непрерывная доставка, непрерывное развертывание: просто матрешка

Методологии

Какая разница между Scrum и Kanban

• Scrum vs Kanban: в чем разница и что выбрать?

Scrum и Kanban — представители методологий Agile-семейства. Обе считаются гибкими и итеративными.

Более 17 лет назад лидеры IT-разработки сформулировали манифест Agile. Главное, что можем выделить из манифеста:

• Люди и взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования первоначальному плану.

Основу Scrum составляют короткие итерации или спринты, как правило, 2-3-х недельные. Перед началом спринта команда сама формирует список фич на итерацию, далее запускается спринт.

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

Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Вчера вы залили на прод новую фичу, а сегодня получили данные с передовой и узнали, что вот эта штука не работает так, как было задумано — люди не нажимают кнопку «купить». Вы «даете по шапке» UX, он дает вам новые требования. Вы поднимаете наверх очереди эту задачу, программист берет эту задачу «сверху», выполняет ее и, к вечеру fix уже на проде, конверсия в платежи выросли на 12%. Это победа.

Основная разница между Scrum и Канбан — в длине итераций. В Scrum итерации — 2 недели, в Kanban задачи программисту можно «подсовывать» хоть каждый день.

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.

Итак, в Scrum наша цель — закончить спринт, в Kanban — задачу.

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

Что такое Code Debt и как с ним быть

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

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

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

• Делайте одноразовые прототипы MVP и только подтвержденные гипотезы включайте в работу.
• Создавайте архитектуру, которую будет просто изменить: микросервисы, API с версионированием.
• Откажитесь от организации собственных серверных в пользу облачных решений. Например, Microsoft Azure, AWS Amazon Cloud, «Яндекс.Облако», облако от Mail.ru и так далее.
• Установите в команде четкий definition of done, включающий в том числе метрики качества. Очень помогает включить в DOD пункт, исключающий «приемку» фичи, если есть связанные с ней баги.
• Для MVP хорошо проектировать систему так, чтобы миграция пользователей с прототипов на стабильную часть была незаметной.

Компании справляются с техдолгом по-разному. Основных стратегий три.

• Переписывают все с нуля. Это ультимативный способ поддерживать систему в состоянии, когда она постоянно готова к изменениям, если все зашло слишком далеко и уже нет прежней гибкости.
• Делают постепенный рефакторинг. Задачи по техдолгу отправляются в бэклог наравне с продуктовыми задачами. Это замедляет работу по выкатке новых фич, но бизнес обычно идет на компромиссы.
• Смиряются с техдолгом. Если у вас не стартап, а обновления нужны раз в полгода, то можно просто смириться с тем, что код неоптимален, и действовать по принципу «работает — не трогай». Как только поймете, что ошиблись, вы так или иначе переместитесь к пункту 1.

Other…

Как ты делаешь эстимацию задачи?

Были ли кейсы когда эстимации проваливались?

Почему так получалось?

Какое должно быть покрытие

Как их правильно писать

Что делаешь, если не можешь справиться со сложными задачами?

Была ли документация на проекте и как организована?

Lifecycle задачи

Что для тебя clean code

CORS

Троттлинг