[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"general-list":3,"methodology-topic-xp-praktiki":4,"footer-feature-tags":163},true,{"topic":5,"parent":156,"siblings":160},{"slug":6,"title":7,"hint":8,"h1":9,"definition":10,"readTime":11,"published":12,"updated":12,"tags":13,"sections":16,"table":59,"checklist":83,"shtab":94,"faq":113,"terms":126,"related":143,"seo":153},"praktiki","Инженерные практики XP","тесты, пары, сборка, рефакторинг","Инженерные практики XP и связи между ними","Практики подхода держатся друг за друга: рефакторинг опирается на тесты, тесты — на быструю сборку, простой дизайн — на возможность переделать. Выборочное применение половины набора даёт заметно меньше половины эффекта.","6 мин чтения","2026-08-30",[14,15],"практики","продвинутый уровень",[17,24,32,39,46,53],{"h":18,"id":19,"paras":20},"Быстрая сборка и непрерывная интеграция","sborka",[21,22,23],"Фундамент всего набора. Каждое изменение автоматически собирается и прогоняется через тесты; результат приходит за минуты.","Скорость здесь техническое требование, а не удобство. Сборка длиной в полчаса обходится локальными приёмами: изменения копят, объединяют реже, проверяют выборочно. Через месяц непрерывная интеграция существует только на схеме.","Второе правило — сломанная сборка чинится немедленно и имеет приоритет над новой работой. Команда, живущая с красной сборкой сутками, перестаёт ей верить, и сигнал теряет смысл.",{"h":25,"id":26,"paras":27},"Тесты вперёд","testy",[28,29,30,31],"Цикл короткий: написать падающий тест на нужное поведение, написать минимальный код, чтобы он прошёл, привести код в порядок. Повторить.","Порядок здесь не формальность. Тест, написанный до кода, описывает требуемое поведение; тест, написанный после, обычно описывает то, что получилось, включая случайные особенности реализации.","Побочный эффект ценнее прямого. Код, который трудно протестировать, обычно плохо устроен, и требование тестируемости вытягивает архитектуру раньше, чем проблема станет дорогой.","Практическое правило для старых систем: новый код приходит с тестом, старый покрывается там, где идёт работа. Проект «покрыть всё» отменяют при первом срочном требовании.",{"h":33,"id":34,"paras":35},"Парная работа","para",[36,37,38],"Двое за одной задачей: один пишет, второй думает на шаг вперёд и замечает то, что первый пропускает. Роли меняются каждые несколько десятков минут.","Затраты меньше, чем подсказывает интуиция. Пара работает медленнее одного человека примерно на десятую-пятую часть, а не вдвое; при этом разбор кода происходит сразу, знание расходится по команде, и число дефектов падает.","Постоянная парная работа подходит не всем: она утомительна и требует совместимости людей. Выборочная — на сложных задачах, на незнакомом коде, при обучении новичка — даёт большую часть эффекта и почти не встречает сопротивления.",{"h":40,"id":41,"paras":42},"Рефакторинг","refaktoring",[43,44,45],"Улучшение внутреннего устройства кода без изменения поведения. Происходит постоянно, малыми шагами, по ходу работы над задачей.","Опирается на тесты полностью: без них вы меняете код вслепую и узнаёте о поломке от пользователей. Именно поэтому рефакторинг ставят после тестов.","Отдельный проект по улучшению кода почти всегда отменяют при первом срочном требовании, а долг возвращается. Работающий вариант — правило «оставь код чище, чем нашёл» в пределах текущей задачи.",{"h":47,"id":48,"paras":49},"Простой дизайн","dizayn",[50,51,52],"Решение делают самым простым из тех, что решают текущую задачу. Обобщение «на будущее» откладывают до момента, когда будущее наступит.","Логика прямая: предсказать будущие требования трудно, а поддерживать обобщение приходится всё время. Функция, добавленная на всякий случай, стоит не только разработки — её тестируют, объясняют и обходят годами.","Практика работает только вместе с рефакторингом. Простое решение без права его переделать превращается в короткое одеяло.",{"h":54,"id":55,"paras":56},"Запас в плане","zapas",[57,58],"Часть недельной ёмкости остаётся незанятой. Практика выглядит поблажкой и на деле защищает всё остальное.","Неделя, заполненная под завязку, ломается от первой срочной задачи, и жертвуют в такой момент тестами и рефакторингом — тем, что не видно снаружи. Через квартал от практик остаются одни названия.",{"head":60,"rows":64,"title":82},[61,62,63],"ПРАКТИКА","ОПИРАЕТСЯ НА","ЧТО БУДЕТ БЕЗ ОПОРЫ",[65,69,71,74,76,79],[66,67,68],"Непрерывная интеграция","Быструю сборку","Сборку обходят, интеграция формальна",[25,67,70],"Тесты запускают редко, они устаревают",[40,72,73],"Тесты","Изменения вслепую, поломки находят пользователи",[47,40,75],"Простое решение застывает и мешает",[33,77,78],"Общий стандарт кода","Споры о стиле вместо работы",[80,54,81],"Всё вместе","Срочное съедает качество за квартал","На что опирается каждая практика",{"lead":84,"items":85,"title":93},"Практики бесполезно оценивать по отдельности: важно, стоит ли под каждой опора. Проверьте снизу вверх.",[86,87,88,89,90,91,92],"Полная сборка с тестами занимает минуты","Каждое изменение собирается автоматически","Сломанная сборка чинится в тот же день и имеет приоритет","Новый код приходит с тестом, без исключений","Рефакторинг идёт в пределах текущей задачи, а не отдельным проектом","Есть общий стандарт кода, и споры о стиле не повторяются","В недельном плане остаётся незанятый запас","Фундамент на месте",{"lead":95,"links":96,"title":106,"points":107},"Сами практики живут в системе сборки и в репозитории. В Shtab остаётся то, что связано с планированием: истории, критерии приёмки, запас ёмкости и видимый технический долг.",[97,102],{"to":98,"tag":99,"text":100,"title":101},"\u002Ffeatures\u002Fkanban-doska\u002F","ВОЗМОЖНОСТЬ","Ограничение незавершённой работы и видимый запас.","Канбан-доска",{"to":103,"tag":99,"text":104,"title":105},"\u002Ffeatures\u002Ffiltratsiia-kartochek\u002F","Срез по метке технического долга.","Фильтрация задач","Что из этого видно в трекере",[108,109,110,111,112],"Критерии приёмки чек-листом в шаблоне задачи появляются в каждой истории.","Назначение двух исполнителей делает парную работу видимой в плане.","Метка технического долга не даёт ему потеряться среди историй.","Ограничение незавершённой работы поддерживает запас ёмкости.","Сводный отчёт показывает, сколько недель подряд запас съедался срочным.",[114,117,120,123],{"a":115,"q":116},"Порядок влияет на результат. Тест, написанный заранее, описывает требуемое поведение; написанный после — то, что получилось, вместе со случайными особенностями реализации. Начать можно и с тестов после кода, это лучше, чем ничего, но эффект вытягивания архитектуры при таком порядке пропадает.","Обязательно ли писать тест до кода?",{"a":118,"q":119},"Абсолютное значение мало о чём говорит: восемьдесят процентов покрытия на неважных ветках хуже пятидесяти на критичных. Смотрите направление и место: растёт ли покрытие там, где идёт активная работа, и покрыты ли пути, поломка которых дороже всего.","Какое покрытие тестами считать достаточным?",{"a":121,"q":122},"Не вводить целиком. Начните с ситуаций, где польза очевидна всем: незнакомый участок кода, сложная задача, обучение нового человека. Постоянная пара по приказу вызывает сопротивление и даёт результат хуже, чем её отсутствие.","Как ввести парную работу, если команда против?",{"a":124,"q":125},"Начинать с границ. Даже в наследованной системе обычно можно проверять поведение снаружи: через интерфейс, через данные на входе и выходе. Такие проверки грубее модульных, зато позволяют начать рефакторинг, а он постепенно делает систему тестируемой изнутри.","Что делать с системой, которую нельзя протестировать?",[127,130,133,135,137,140],{"slug":128,"title":129},"tdd","Разработка через тестирование",{"slug":131,"title":132},"pair-programming","Парное программирование",{"slug":134,"title":66},"continuous-integration",{"slug":136,"title":40},"refactoring",{"slug":138,"title":139},"acceptance-criteria","Критерии приёмки",{"slug":141,"title":142},"definition-of-done","Определение готовности",[144,149],{"to":145,"tag":146,"text":147,"title":148},"\u002Fmethodology\u002Fxp\u002Fvnedrenie\u002F","ТЕМА","Порядок, в котором они приживаются.","Как внедрять практики по одной",{"to":150,"tag":146,"text":151,"title":152},"\u002Fmethodology\u002Fscrum\u002Fsobytiya\u002F","Организационный ритм, в который встраиваются практики.","События Scrum",{"title":154,"description":155},"Практики XP: тесты вперёд, пары, сборка, рефакторинг","Инженерные практики экстремального программирования и связи между ними: быстрая сборка, непрерывная интеграция, тесты до кода, парная работа, рефакторинг, простой дизайн.",{"slug":157,"title":158,"short":159},"xp","Экстремальное программирование (XP)","XP",[161],{"slug":162,"title":148},"vnedrenie",[164,173,179,188,193,199,205,211,215,221],{"id":165,"name":166,"hex":167,"translations":168,"count_pages":172},8,"Компания","#f40925",{"ru":169,"en":170},{"name":166},{"name":171},"Company",9,{"id":174,"name":175,"hex":176,"translations":177,"count_pages":165},26,"Главная страница",null,{"ru":178},{"name":175},{"id":180,"name":181,"hex":182,"translations":183,"count_pages":187},2,"Проекты","#3027ff",{"ru":184,"en":185},{"name":181},{"name":186},"Project",15,{"id":189,"name":190,"hex":176,"translations":191,"count_pages":180},33,"ИИ",{"ru":192},{"name":190},{"id":194,"name":195,"hex":176,"translations":196,"count_pages":198},34,"Комментарии",{"ru":197},{"name":195},4,{"id":200,"name":201,"hex":176,"translations":202,"count_pages":204},25,"Задачи",{"ru":203},{"name":201},24,{"id":206,"name":207,"hex":176,"translations":208,"count_pages":210},27,"Рабочие пространства",{"ru":209},{"name":207},3,{"id":204,"name":212,"hex":176,"translations":213,"count_pages":165},"Kanban-доска",{"ru":214},{"name":212},{"id":216,"name":217,"hex":176,"translations":218,"count_pages":220},23,"Диаграмма Ганта",{"ru":219},{"name":217},1,{"id":187,"name":222,"hex":176,"translations":223,"count_pages":220},"Календарь",{"ru":224},{"name":222}]