Skip to content
Start free
Get App

Почему AI делает архитектуру ещё важнее

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

Key Takeaways

  • Архитектура — это осознанные ограничения, повышающие качество и скорость разработки.
  • AI не заменяет архитектора, а требует четко описанной архитектуры для эффективной работы.
  • Ответственность за архитектуру лежит на разработчиках, а не на AI.
  • Хорошая архитектура помогает бизнесу быстрее получать новые функции и снижать баги.
  • Новые профессии и подходы появляются в связи с интеграцией AI в процесс разработки.

What the video covers

  • Архитектура — это набор полезных ограничений, которые помогают сохранять нужные свойства системы.
  • Цель архитектуры — уменьшить трудозатраты на создание и сопровождение ПО, ускоряя доставку бизнес-ценности.
  • Архитектурные решения лежат в зоне ответственности команды разработки и напрямую влияют на успех проекта.
  • Искусственный интеллект пока не улучшает архитектуру проектов, а скорее потребляет её, опираясь на существующий код и правила.
  • Для эффективного использования AI важно четко описывать архитектуру в проекте, чтобы избежать генерации легаси-кода.
  • Появляются новые роли, такие как Agentic AI Developer, где человек принимает решения, а AI выполняет рутинные задачи.
  • Архитектура помогает справляться с ростом кода и сложности проектов, обеспечивая гибкость и масштабируемость.
  • Применение принципов SOLID и инверсии зависимостей улучшает поддержку и расширяемость кода.
  • Обучение и обмен опытом через книги, конференции и видео помогают быстрее развивать архитектурные навыки.
  • Автор делится личным опытом презентаций и работы в международных компаниях, подчеркивая актуальность темы.

Chapters

  1. 00:00Введение в понятие архитектуры
  2. 01:13Архитектура как набор ограничений
  3. 02:30Вопросы деления кода и структура проекта
  4. 03:41Ответственность за архитектуру и бизнес-ценность
  5. 05:15Роль AI и его влияние на архитектуру
  6. 06:53Необходимость четко описанной архитектуры для AI
  7. 08:14Новые профессии и подходы с AI
  8. 09:14Заключение и личный опыт автора

Answers

Questions about this video

Что такое архитектура программного обеспечения?

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

Как искусственный интеллект влияет на архитектуру проектов?

AI пока не улучшает архитектурные свойства проектов, а лишь потребляет существующую архитектуру, опираясь на код и описанные правила, что требует четкого документирования архитектуры.

Почему архитектура важна в эпоху AI?

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

Full Transcript — Download SRT & Markdown

00:00
Speaker A
Всем привет! Тема сегодняшнего выпуска — "Архитектура". Все мы слышали это слово, знаем, что оно очень важное для проектирования сложных систем. Но мало кто может даже на словах описать, что такое хорошая архитектура, какие у неё особенности и какую основную цель она преследует.
00:16
Speaker A
А если сюда ещё добавить искусственный интеллект, у многих возникает вопрос, надо ли вообще в этом сегодня разбираться. Короткий ответ: надо. И сегодня разберёмся, почему это действительно так. Если интересно, подписывайтесь, ставьте лайк и поехали!
00:33
Speaker A
Думаю, начать стоит с одной истины, написанной прямо в Википедии: "Общепринятого определения архитектуры программного обеспечения не существует. Сайт Института программной инженерии приводит более 150 определений этого понятия".
00:48
Speaker A
При этом сама Википедия всё-таки решилась дать своё: "Архитектура программного обеспечения — это совокупность важнейших решений об организации программной системы".
00:58
Speaker A
Определение достаточно общее, но мне оно нравится. Правда, я бы взглянул на архитектуру ещё под одним углом, более прикладным: "Архитектура — это набор решений, которые ограничивают способы разработки системы, чтобы она сохраняла нужные свойства".
01:13
Speaker A
Вот такое определение куда легче примерить к ежедневной работе. Архитектура — это в первую очередь ограничения. Причём полезные ограничения. Мы осознанно создаём запреты в проекте, чтобы получить взамен что-то более ценное. И это всегда торг: насколько неудобный запрет мы вводим и насколько большую пользу получаем.
01:33
Speaker A
Чтобы понять, о чём идёт речь, задайте себе вопрос. Почему в вашем текущем проекте код разделён на огромное количество файлов? Почему вы не пишете весь код в одном единственном файле?
01:45
Speaker A
Технически это возможно. Компьютеру абсолютно всё равно, как написан код. Получается, вы соблюдаете запрет на раздувание файлов до сотен либо тысяч строк. А взамен получаете читабельность, простую навигацию, меньшую связанность кода, а как следствие — меньше конфликтов при командной разработке, проще тестирование,
02:03
Speaker A
понятнее зависимости. Одно суперпростое ограничение, а сколько пользы. Поэтому буквально все проекты мира следуют этому правилу, даже не задумываясь, что это архитектурное решение.
02:15
Speaker A
Но это ограничение сразу порождает следующий вопрос, и вот он уже по-настоящему сложный. Хорошо, в один файл нельзя. А как тогда делить? Если в проекте миллион строк кода, по какому принципу раскладывать его по файлам и папкам? Вот это, на самом деле,
02:30
Speaker A
и есть важный архитектурный вопрос. И у меня есть ответ на него, но к нему вернёмся позже.
02:36
Speaker A
Из моего опыта, люди чаще всего начинают проект с крайне примитивной структуры папок, а потом постепенно её усложняют. И делают это почти всегда интуитивно. Ваш предыдущий опыт пытается подсказать, какое решение когда-то себя показало хорошо, а какое завело в тупик.
02:52
Speaker A
Остаётся понять, а что вообще значит "решение показало себя хорошо" или "завело в тупик". В основном под этим мы подразумеваем, насколько легко код расширять, читать, переиспользовать. Получается, цель архитектуры — повышать все эти свойства.
03:06
Speaker A
Именно об этом говорит Роберт Мартин в своей книге "Чистая архитектура". Он попробовал коротко сформулировать цель любой архитектуры: "Цель архитектуры программного обеспечения — уменьшить человеческие трудозатраты на создание и сопровождение системы".
03:21
Speaker A
Вот это очень важная мысль, о которой многие забывают. Архитектура нужна не для того, чтобы код был читабельный и переиспользуемый. Это лишь следствия. Архитектура нужна, чтобы доставлять бизнесу новые фичи быстрее, чтобы у пользователей багов было меньше, а стабильность проекта выше. Помочь бизнесу зарабатывать. А разработчик,
03:41
Speaker A
который умеет так мыслить, и сам начинает стоить на рынке заметно дороже. Бизнесу, если честно, плевать, как вы раскладываете код по папкам, пока вы доставляете фичи не медленнее, а лучше быстрее конкурентов. Поэтому принятие архитектурных решений целиком лежит на отделе разработки. Это наша зона ответственности, и никто её за нас не закроет.
04:00
Speaker A
И вот что я пытаюсь до вас донести. Благодаря "Чистой архитектуре" у нас появилась метрика, которой можно измерять качество любого архитектурного решения. Придумали новое ограничение для проекта? Спросите себя: уменьшит ли оно человеческие трудозатраты на создание новых фич или поддержку старых? Если да, внедряйте. Если нет, значит вы вводите правило ради правила.
04:26
Speaker A
Мы разобрались, что такое архитектура. Теперь обратимся к нашей реальности, а именно, как эпоха искусственного интеллекта на неё повлияла. Ведь многие из вас перестали писать код руками от слова совсем. Так нужно ли вообще думать об архитектуре при вайб-кодинге или при аджентик-кодинге?
04:42
Speaker A
Давайте порассуждаем вместе. Привёл ли искусственный интеллект ваш проект на качественно новый уровень? Стал ли проект более гибким для внедрения новых фич? Уменьшилось ли количество багов, улучшилась ли читабельность кода? Думаю, на эти вопросы ответ скорее нет, чем да.
04:58
Speaker A
Получается, искусственный интеллект как минимум не улучшал архитектурные свойства вашего проекта, а зачастую и ухудшал. И это видели разработчики AI. Но как они могли решить эту проблему? Ведь они ничего не знают о вашем проекте, ваших нуждах, подходах, которые вам нравятся.
05:15
Speaker A
Поэтому было принято решение давать искусственному интеллекту вашу кодовую базу как контекст: агент индексирует проект, читает уже написанный код и опирается на то, как всё устроено, соблюдая установленные ранее правила. Это заметно улучшило ситуацию. Сгенерированный наспех код действительно стал куда ближе к ожиданиям разработчиков, и использование AI в командах значительно выросло.
05:37
Speaker A
Но мы всегда хотим большего. В большинстве проектов существует легаси, которым вдохновляться как раз не нужно. Мы постоянно в поиске более гибких решений и подходов, придумываем новые ограничения, дающие новые возможности. Но как сообщить о последних нововведениях искусственному интеллекту, если он продолжает генерировать легаси-код?
05:58
Speaker A
Как мы уже обсуждали в другом видео, для решения этой проблемы разработчики AI придумали передавать больше контекста посредством скилов и правил. Всё очень просто: вы описываете в MD-файлах, какую архитектуру хотите использовать, и любой агент, генерирующий код, будет на них опираться. И это
06:14
Speaker A
очень удобно. Представьте, что в ваш репозиторий контрибьютит разработчик из другой команды, который не знаком со всеми вашими правилами. Ему и не нужно: его агент будет опираться на описанные в проекте правила и использовать наиболее актуальные подходы. Согласитесь, удобно.
06:31
Speaker A
К чему я всё это рассказываю. При базовых настройках искусственный интеллект опирается либо на существующую кодовую базу, либо на правила и скилы, описанные вами. Таким образом, искусственный интеллект абсолютно не развивает архитектуру вашего проекта. Он является лишь её потребителем. Поэтому именно вы по-прежнему являетесь архитектором вашего проекта.
06:53
Speaker A
И раз многие уже пишут код только через AI, нужда в чётко описанной архитектуре растёт с каждым днём. Это единственный способ не превратить проект в помойку. И описывать эту архитектуру будет никто иной, как человек.
07:06
Speaker A
Именно поэтому я и решил поднять эту тему. Посмотрите, как смещается рынок: рядом с привычными позициями Frontend Developer или React Developer в вакансиях всё чаще появляется новая позиция Agentic AI Developer. А популярные площадки вроде Udemy и Coursera уже массово открыли курсы по переобучению и подготовке кадров под неё.
07:28
Speaker A
Не пугайтесь, если фраза Agentic для вас новая. Идея простая. Вы босс, а искусственный интеллект — ваш ассистент. Вы принимаете все решения, вы несёте ответственность за код, ломающий прод, вы несёте ответственность за каждое сообщение, отправленное искусственным интеллектом от вашего имени. AI лишь забирает рутинную работу. Он
07:49
Speaker A
генерирует код. Он проводит исследование по логам. Он постит статусы по задачам в Slack перед дейли-митингом. Он быстро знакомится с большим объёмом информации и даёт вам выжимку.
08:00
Speaker A
Надеюсь, мне удалось провести границу между вашей зоной ответственности и зоной ответственности.
08:14
Speaker A
видел во всех своих проектах: за архитектуру каждого проекта или репозитория отвечают именно люди. И нужда в хороших архитекторах сильно выросла. Размер кодовой базы у всех уже вырос и будет расти ещё быстрее, а вам нужно постоянно принимать решения, каким образом всё это разместить в проекте. И конечно же, у меня есть ответ на этот вопрос.
08:37
Speaker A
Ответ у меня действительно есть. Но дать его целиком за оставшуюся часть видео, конечно же, невозможно. Поэтому я разберу хотя бы одну полезную мысль, которая позволит вам приблизиться к мышлению настоящего архитектора: "Начните мыслить на уровне абстракций вместо имплементаций".
08:55
Speaker A
В Википедии про абстрактное мышление есть хорошая формулировка: “При абстрактном мышлении человек выходит за рамки привычной системы координат и правил мировосприятия, абстрагируясь от внешней действительности и пытаясь сконцентрироваться исключительно на исследовании мысли или идеи.” Мне это нравится, потому что отлично ложится на рабочую реальность. Вам ставят задачу, и вам нужно
09:18
Speaker A
абстрагироваться от текущих деталей проекта, чтобы сконцентрироваться на исследовании самой задачи. Давайте посмотрим, как это работает на практике.
09:26
Speaker A
Представьте: от бизнеса пришёл запрос, что много жалоб на баги, и нужно срочно что-то делать. Вы обнаружили, что у вас нет никакой системы мониторинга прода, и решили подключить Sentry. Завели аккаунт, попросили искусственный интеллект интегрировать его.
09:42
Speaker A
В итоге по всему проекту появился вот такой код. Остаётся задеплоить и начать мониторить ошибки. Это базовая реакция большинства разработчиков, и вполне рабочая стратегия.
09:54
Speaker A
Но можно подойти чуточку иначе. Тот же кейс, только вместо прямой интеграции Sentry мы сначала создадим небольшой модуль, скорее даже локальную библиотечку, для логирования ошибок на клиенте. Код очень простой, буквально пять строк.
10:09
Speaker A
На этом моменте могу вас поздравить. Вы только что увидели абстрактное мышление в действии. Вероятно, вы недоумеваете: разница ведь микроскопическая. Но она есть, и она куда существеннее, чем кажется на первый взгляд.
10:23
Speaker A
Первое и самое главное: новое решение абсолютно не зависит от инструмента. Посмотрите на этот код ещё раз и ответьте: что здесь используется, Sentry, Datadog, Bugsnag или что-то третье? Из кода ответить невозможно.
10:36
Speaker A
Это и есть шаг в сторону мышления абстракциями: общий модуль logger вместо конкретного инструмента Sentry. Но зачем? Такой подход даёт гибкость. Сейчас покажу, насколько большую.
10:47
Speaker A
Представьте, проект вырос до миллионов строк и сотен тысяч пользователей в день. Логов стало очень много, а в некоторых сервисах вроде Datadog счёт за использование может достигать сотен тысяч долларов. И вы решаете переехать на решение подешевле, например Coralogix.
11:03
Speaker A
Сравним интерфейсы этих двух инструментов. Как видите, есть крайне похожие варианты использования. И благодаря AI мигрировать сотни или тысячи схожих мест в коде технически несложно. Только вот мержить пул-реквест на тысячи файлов придётся, скрестив пальцы, в надежде что всё хорошо. И не забывайте, что все тесты тоже придётся обновить.
11:24
Speaker A
Попробуем ещё усложнить ситуацию. В крупных компаниях вам скорее всего вообще не разрешат просто удалить старый логгер из прода одним махом. Это слишком рискованно. Вас попросят добавить второй логгер параллельно и скрыть его за фича-флагом, чтобы включать и выключать функциональность прямо в проде без деплоя.
11:42
Speaker A
Дальше классика безопасной раскатки: включили новый логгер на 10% пользователей, сравнили, что логи в обеих системах идентичны, постепенно раскатили на 100%, а старый выключили. Звучит перестраховочно, но в большом бизнесе всё именно так и работает, на это есть объективные причины.
12:02
Speaker A
Что это значит с точки зрения кода без абстракции. Первый пул-реквест: добавить фича-флаг и второй логгер во все тысячи мест. Мержите с горем пополам, деплоите, раскатываете, убеждаетесь, что всё работает. И сразу же готовите второй пул-реквест: удалить старый логгер и флаг из тех же тысяч файлов. Два гигантских PR, сложное ревью,
12:24
Speaker A
надежда, что ничего не сломалось при таких больших изменениях. А теперь как ту же проблему решает наша микроскопическая абстракция.
12:32
Speaker A
Оба адаптера и фича-флаг живут внутри одного модуля logger. Вся безопасная раскатка с процентами пользователей остаётся, бизнес получает те же гарантии. Но переключение между инструментами происходит в одном файле. Не два пул реквеста на тысячи файлов, а пара правок в одном месте. Большая миграция всего в пару строк, и ощущение безопасности при этом бесценно.
12:54
Speaker A
Если вы думаете, что эта ситуация слишком редкая, переезд с одного инструмента на другой, тогда вот вам ещё примеры. Сколько изменений нужно сделать при обновлении версии Sentry?
13:04
Speaker A
А если вы хотите исключить из логов все 401 ошибки или ошибки при вызове AbortController, так как это ожидаемое поведение? Может, вы хотите в контекст положить trace id, который приходит с сервера и доступен в ошибке. Вариантов много.
13:20
Speaker A
И во всех этих случаях маленькая абстракция позволяет сделать все изменения практически в одном файле. Такая простая идея, но даёт чувство безопасности, и конечно же гордости, что благодаря такой простой идее упростил себе жизнь очень сильно.
13:35
Speaker A
И самое интересное, что этот подход не что-то новое и нестандартное. Это лишь применение базовых принципов программирования. Библиотечка logger это не что иное, как инверсия зависимостей, пятый принцип SOLID, который заставляет код зависеть от интерфейса, а не от имплементации.
13:47
Speaker A
И это очень важная мысль. В самом начале разработки логгера ваша энергия должна уходить в первую очередь на придумывание интерфейса для вашей абстракции. Как вы планируете пользоваться этой абстракцией? Что именно вы заимпортите? Это будет объект или сразу функция, с каким именем,
14:03
Speaker A
какие параметры будет принимать эта функция и так далее и тому подобное. Для большей ясности рассмотрим всё тот же логгер. Я решил, что буду импортировать из моей абстракции объект logger: название говорящее, с достаточно предсказуемыми методами error, warn и info. С параметрами пришлось подумать. Принял решение отправлять первым параметром
14:24
Speaker A
кастомное сообщение, потому что error message не всегда репрезентативен и читабелен, а с кастомным сообщением ошибки удобнее группируются, да и место с ошибкой в проекте легче найти поиском.
14:35
Speaker A
Вторым параметром решил сделать объект с обязательным полем error. Мне нравится использовать объекты в параметрах. Не важен порядок параметров.
14:44
Speaker A
Можно от какого-то параметра избавиться, просто игнорируя его передачу, и наоборот, добавить ещё один для узких ситуаций. И при всём этом вы не ломаете обратную совместимость вашей абстракции.
14:56
Speaker A
Как видите, можно пользоваться такой абстракцией каждый день и не догадываться, сколько смысла вложено в каждое название, метод и параметр. За обычным именем могут стоять самые громкие паттерны и базовые принципы, и все они направлены на главную цель архитектуры: уменьшить человеческие трудозатраты на создание и сопровождение системы.
15:17
Speaker A
У нас действительно получилось сократить огромные пул-реквесты до пары файлов. И для этого не понадобилось ничего особенного, кроме понимания, что задачу можно выполнить иначе.
15:31
Speaker A
Это лишь один пример, как вы можете приблизить себя к архитектурному мышлению. Грань настолько тонка, что практически незаметна невооружённым глазом. И мы учимся видеть её только спустя годы собственных проб и ошибок. Как только вы попробуете миграцию одного логгера на другой в большом проекте, вы наконец-то задумаетесь, что что-то идёт не так. И возможно,
15:53
Speaker A
это и станет вашей отправной точкой к созданию микроабстракции. И только прочувствовав эту боль, вы начнёте создавать абстракцию над вашим логгером уже в абсолютно всех проектах.
16:05
Speaker A
Это и есть самый настоящий боевой опыт. Но это не единственный способ развить себя. Можно использовать и чужой опыт. Для этого придуманы книги, конференции, мастер-классы, YouTube видео. И вместо того, чтобы с нуля тратить долгие годы на набивание шишек, вы можете послушать лекцию, посмотреть презентацию и понять, как ваш проект может быть устроен
16:26
Speaker A
немного иначе. Как вы уже видели, небольшое изменение может привести к большому результату. Но у меня для вас есть даже большое изменение, я бы сказал, огромное. Я самолично создал целую архитектуру, которая прижилась в абсолютно разных доменах. И это не выдумка, которую я набросал на
16:44
Speaker A
коленке за последние полгода. Впервые я придумал и интегрировал эту архитектуру в 2019 году. И с тех пор перевёл на неё все проекты и компании, в которых работал. И это было просто сделать.
16:57
Speaker A
Моя архитектура была на голову выше любой архитектуры, которая была интегрирована в проект до моего прихода. И нет, она не была идеальной. Она просто была лучше, чем то, что было в проекте на момент моего прихода туда. Я собрал о ней фидбек у многих лучших умов из разных
17:13
Speaker A
стран и абсолютно разных доменов. Финансовое приложение, мессенджер, мониторинг хостинга, видеоредактор. Всё это реальные домены, куда я интегрировал свои наработки.
17:23
Speaker A
Я презентовал её в офисе APC в Амстердаме, когда там жил. Я летал презентовать её коллегам в Израиль, причём дважды: в компанию ControlUp и в мою нынешнюю компанию Riverside, стартап уровня единорога. Туда наняты одни из самых дорогих кадров рынка из разных стран: авторы известных книг по разработке,
17:41
Speaker A
выходцы из Google Meet, которых позвали выводить качество связи на новый уровень. И при всех этих личностях для архитектуры React-приложений используется именно моя архитектура. А всё потому, что она простая для понимания и использования.
17:56
Speaker A
Её корневую идею можно упрощённо донести за 5 минут на курилке. Именно поэтому я и придумал для неё такое название: Simple Architecture. Всё должно быть просто. Потому что из моего опыта только простые вещи выживают на дистанции. Архитектуру нужно уметь просто
18:12
Speaker A
объяснить и просто интегрировать, и только тогда её можно называть Simple Architecture. И да, именно в ней кроется ответ на вопрос из начала выпуска: по какому принципу раскладывать миллион строк кода по файлам и папкам.
18:25
Speaker A
Это действительно лучшее, что я придумал за свою карьеру. И в эпоху AI она стала только лучше. Надеюсь, у вас появилось желание познакомиться с ней как можно быстрее.
18:36
Speaker A
И конечно же, я подготовил такую возможность. Мы записали лекции, объём которых сопоставим с 38 выпусками этого YouTube-канала. Привычный вам формат с АйТи Синяком в главной роли. Я решил не просто рассказать про свою архитектуру, а вывести ваше архитектурное мышление на новый уровень.
18:54
Speaker A
Научить вас видеть и строить архитектурные границы, анализировать направление зависимостей, осознавать уровень зацепленности модулей, ну и конечно, всё это закрепить на практике.
19:04
Speaker A
Как вы уже догадались, я подготовил для вас online bootcamp. Мы соберём всех желающих прокачаться и 7 недель подряд будем смотреть подготовленные видео, выполнять домашку, обсуждать прогресс на стримах, развивать правила для искусственного интеллекта. И на всём этом пути мы с командой будем делиться
19:21
Speaker A
своими мыслями и опытом и проверять домашки. Более детально об этом кэмпе я расскажу на стриме, который состоится на днях. Если вам интересно, обязательно подпишитесь хотя бы временно на ТГ-канал, туда буду постить все самые свежие новости по этому поводу.
19:37
Speaker A
Ну а если видео понравилось, обязательно поставьте лайк и подписывайтесь на канал. И до встречи на стриме!
19:43
Speaker A
Чао!
Topics:архитектура программного обеспеченияискусственный интеллектAI в разработкеограничения в архитектуречистая архитектураAgentic AI Developerпринципы SOLIDкодовая базаразработка ПОавтоматизация кода

Get More with the SozAI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries and speaker detection. 30 minutes free.

App Store Google Play
Or transcribe another YouTube video here →

Free tools: TXT to SRT · SRT Validator · Merge SRT · Subtitle to Text · All tools

Related Transcripts

View All
Побег из Украины в Россию. Предлагали работать в ТЦК. 7… — Transcript44:53
Побег из Украины в Россию. Предлагали работать в ТЦК. 7… — Transcript
Volkmix Bushcraft
7,888 1 Russian
Админские войны: Эпизод II. Атака клонов — Transcript0:57
Админские войны: Эпизод II. Атака клонов — Transcript
ПРЕМИЯ ДАРВИНА
71 1 Russian
Вечерний Копатыч. Выпуск 22 – методический. Часть 2 (ра… — Transcript4:40:28
Вечерний Копатыч. Выпуск 22 – методический. Часть 2 (ра… — Transcript
Kopatych Trade
27,787 1 Russian
Вечерний Копатыч. Выпуск 20 – хэйтерский. — Transcript5:39:09
Вечерний Копатыч. Выпуск 20 – хэйтерский. — Transcript
Kopatych Trade
35,166 1 Russian
Вечерний Копатыч. Выпуск 19 – стабилизированный. — Transcript3:44:54
Вечерний Копатыч. Выпуск 19 – стабилизированный. — Transcript
Kopatych Trade
19,916 1 Russian
Вечерний Копатыч. Выпуск 18 – двадцать девятый левел — Transcript3:49:55
Вечерний Копатыч. Выпуск 18 – двадцать девятый левел — Transcript
Kopatych Trade
21,646 1 Russian
Вечерний Копатыч. Выпуск 17 – почти без ограничений. — Transcript5:06:51
Вечерний Копатыч. Выпуск 17 – почти без ограничений. — Transcript
Kopatych Trade
27,169 1 Russian
Вечерний Копатыч. Выпуск 16 – обходной. — Transcript4:00:22
Вечерний Копатыч. Выпуск 16 – обходной. — Transcript
Kopatych Trade
21,792 1 Russian
Вечерний Копатыч. Выпуск 15 – нестабильный. — Transcript3:17:29
Вечерний Копатыч. Выпуск 15 – нестабильный. — Transcript
Kopatych Trade
17,075 1 Russian
Вечерний Копатыч. Выпуск 14 – пояснительный. — Transcript3:59:47
Вечерний Копатыч. Выпуск 14 – пояснительный. — Transcript
Kopatych Trade
21,715 1 Russian
Вечерний Копатыч. Выпуск 13 – образовательный. — Transcript4:19:00
Вечерний Копатыч. Выпуск 13 – образовательный. — Transcript
Kopatych Trade
21,756 1 Russian
Вечерний Копатыч. Выпуск 12 – пока ещё доступный. — Transcript3:13:56
Вечерний Копатыч. Выпуск 12 – пока ещё доступный. — Transcript
Kopatych Trade
19,762 1 Russian