Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Здравствуйте, AlexNek, Вы писали:

A_A>>>

время на разработку уменьшится — экономия бабла для заказчика
AN>>ну это еще нужно доказать что время на разработку действительно Существенно уменьшится, в чем я несколько сомневаюсь.
A_A>>>

заказчик будет получать продукты быстрее — сможет выходить на рынок с новым продуктом раньше — получение новых прибылей для заказчика
A_A>>>

система будет более стабильна(будет меньше возможных багов) — вероятность потери клиентов для заказчика снизится — заказчик будет меньше терять бабла
AN>>Как система контроля версий влияет на количество багов?
A_A>Я говорю не за СКВ, а за исключение потенциальной возможности изменений исходников людьми, которые не должны этого делать в данный момент.
Насколько часто это происходит что бы могло существенно повлиять на количество багов. Тем более что речь шла о непреднамеренном исправлении. Например при периименовании чего то общего, хотя переименования можно отнести даже в плюсам, не нужно парить всем остальным мозги отчего перестало компилится. Хотя и переименование не может быть "тихим" для нескольких проектов в команде.

A_A>>>С такими аргументами нормальное руководство утверждает.
AN>>А кто, сколько времени и на что будет перестраивать все остальное?
A_A>делаете предварительные исследования в свободное от работы время(это на самом деле вам же, разработчикам, нужно )
A_A>закидываете ссылками, что это можно сделать
A_A>берете время
A_A>делаете
Предположим предыдущий вариант был сделан в течении 5-ти лет по часу в неделю считаем 250 часов, то бишь хотя бы на месяц нужно все заморозить в самом лучшем случае (Даже пусть на неделю). При этом далеко не очевидно что новая версия будет работать абсолютно идентично. Пусть даже если и делать все на игрушечной копии, после переноса обязательно будут затыки и в конце концов выяснится что новый подход не позволяет что-то сделать, что мы не заметили при анализе.
То бишь риски существуют, что так горячо лоббируемый переход дал больше новых проблем, чем решил.
Предлагаю догадатся, кто будет виновать в этом случае

Cообщение написано в << RSDN@Home 1.2.0 alpha 5-AN-R6 rev. 8461>>

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Здравствуйте, AlexNek, Вы писали:

Q>>>>>Когда угодно. У тебя стоит ссылка на пакет версии 3.4.0.128. То, что на билд-сервере появляются версии 3.4.0.129, 3.4.0.130, etc твою программу не ломает. То же, что и со сторонними библиотеками. Скажем, используешь ты NUnit 2.5.9.10348. То, что вышла новая версия NUnit 2.5.10.11092 никоим образом на твою программу повлиять не может, пока ты сам не решишь обновиться.
AN>>>>Во внутренности NUnit мне не нужно лезть. Допустим получил я от библииотеке 0, а должно быть 5. Лезешь с отладкой и видишь что 0 ну никак не может получится. А это просто версии исходников и либы не совпадают.
A_A>>>Нужно собирать либу с такой версией, чтобы можно было найти реальные исходники.
AN>>Кто и как будет проверять версию Длл-ки при входе в функцию?
A_A>Тут поможет перегрузка функций, если уж совсем никак.
Примерчик мона?

AN>>>>>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.

Q>>>>>Не понял вопрос. Твоя переиспользуемая библиотека теперь выглядит так же, как не твоя переиспользуемая библиотека. От которой у тебя нет, и не нужны исходники. Все проекты всегда ссылаются на точную версию строгоименованной библиотеки.
AN>>>>Кажется, я уловил проблему. Все будет работать когда ВСЕ проекты подключены как Длл-ки (исключая вариант с отладкой кода). Но если я разработчик и мне нужно иметь актуальную версию Длл-ки, то их получается уже две версии. Одна собранная по исходникам, другая из репозитория. Дя какого-то небольшого количества еще можно все отследить, но когда и тех и других достаточно много да и еще со сложными зависимостями, остается только ждать накладки.
AN>>>>Должен быть всегда один источник и смешанная работа просто не допускается. Или всегда абсолютно все свои текущие проекты как Длл-ки с сервера или все подключения через проекты (кроме чисто библиотечных, считаемых как бы не своими). То есть если есть иерархия проектов, то вся ветка либо/либо, но никак не комбинация в ветке.
A_A>>>Да. перемешивать нельзя — бардак будет еще тот.
AN>>А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?
A_A>А в чем проблема-то?
A_A>Просто надо больше комунницировать, чтобы о таких изменениях все были в курсе.
А если было сказано об изменениях, но допустим забыли, что то сделать, что привело к "рассогласованию" исходников с бинарниками.

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, AlexNek, Вы писали:

AN>>PDB то будет идти с Длл-кой, но вот гарантировать совместимость исходников с ними, да проблема.
AN>>И кстати, как сгенерить PDB без DLL-ки?

Q>http://www.rsdn.ru/forum/philosophy/4503615.aspx

Автор: Qbit86
Дата: 19.11.11

И где же там ответ на поставленный вопрос?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, AlexNek, Вы писали:

Z>>>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?
AN>>Аргументируют, что Длл-ку имеет право изменить только "автор". А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.

ГВ>Странная аргументация, очень странная. Она допустима только при одном условии: если автор работает в другой компании. Если все "авторы" работают в одной конторе — исходники должны быть доступны всем.
Речь идет о непреднамеренном изменении, причем в уже протестированной части (и "закрытой") части. А исходники и так доступны всем при двух вариантах. Только при подключении Длл-ок нужно целенаправленно лезть в иходники, а при подключенных исходниках это может сделать и прога рефакторига.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AlexNek, Вы писали:

AVK>Сначала ответ — лучше исходники, так как это позволяет легче понимать код (навигация при просмотре по зависимостям не обрывается на бинарниках). Единственный момент, который стоит помнить — это влияет на производительность студии. Но если проект суммарно не очень большой, или если машина на современном уровне, то замедление обычно некритично.

AN>>Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки

AVK>При наличии решарпера особенно полезно иметь исходники. Настолько полезно, что решарпер игнорирует нафик бинарные ссылки, если ему удается найти исходники, которые бинарнику соответствуют.

Есть небольшая проблемка, что нужно иметь все исходники и без "выкрутасов". А то тестеры добрались до тестирования не public частей в своем проекте, а потом плачутся на вносимые изменения.
AN>>А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, AlexNek, Вы писали:

AN>>Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".

ГВ>Задача-максимум: иметь возможность полностью пересобрать все проекты на любой машине разработчика.
Вообще то это задача минимум. Точнее, собрать конечный проект на любой машине разработчика. А пересобрать все бывает часто просто невозможно из-за ограничений по лицензии. А если даже все проекты свои, все равно могут быть ограничения. Например, для сборки одной из частей требуется "подписывать" данные в ресурсах приватным ключем.

ГВ>Но много зависит от размера исходников. Если у вас их сотни мегабайт с полусуточным циклом компиляции, то, пожалуй, полный доступ нужен только для справочных целей, а для работы достаточно периодически обновляемых бинарников.
Это уже вопрос оптимизации.
ГВ>А если сборка всех ваших исходников укладывается в час-два (сторонние библиотеки сейчас не считаем), то уместно иметь полную копию всех исходных текстов.
Я бы сформулировал следующее. Если проект находится в конечном листе иерарахии проектов, то с целью экономии времени, лучше поключать Длл-ки.

Здравствуйте, Jiteco, Вы писали:

...
AN>>Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".

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

Здравствуйте, AlexNek, Вы писали:

AN>И где же там ответ на поставленный вопрос? :shuffle:

Там задаётся встречный вопрос — зачем поставлять pdb с бинарниками?

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, AlexNek, Вы писали:

AN>>И где же там ответ на поставленный вопрос?

Q>Там задаётся встречный вопрос — зачем поставлять pdb с бинарниками?
Я заметил там только "я никогда не использовал чужие pdb". А зачем вроде и так понятно. Какой есть еще стандартный и простой способ, что бы глянуть исходники кода где произошло допустим прерывание, при наличии исходного кода.

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

Здравствуйте, AlexNek, Вы писали:

AVK>>Это регулируется техническими средствами — либо единым репозиторием, либо внешними ссылками на нужные репозитории.
AN>Репозиторий и так один, а вот забыть еще в одном месте кнопочку нажать, довольно просто.

Что значит в одном месте? Есои репозиторий единый, для апдейта нужно нажать кнопку ровно один раз ровно в одном месте.

Здравствуйте, Andrii_Avramenko, Вы писали:

AN>>А у меня есть исходники .NET Framework в проекте?
A_A>Догадываюсь, что нету.

А у меня есть. Не в проекте, правда, но студия и решарпер прекрасно их получают и позволяют по ним отлаживаться.

A_A>Так значит юзание библиотек является достаточным.

Две ноги тоже достаточны для перемещения.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Задача-максимум: иметь возможность полностью пересобрать все проекты на любой машине разработчика. Но много зависит от размера исходников. Если у вас их сотни мегабайт с полусуточным циклом компиляции, то, пожалуй, полный доступ нужен только для справочных целей, а для работы достаточно периодически обновляемых бинарников. А если сборка всех ваших исходников укладывается в час-два (сторонние библиотеки сейчас не считаем), то уместно иметь полную копию всех исходных текстов.

Речь про .NET, а там время сборки даже очень больших проектов на нормальной машине единицы, в экстремальных случаях десятки минут.

ГВ>А всякие параноидальные "защиты" — это всё детсад, напакостить при желании можно где угодно. Скажем, кто-то даст кому-то по дружбе доступ к репозиторию...

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

ГВ> Короче, всё это разговоры в пользу бедных — организационные задачи техничесиким средствами не решаются.

Иногда решаются, но серпом по яйцам ради сомнительных проблем ...

Здравствуйте, Qbit86, Вы писали:

Q>Откровенно говоря, я не знаю деталей внутреннего устройства PDB и тонкостей их распространения вместе в библиотеками. Но во всех (немногочисленных, но без исключения) NuGet-пакетах, которые таки содержали PDB-файлы, при открытии последних видны строки типа «C:\Users\VasyaPupkin\SomeProject\SomeModule\SomeClass.cs». Простите мне моё невежество, но, емнип, я никогда не использовал чужие pdb. Скажите, они вообще работают?

Работают.

Q> И если да, то как?

Так же как и свои собственные.

Q> Я так понимаю, они нужны для связи символов с исходниками. И судя по тому, что я вижу внутри pdb-файла, они связывают символы с исходниками разработчика, а не моим комплектом исходников.

Если ты про абсолютный путь, то студия умеет его заменять. При первой необходимости она спросит тебя, где находится файл MySuperClass.cs и после этого будет брать исходники оттуда.

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>>Здравствуйте, AlexNek, Вы писали:

A_A>>>>1) Если нет человека с такой должностью — нужно завести должность и взять человека
AN>>>А зачем, когда можно вполен обойтись без него просто использую другой подход.
A_A>>Так в чем проблема? Используйте тот подход, который для Вас более выгоден.
AN>Хотелось бв иметь какие то критерии для выборато гото или иного подхода.
AN>Получается тогда для подхода с Длл-ками желателен отдельный человек.
там, по сути дела, работы не особо много.
Задача — автоматизировать этот процесс.
У нас в этом процессе учавствуют: svn, TeamCity и NuGet(+кастомные таски для NuGet).
svn у вас есть, если есть CI, то я думаю до получения первого стабильного фида от NuGet займет не более 40 часов для 1 человека.

A_A>>Если был бы простенький проект на 2-3 человека с 10-15 проектами — тогда бы овчинка выделки не стоила и юзание сорцов по ссылке было удобнее.
AN>Честно говоря, не вижу зависимости удобства от количества, если не учитывать какие то определенные параметры, например время компиляции (в данном случаем им можно пренебречь). То бишь нужно определится с критериями.
Ну, имхо, в будущем будет прозрачнее наблюдать версионированную длл-ку, отвечающую за какую-то функциональность,
чем лезть в svn и искать в истории своего проекта, какую же версию общего функционала он юзал
хотя, вероятность в такой нужде конечно невысокая

Здравствуйте, AlexNek, Вы писали:

AN>>>Значит голос за Длл-ки?
AN>>А как быть тогда с совмещением ссылок на Длл-ки и проекты?
A_A>>Можно по-детальней?
AN>Допустим есть решение использовать подключение через Длл-ки, тогда абсолютно все проекты обязаны подключаться как Длл-ки, а Длл-ки браться из одного места. AN>>Что тогда делать разработчику Длл-ки?
AN>Ведь ему вначале нужно иметь локальную копии для проверки/тестирования, а наличие копии входит в противоречие с требованием "одного источника". Точнее, это AN>>требование является необходимым для "внутренностей" ветки иерархии проектов/Длл-ок. Окончания веток- листики этому требования не подчиняются. Их можно AN>>включать как нужно в данной ситуациии.
Здесь немного не ясно.
Разработчик длл-ки ничего и никого не ждет(это ж будет какой-то общий функционал) — наоборот, его все ждут
Копия чего ему нужна?
Он делает новый функционал согласно появившимся требованиям.
Если функционал еще не существует — что проверять-то тогда?
A_A>>Что делать разработчику именно этой Длл-ки в проекте?
A_A>>тут есть два варианта:
A_A>>1)Длл-ка принадлежит другой команде — вносится тикет на создание в ней фичи и ждем, когда эта команда нам выдаст новую длл-ку.
AN>Тут видимо подразумевается, что проект принадлежит конечному листу иерархии проектов.
A_A>>2)длл-ка наша — мы сами с ней делаем что хотим и не ждем никогда
AN>Вот именно ждать и нужно. "Владелец" Длл-ки нужен вначале найти и исправить проблему, а остальные ждут пока будет готова очереная порция Длл-ок.
Так в варианте с исходниками тоже ждать остальным придется.
Если вопрос во времени билда новой версии и доставка ее всем нуждающимся — то без автоматизации — никак.
Считаем:
Время билда — время компиляции проекта (+- работа CI — но там секунды)
Время доставки — изменение строки в конфиге NuGet, и работа батника — минута делов
AN>>Хотя можно AN>>сказать, берите файл х проекта У. К тому-же разработчик при создании локальной Длл-ки, должне пользоваться "другим источником" — исходниками. AN>>А при использовании второго источника должна быть гарантия, что эти два истоника синхронизированы. К тому нужно иметь и локалный механизм "подмены" Длл-ок.
Да, пока автоматизацию длл-ок не сделаете — однозначно юзать только ссылки на исходники, а то времени и нервов впустую будет уходить много
AN>>И что делать остальным когда исходники уже в репозитории, но бильд длл-ок еще не готов. Ждать пока не будет все готово и после все брать?
AN>>А если в это же время закоммитились другие изменения, которые нужно пока избежать? (Допустим они исправили генерацию данных, и неправильные данные для теста уже получить просто невозможно)
A_A>>Это сложный вопрос. Опять же:
A_A>>1) Если длл-ка ваша — то вы всегда в курсе всех изменений
AN>Даже если и в курсе, нужно отслеживать и исходники и бинарники (в случае подключения Длл-ок), да и еще желательно знать зависимости бинарников.
Зачем что-то отслеживать?
Один обновил длл-ку -> сообщил нуждающимся номер версии и суть обновлений -> они скачали и юзают.
А вот если будут проблемы и захочется найти виновного — то разбираться придется со своим проектом, и версией исходников длл-ки
(в соответствии версии длл-ки исходникам мы ведь не сомневаемся — это ж происходит без участия человека)
A_A>>2) Тут надо отслеживать все изменения с текущей версии по ту, которую хотите заюзать.
A_A>>То есть нужно отслеживать два источника: исходники и бинарники, и к тому же учитывать иерархию бинарников.
A_A>>1) Если длл-ка ваша — вы следитие только за сорцами — на версии вам пофиг
AN>Пофиг не могут быть, ведь подключаются только Длл-ки. (Не говорим о "конечных листиках")
A_A>>2) Следите только за изменениями в функционале и версиями — на сорцы вам пофиг
AN>на сорцвы не пофиг, откуда бильдить локальные версии на время правки?
насколько я понял, длл-ка принадлежит "нашей" команде, так что этот пункт уже не имеет значение

Здравствуйте, AlexNek, Вы писали:

AN>>>А кто, сколько времени и на что будет перестраивать все остальное?
A_A>>делаете предварительные исследования в свободное от работы время(это на самом деле вам же, разработчикам, нужно )
A_A>>закидываете ссылками, что это можно сделать
A_A>>берете время
A_A>>делаете
AN>Предположим предыдущий вариант был сделан в течении 5-ти лет по часу в неделю считаем 250 часов, то бишь хотя бы на месяц нужно все заморозить в самом лучшем случае (Даже пусть на неделю). При этом далеко не очевидно что новая версия будет работать абсолютно идентично. Пусть даже если и делать все на игрушечной копии, после переноса обязательно будут затыки и в конце концов выяснится что новый подход не позволяет что-то сделать, что мы не заметили при анализе.
AN>То бишь риски существуют, что так горячо лоббируемый переход дал больше новых проблем, чем решил.
AN>Предлагаю догадатся, кто будет виновать в этом случае
Делаете пилотные проекты(лучше скопировать текущие самые сложные, с наибольшим количеством зависимостей) — на них играетесь
Потом постепенно переводите текущие на новую систему.
Риски всегда есть. Чтобы о них узнать заранее нужно проводить ресерч.
А по поводу переходить или нет — выписываешь в список плюсы и минусы существующей системы и новой(насколько возможно собрать информацию)
и будет ясно.

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

Здравствуйте, AlexNek, Вы писали:

A_A>>>>Нужно собирать либу с такой версией, чтобы можно было найти реальные исходники.
AN>>>Кто и как будет проверять версию Длл-ки при входе в функцию?
A_A>>Тут поможет перегрузка функций, если уж совсем никак.
AN>Примерчик мона?
Есть класс в длл-ке(который лезет в базу за данными), у которого паблик только дефолтный конструктор.
Его уже юзают кучка клиентов.
В новой версии для нового клиента понадобилось добавить в этот класс возможность повтора подключения к базе,
если она не доступна.
Перегружаешь конструктор и юзаешь новую версию в новом клиенте.
Все остальные клиенты юзают старую версию.
Делаешь техническую таску на новую итерацию — отрефакторить всех остальных клиентов на юзание новой версии длл-ки.

AN>>>>>>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.

AN>>>А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?
A_A>>А в чем проблема-то?
A_A>>Просто надо больше комунницировать, чтобы о таких изменениях все были в курсе.
AN>А если было сказано об изменениях, но допустим забыли, что то сделать, что привело к "рассогласованию" исходников с бинарниками.
Автоматизация без участия человека не допустит рассогласования исходников с бинарниками.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Andrii_Avramenko, Вы писали:

AN>>>А у меня есть исходники .NET Framework в проекте?
A_A>>Догадываюсь, что нету.

AVK>А у меня есть. Не в проекте, правда, но студия и решарпер прекрасно их получают и позволяют по ним отлаживаться.

А в чем профит от отладки по исходникам .NET Framework?
Пересборка его все равно не имеет смысла.
Для меня например важно, что функционал какой-то библиотеки выполняет заявленные требования.
Если не выполняет, то по какой причине:

если я передаю некорректные входные параметры, то какие именно и какие границы корректности

если по вине библиотеки, то это уже не моя проблема
Во всех случаях я не вижу практического смысла в наличии исходников.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Andrii_Avramenko, Вы писали:

ГВ>>>А как он узнает, что бага в такой-то библиотеке а не в его коде?
A_A>>К примеру при вызове метода поймает NotImplementedException

ГВ>А как он будет такую проблему решать? Неужели кинется дописывать код?

Это примерчик я привел смеху ради конечно

Более реальный, когда ловит IndexOutOfRangeException

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Разве что очень поверхностная. На самом деле тут вопрос в цене. ИМХО, всяко проще объяснить людям, что не надо лазить в чужой код (читай, рассказать о правилах ГВ>перестроения), чем выдумывать сложные инструментальные подходы (читай, строить отдельный путепровод для каждого маршрута из всех точек А во все точки Б).

Плохое я сделал ТЗ в начале, не детализированное
Давайте уточним.
Заказчик: министр внутренних дел
Бизнес требование: организовать гарантированное безопасное двухстороннее автомобильное движение на дороге
Имеем: на дороге отсутствуют какие-нибудь знаки, разметка и т.п., зато присутствуют нарушения двухстороннего автомобильного движения.
Организационное решение:
1) Наносим одинарную разделительную полосу — обучаем всех водителей, что пересекать ее низзя ни при каких условиях.
Рапортуем министру, что теперь двухстороннее автомобильное движение на дороге будет безопасным.
Идем пить пиво с министром за клево сделанную работу
Министр вызывает нас на ковер и негодует — нарушения остались.

2) Наносим двойную разделительную полосу — обучаем всех водителей, что пересекать ее низзя вообще никак(даже наезжать на нее) ни при каких условиях.
Рапортуем министру, что теперь-то уж точно двухстороннее автомобильное движение на дороге будет безопасным.
Идем пить пиво(без министра — нефиг негодовать на нас по пустякам) за клево сделанную работу
Министр вызывает нас на ковер и снова негодует — нарушения остались.
Вот, блин, достал уже, думаем мы.
А не свалить ли в министерство юстиции работать — там деньги те же платят, но хоть заказчик нормальный...

3)Устанавливаем знаки(ограничение максимальной скорости, запрет обгона) — обучаем всех водителей, что нарушать их низзя ни при каких условиях.
Рапортуем министру, что теперь-то уж верняк двухстороннее автомобильное движение на дороге будет безопасным.
Идем пить пиво(без министра — ну его, че-то он какой-то нервный последнее время) за клево сделанную работу
Министр вызывает нас на ковер и опять негодует — нарушения остались.
Да иди ты [направление поскипано] со своей дорогой, думаем мы.
Сваливаем в министерство юстиции.

4) Пришла другая команда и забацала путепровод.
Другая команда идет пить пиво с министром за клево сделанную работу

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

Имхо, разница в цене очевидна, если нужна гарантия.
Да и инструментальный подход попроще буит, а главное — гарантирует результат.