«Ветка», «песочница», «мёрджить» и ещё 11 терминов, которые помогут понять разработчиков

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

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

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

На английском — application programming interface, на русском — программный интерфейс приложения, для тех, кто в теме, — «эйпиай», «апи», «апишка» или «апиха». Так что потренируйтесь распознавать на слух все варианты. Но как бы ни произносил этот термин ваш собеседник, он имеет в виду описание способов взаимодействия между программами, то, как они могут общаться — передавать данные друг другу.

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

Наследие — именно так переводится legacy с английского — которому обычно никто не рад. Ведь под легаси подразумевают устаревший код или систему, на которой завязана работа продукта. Работать с ним сложно, отказаться — ещё сложнее.

На собеседованиях кандидаты часто спрашивают, как много легаси-кода в проекте. Это нормально, ведь все хотят создавать новое, а не копаться в том, что уже сделано (и не факт, что хорошо). А когда разработчик говорит: «Вроде легко, но там легаси» — стоит умножить сроки на два, а то и на три. Потому что внезапно может выясниться, что на легаси-кусок кода завязаны критичные функции вообще в другой части проекта.
Павел Комягин, тимлид разработки внутренних коммерческих продуктов Нетологии

Общая задача продактов и разработчиков — балансировать рабочую загрузку так, чтобы оставалось время на избавление от легаси. Если будет достигнута критическая масса легаси-кода, разработка будет идти сложнее и медленнее.
Яна Арсютина, CPO Нетологии

Не фейл, а большой объём работы, который можно разбить на несколько более мелких задач, объединённых общей идеей. Например, новая крупная фича в продукте. В Jira и подобных ей инструментах для управления проектами такие задачи называются историями.

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

Чтобы перейти на сторипоинты, нужно проанализировать сделанные задачи и выбрать эталонные — те, на которые будет ориентироваться команда для оценки сложности новых задач. Например, исправить опечатку — 1 сторипоинт, а добавить новый блок на страницу — уже 2, потому что задача больше. В каждой команде свой набор эталонных задач для оценки.

Сторипоинты неразрывно связаны с капасити, ёмкостью команды, и планированием. Зная оценку задач и количество сторипоинтов, которое команда в среднем закрывает в спринт или итерацию, можно планировать и прогнозировать готовность продукта.
Яна Арсютина, CPO Нетологии

Что? Да! Ещё один способ измерять сложность задач и время на их выполнение. Задачи ранжируются по размерам маек (от XS до XL) и измеряются в идеальных часах — времени, которое потребуется на решение, если ничего не будет отвлекать.

Каким задачам присвоить размер S, а каким — XL, команда решает на основе своей средней скорости работы.

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

Нужно помнить про нюансы: внимательно читать лицензию, в ней написано, чем именно можно свободно пользоваться, и учитывать, что open source не синоним слова «бесплатно».
Павел Комягин, тимлид разработки внутренних коммерческих продуктов Нетологии

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

От английского глагола deploy — приводить в действие или разворачивать. Задеплоить приложение, сайт или сервис — значит запустить новую версию в рабочей среде, на сервере или хостинге. Только представьте, как здорово это модное слово будет смотреться в вашем лексиконе!

«Задеплоить» часто ставят в один ряд с другим похожим по смыслу словом — «зарелизить». Но между ними есть разница: деплой может остаться внутренним изменением, а релиз всегда подразумевает загрузку обновления в открытый доступ. Поэтому каждый релиз — деплой, но не всякий деплой — релиз.
Павел Комягин, тимлид разработки внутренних коммерческих продуктов Нетологии

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

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

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

Накопление в коде проблем, которые замедляют разработку или делают её менее качественной.

Простой пример: разработке нужно было быстро зарелизить фичу, поэтому написали неоптимальный, запутанный и медленный код, а теперь тратят лишний час каждый раз, когда нужно что-то исправить. Выход есть — отдать технический долг, то есть устранить проблему. Часто бывает, что команды планируют 10–20% времени на задачи техдолга.
Павел Комягин, тимлид разработки внутренних коммерческих продуктов Нетологии