Вернуться




TBD — что это такое? Магистральная разработка программ для ПК



В сети часто встречается вопрос: «TBD что это такое?». Данная аббревиатура затрагивает две IT-сферы: видеоигры и модель разработки программного обеспечения. Сегодня разберем, что такое TBD как подход в программировании.

TBD — это Trunk Based Development или магистральная разработка программного обеспечения. Это специальный метод разработки, при котором программисты совместно работают над одной веткой кода, которая называется «ствол» (или главная ветка). Остальные ответвления разработки имеют более короткий срок жизни благодаря использованию документированных моделей.

TBD что это значит в программировании 

Основная идея TBD состоит в том, чтобы не использовать объединение отдельных ветвей функции с основной ветвью при раздельной разработке, а применять деление таких функций на небольшие части, которые сразу помещаются в «ствол» разработки и разрабатываются всеми программистами. Если простыми словами, то команда разработчиков программирует без четкого применения деления на отдельные ветви разработки, а целиком работает над конкретной частью.

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

Преимущества TBD 

Помимо основного преимущества, описанного выше, TBD-модель это еще ряд достоинств, которые нужно отметить:

  1. Быстрое развертывание. TBD совместно с конвейером CI/CD дает возможность разворачивать функциональный код непосредственно в самом сердце производства. Это облегчает интеграцию рабочих частей и развертывание самой разработки. Плюс ко всему это дает хорошую возможность в случае обнаружения ошибок «откатить» разработку до рабочего состояния, так как «рабочие состояния» фиксируются.

  2. Высокое качество кода. TBD это то, что обеспечивает устойчивый и качественный код, начиная с самой базы, а вероятность ошибок сильно снижается. Также эта модель дает возможность использовать «принцип 4-х глаз», когда минимум 2 отдельных программиста просматривают код перед его отправкой в «ствол» всей разработки. Для этого используется парная разработка, когда программисты работают по двое, а не поодиночке, помогая и проверяя друг друга. При этом ответственность за качество их части кода лежит на них двоих.

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

Потенциальные недостатки TBD

Помимо достоинств этой модели разработки, у нее есть собственные потенциальные недостатки. Почему потенциальные? Потому что во многих TBD-командах они отсутствуют, но в принципе их наличие не исключено. 

TBD это то, что обладает следующими потенциальными недостатками:

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

  2. Затруднено тестирование и мониторинг разработки. TBD часто применяется при разработке больших и сложных программ в огромных проектах. Поэтому требуется наличие мощного набора тестов для качественного тестирования кода, чтобы быстрее выявлять ошибки и не допускать их «разрастания» из-за того, что вовремя их не выявили.

Заключение

TBD — это далеко не новый подход в программировании. История этого метода тянется к нам еще из 80-х, свою популярность он приобрел к концу 90-х, и до сих пор этой моделью пользуются крупные компании, такие как Гугл или Фейсбук.

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



Если вам понравилась эта статья поделитесь ею с друзьями, тем самым вы помогаете нам развиваться и добавлять всё больше интересного и полезного контента!




Cхожие статьи





Стоит ли учиться программировать в 2021

Стоит ли учиться программировать в 2021

Не случайно в разговорах о рынке труда, перспективах развития и важнейших с ...

21 Февраля 2021    Другое

Плюсы и минусы Baas для разработки мобильных приложений

Плюсы и минусы Baas для разработки мобильных приложений

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

23 Марта 2021    Другое

Начинающий программист

Начинающий программист

Самыми легкими в изучении можно считать такие языки как JavaScript, Python, ...

23 Марта 2021    Другое