В сети часто встречается вопрос: «TBD, что это такое?». Данная аббревиатура
затрагивает две IT сферы: видеоигры и модель разработки программного
обеспечения. Сегодня разберем, что такое TBD, как подход в программировании.
TBD — это Trunk Based Development, или магистральная разработка программного
обеспечения. Это специальный метод разработки, при котором программисты
совместно работают над одной веткой кода, которая называется «ствол» или главной
веткой. Остальные ответвления разработки имеют более короткий срок жизни,
благодаря использованию документированных моделей.
TBD, что это значит в программировании
Основная идея TBD состоит в том, чтобы не использовать объединение отдельных
ветвей функции с основной ветвью при раздельной разработке, а применять
деление таких функций на небольшие части, которые сразу помещаются в «ствол»
разработки и разрабатываются всеми программистами. Если простыми словами, то
команда разработчиков программирует без четкого применения деления на
отдельные ветви разработки, а целиком работает над конкретной частью.
Магистральная разработка приносит очень важное преимущество перед другими
моделями — в ней практически отсутствуют конфликты при слиянии отдельных
ветвей общей разработки.
Преимущества TBD
Помимо основного преимущества, описанного выше, TBD-модель, это еще ряд
достоинств, которые нужно отметить:
- Быстрое развертывание. TBD совместно с конвейером CI/CD дает
возможность разворачивать функциональный код непосредственно в самом
сердце производства. Это облегчает интеграцию рабочих частей и
развертывание самой разработки. Плюс ко всему, это дает хорошую
возможность, в случае обнаружения ошибок «откатить» разработку до
рабочего состояния, так как «рабочие состояния» фиксируются. - Высокое качество кода. TBD это то, что обеспечивает устойчивый и
качественный код, начиная с самой базы, а вероятность ошибок сильно
снижается. Также эта модель дает возможность использовать «принцип 4-х
глаз», когда минимум 2 отдельных программиста просматривают код перед его
отправкой в «ствол» всей разработки. Для этого используется парная
разработка, когда программисты работают по двое, а не по одиночке, помогая и проверяя друг друга. При этом ответственность за качество их части кода
лежит на них двоих. - Командная работа. Парная разработка улучшает командный дух. Плюс, это
дает возможность более слабым разработчикам работать с более сильными,
тем самым перенимать опыт и становиться лучше. Плюс, общее дело
поднимает градус ответственности и коммуникации между членами команды.
Потенциальные недостатки TBD
Помимо достоинств этой модели разработки, у нее есть собственные потенциальные
недостатки. Почему потенциальные? Потому что во многих TBD-командах они
отсутствуют, но, в принципе, их наличие не исключено.
TBD это то, что обладает следующими потенциальными недостатками:
- Вероятность незаконченных функций. Из-за специфики метода, иногда в
разработке могут возникать незавершенные функции, которые образуются по
разным причинам. Чаще всего это, когда одна из команд, работающая над
функцией не успевает к дате релиза и показа программы заказчику. Это может
возникнуть из-за неправильного группирование пар разработчиков, когда
попадаются два слабых или не обладающих знаниями в нужной области,
разработчика вместе. - Затруднено тестирование и мониторинг разработки. TBD часто применяется
при разработке больших и сложных программ в огромных проектах. Поэтому
требуется наличие мощного набора тестов, для качественного тестирования
кода, чтобы быстрее выявлять ошибки и не допускать их «разрастания» из-за
того, что не вовремя их выявили.
Заключение
TBD — это далеко не новый подход в программировании. История этого метода
тянется к нам еще из 80-х, свою популярность он приобрел к концу 90-х и до сих пор
этой моделью пользуются крупные компании, такие как Гугл или Фейсбук.
Реализовать магистральную разработку не так легко как кажется, так она приносит с
собой определенные трудности, например, она требует профессионализма и
ответственности от всех участвующих разработчиков, чтобы они могли
самостоятельно программировать, брать ответственность за свой код и принимать
нужные решения.
Возможно вам будет интересно почитать статью “Введение в асинхронный Javascript.”
История показывает, что те, кто смог реализовать TBD модель в своей работе, не возвращаются к другим моделям. Но не нужно забывать, что одна и та же модель разработки не во всех случаях применима, поэтому лучше применять ту модель, которая лучше подходит вашей разработке и вашей команде, с которой будете осуществлять задуманное.
