Как убедить тимлида притянуть в проект Boost

Откуда такая может быть ненависть к Boost?

Всё своё ношу с собой, etc.

И как с этим можно бороться? Кто что может посоветовать? Может у кого есть свои истории успеха.

Продемонстрировать тимлиду демку с этим небольшим Boost.Filesystem, в которой были бы видны преимущества его использования и возможность удобного деплоя.

Если тимлида не вырвет на клавиатуру от сборки самого Boost, то он задумается.

А почему бы не взять Qt? Там тоже годные классы для работы с файловой системой.

Я всё слышал
А вот зацени-ка мой новый говнокод:
zamazan4ik_sallary=zamazan4ik_sallary/2

salary*

За адекватные споры у нас не увольняют и не ставят палки в колёса. По крайней мере пока что мне не ставили.

Сам соберу и прикручу к проекту - не велика там проблема.

Так он знает, что есть такое. Просто не хочет тянуть это.

Ну так пусть и Boost с собой носит. В VCS будет лежать какая-то версия Boost, при checkout выкачается и всё. Для разработчика проблем нет, удобство при работе.

А свои костыли на ровном месте писать - ну это слишком уже.

Не берут Qt потому что дорого. Холивары насчёт «Как будем GUI делать» уже были до моего устройства на работе. Битва была между Qt vs WPF. Как я понял, WPF победил.

Ну так пусть и Boost с собой носит. В VCS будет лежать какая-то версия Boost, при checkout выкачается и всё. Для разработчика проблем нет, удобство при работе.

Может он просто не хочет бинари в VCS пихать?

Сам соберу и прикручу к проекту - не велика там проблема.

Вот ты лучше собери (выдели файлы) из Boost так, чтобы из него использовалось только самое необходимое, а сам он собирался при сборке всего проекта.

А свои костыли на ровном месте писать - ну это слишком уже.

Видимо он понимает то, что раз проект не является кросс-платформенным и завязан на MFC, то Boost там совершенно ни к чему, а пару функций можно написать и самому.

Лучше покажи ему: https://msdn.microsoft.com/en-us/library/hh874694.aspx

Может он просто не хочет бинари в VCS пихать?

Сомневаюсь, так как у нас просто куча бинарей валяется в SVN.

Видимо он понимает то, что раз проект не является кросс-платформенным и завязан на MFC, то Boost там совершенно ни к чему, а пару функций можно написать и самому.

Не всё так просто :) Этот самописный велосипед потихоньку обрастает #ifdef'ами для linux, складируется в нашу библиотеку с утилитами, а потом тянется в другие проекты, которые уже не windows-only.

Лучше покажи ему: https://msdn.microsoft.com/en-us/library/hh874694.aspx

Спасибо, гляну.

убей тимлида и сам стань тимлидом.

все просто.

Не дорос я до тимлида пока что.

Так то мужик умный. Но иногда он делает очень странные вещи.

Велосипед — это обычный vendor lock-in, в мире M$ так принято :)

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

Ну и подготовить наиболее удобный способ добавить Boost на компьютер каждого разработчика (доступный для новичка-стажёра), чтобы переход был лёгким и выглядел заманчиво.

Я никак не могу, зачем он это делает

Он мудр, ибо буст - жирное говно.

Не берут Qt потому что дорого

0 это дорого ?

Код-то нормальный пишет? Если да, то в чём проблема? Если нет, то покажи ему конкретно, в каких местах буст лучше.

Ответ прост: идиоты. Так многие в мире сишек любят велосипеды. Дай ему статью почитать о бусте, желательно от какого-нибудь крутого и уважаемого программера, который пилит LLVM, к примеру.

Я никак не могу, зачем он это делает

Он мудр, ибо буст - жирное говно.

Может и не совсем Г, но то что ОЧЕНЬ ЖИРНЫЙ - это ФАКТ

Нет, часто говнокодит. Я показывал, ответ - тянуть буст не будем.

В программировании каждый второй упертый, да так, что мнит себя умнее всех других. Все как у людей. Привыкай! На кого попадешь)

Подробнее можно? я с лицензированием Qt не слишком знаком, но насколько я знаю, для коммерческой разработки нужно покупать. Бесплатно юзать можно, только если линковать не статически.

про буст он знает

А аргументы можно, почему boost - говно? И что есть лучше? Qt, POCO, smth else?

Завидую я таким тимлидам, которые не знают чем себя занять и могут себе позволить писать миленькие велосипедики. :)

Кстати, на счет тяжести буста. Все зависит от конкретной библиотеки. В некоторых случаях это будут просто хедеры. В других - придется включить в дистрибутив одну или две либы. В третьих - придется включить половину буста.

Ты попробуй подключить этот Filesystem, о котором пишешь. Может быть, там нужно будет включить в дистрибутив всего одну либу буста. Это уже будет аргумент.

Он начальник — ты дурак. Ты начальник — он дурак.

Будешь начальником — будешь решать, какие зависимости стоит тянуть, а что стоит накостылить.

Ну как минимум Filesystem не header only. Нужно линковаться с libboost_system && libboost_filesystem.

а если я подчинённый, то я должен безропотно выполнять указания и не пытаться улучшить проект? Я не согласен с такой пассивной точкой зрения

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

то я должен безропотно выполнять указания и не пытаться улучшить проект?

Ну ты предложил же ему буст. Он принял решение его не использовать. Один из вас понимает лучше, что нужно для проекта (неизвестно еще, кто). Но так как он начальник, решение в итоге принимает он.

Ну ты можешь, конечно, переписать код с бустом и попробовать его убедить.

В общем, пойнт в том, что твое рационализаторское предложение должно быть конкретным с уже готовым прототипом, чтобы можно было показать на месте, а не рассуждением на общую тему. Может быть, поможет тогда)

А в чём проблема линковать динамически? Тоже тимлид против? Я работал в коммерческом проекте, где используется самосборный Qt. Линкуемся динамически, библиотеки с собой в пакете, на сайте компании архив с исходниками и скриптом, Digia не платили, брат жив.

Два бинарника запустить и либы с хидерами закинуть по нужным путям. По крайней мере до 1.62 так собирал для своих нужд. dll и прочего там нет, ЕМНИП.

Только, конечно, это как-то надо уметь подать. Просто, чтобы не было претензий к тебе потом, что в рабочее время ты какой-то фигней занимался, а такой сценарий вполне возможен ;)

Критерий улучшения? Твой синдром утенка против его синдрома NIH?Лишние зависимости и прослойки, не? :) Выбрал себе писаную торбу, буст, носишься с ней... Нет бы комитет убедить про std::filesystem

Недостаточно модулен, жирен, нестабилен.

Например если попробуешь заюзать filesystem - у тебя весь проект должен будет знать про его типы, скажи прощай инкапсуляции реализации.

Очень легко притащить datetime по зависимостям. Или regex, а с ним icu на 40 метров. И всё это периодически ломается.

lexical_cast

95% его использования покрывается std::to_string() из c++11

ИМХО, имеет смысл действовать так:

1. Попробовать получить от тимлида список технических аргументов почему его велосипед лучше Boost.Filesystem. Может там есть разумное зерно (скажем, там идет работа с системно-зависимыми параметрами файловой системы, которые не поддерживаются в Filesystem).

2. Если на первом пункте выясняется, что никаких технических аргументов «против Boost-а» нет, то:

2.1. Вы создаете механизм простого подтягивания Boost-а или отдельных его частей в проект. Настолько простой, чтобы любой разработчик в вашей команде мог сделать это буквально «по щелчку».

2.2. Вы подготавливаете набор примеров из вашего проекта, в которых используется велосипед вашего тимлида. Переписываете из на Boost.Filesystem так, чтобы выигрыш был очевиден. Начинаете демонстрировать эти примеры вашим коллегам (пока еще не тимлиду), дабы набрать «критическую массу» снизу. Если у вас появятся единомышленники, которые начнут давить на тимлида со своей стороны, шансов будет больше.

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

Быть может, есть какие-то тайные смыслы, почему буст это плохо. Я пока от него только слышал, что он тяжёлый. Больше контраргументов не было.

Я проблемы не вижу. Начальство решило иначе.

В данном случае выкроить чуточку времени не трудно

Нет бы комитет убедить про std::filesystem

Так в MS и в мире винды, срали все на тормознутый комитет и в Visual C++ 2015 его уже добавили. #include <filesystem> и вперёд.

Не удивлюсь, если у них и реализация модулей из коробки скоро появится.
Вон тестируют что-то уже: http://blog.conan.io/2016/06/01/Building-and-packaging-C -modules-in-VS2015....

В продакшене с++17 я нескоро увижу. Если Вы предложите что-то лучшее для работы с файловой системой, нежели boost.filesystem, я с радостью выслушаю.

Моё мнение: нет смысла переизобретать то, что уже есть и работает неплохо. И оттестировано временем

Не знал про это расширение. Выглядит вполне хорошо на первый взгляд. Надо будет потыкать палкой

Что в из буст - жирное говно? Давай смелей. Какай из его десятков либ, большая часть из которых - header only?

Например если попробуешь заюзать filesystem - у тебя весь проект должен будет знать про его типы, скажи прощай инкапсуляции реализации.

Можно написать обертку какую-нибудь, повсюду буст инклудить это ж ужас.

Как убедить джуна не уговаривать тимлида тащить всякую монстроидальную дичь в проект?

Спасибо за гайд.

Разумного зерна нет: написаны свои костыли для итерации по директории, удаление файла, etc.

Большинству разрабов плевать, что есть, то и юзают. Желания улучшить есть у единиц. Насчёт демонстрации Вы правы: у меня есть кейсы, где я могу показать мне преимущество boost.filesystem.

Убедить меня в том, что свои бажные костыли лучше проверенного решения

Большинству разрабов плевать, что есть, то и юзают. Желания улучшить есть у единиц.

Тогда есть еще один путь. Но это прямая дорога к конфронтации.

Воздействовать еще можно и на менеджмент, если вести учет проблем, возникающих из-за глючного велосипеда. Тупо считать количество багов и потраченных на их исправление ресурсов (причем не только разработчиков, но и техподдержки, QA и т.д.), а так же связанные с этим задержки по срокам релизов. Затем предъявить все это менеджеру.

Дабы сразу не испортить себе жизнь, можно сперва такой статистикой донимать самого тимлида. И только если на него это никак не будет действовать, тогда уже обращаться к проджект-менеджеру и/или продукт-оунеру (не знаю, кто у вас ведает сроками/бюджетами и вообще отвечает за проект).

Это прямая дорога на биржу. Хожена многими джунами.

Хочешь ключевое, СВОИ

Видимо причина есть, но тебе ее не озвучивают ибо рано