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

ну например «да это баг критический но мы его пофиксим в седующей мажорной версии которая выйдет через два года»,

или как в одной JSON библиотеке: есть фича подмешивания свойств, и инициализация через конструктор, народ завел тикет что если их совместить то выдает ошибку, но вот легкий воркароунд есть. Автор-чудак взял и в ответ отключил возможность инициализации через конструктор объектов с миксинами, мол потом переделаю, ну и как итог всем сломал код в новом минорном релизе.

mvp

что такое mvp?

Вообще да, шанс что так и нужно, есть. Нельзя огульно судить

Есть две крайности – «не использовать внешние библиотеки ваще» и «всё решать фреймворками и зависимостями». И то и то плохо, нужно соблюдать баланс.

В случае с JSON-библиотекой можно либо самим «по-бырому» пофиксить, либо не переходить на следующий минорный релиз.

Есть две крайности

Это очевидно, я про буст спрашивал. Потому что если там в минорных релизах фиксят баги подобным образом то тимлид прав 8)

В случае с JSON-библиотекой можно либо самим «по-бырому» пофиксить, либо не переходить на следующий минорный релиз.

Форк библиотеки - это зачастую хуже чем делать свою. Так что в том случае я просто внимательно изучил багтреккер и не стал комбинировать сии «фичи».

ну если хватает знаний и времени для написания фикса и отправку его в Boost - то почему бы и нет?

Лезет иногда, но очень редко.

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

Если Вам нетрудно, то можете рассказать, на каких условиях Qt бесплатна для коммерческой разработки?

Эффективность в плане скорости что ли? Абсолютно не требуется в нашей ситуации.

Инфраструктура - а её и нет сейчас толковой.

Если я не ошибаюсь в любых случаях кроме случая когда ты хочешь внести изменения в qt, но при этом не распостранять свои изменения qt части как опен сурс. Эксперты, поправьте если я не прав.

воистину прав, хотя я не эксперт :)

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

Тогда я кажется понимаю тимлида :) Из-за небольшого куска кода тащить слона в кладовку

если хватает знаний

А точно хватает?

времени

Твоё рабочее время принадлежит твоему работодателю. Почему он должен платить за фиксы какого-то левого тулкита?

всё это делается очень медленно, очень и очень. На самом деле итак удалось довольно много сделать: я показал тимлиду, что статический анализ действительно умеет искать ошибки, и ошибки довольно серьёзные. После пары писем со здоровенными списками ошибок и списком тулз, которые юзались для их поиска, он дейтсивтельно оценил и сказал, что мол годные утилиты. Уже маленькая победа. Следующий шаг - уговорить встроить это дело в night builds, чтобы крутилось постоянно, а не только когда я локально проверяю наши проекты, а потом рассылаю письма счастья и лезу править баги.

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

Я смог убедить, что гадить постоянно в trunk - крайне фиговая идея, и для мало-мальски серьёзной вещи нужно создавать отдельную ветку, и только потом мержить ветку с основой.

Я показал, что заниматься всякими оптимизациями без профайлера - ну крайне фиговая затея, и если уж заниматься оптимизацией кода, то нужно гонять профайлером, а не «ну тут я вот позаменяю контейнеры и ускорю программу на 0.1%.». А то, что асимптотику алгоритма по соседству можно неплохо так снизить и получить выигрыш в программе до 10% - так это в глаза не бросается.

Я всё это считаю маленькими, но победами. И работать стало приятнее.

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

Хм, спасибо. Надо будет выяснить подробнее тогда про холивар Qt vs WPF. Если мы сможем отказаться от WPF, то есть очень большой шанс, что C# часть из проекта пропадёт.

Лично мне не жалко своего личного времени написать фикс в Boost. Вопрос только в том, что стоит разобраться в недрах. А это не так просто.

Вопрос только в том, что стоит разобраться в недрах.

Вот-вот.

Это очевидно, я про буст спрашивал. Потому что если там в минорных релизах фиксят баги подобным образом то тимлид прав 8)

Ну тут мы не знаем подробности, да. Возможно тимлид прав. Он неправ однозначно в том, что не может адекватно донести свою точку зрения до ТС.

Форк библиотеки - это зачастую хуже чем делать свою. Так что в том случае я просто внимательно изучил багтреккер и не стал комбинировать сии «фичи».

Один мелкий патч легко поддерживать. Обновление библиотеки – это всегда ручной процесс. Тем более, через релиз можно отказаться от собственного патча или отправить его в апстрим.

В свободное время можно и посидеть :)

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

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

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

И т.п.

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

Он неправ однозначно в том, что не может адекватно донести свою точку зрения до ТС.

Тебя не посещает мысль, что до ТСа в принципе невозможно донести мысль? Ну или, к примеру, что ТСу уже раз объяснили, но не помогло?

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

отправить его в апстрим.

Где его отфутболят, а может и нет, опять видишь ли проблема.

И вот там тимлид сидит и пишет свои костыли для работы с файловой системой: итерация по директории, удаление файла и т.д.

Здесь только буст :-) Даже без вариантов :-) Лол :-)

Версия boost бампается: снова пересобираешь?

А чем это отличается от любой другой зависимости? Сначала смотрим нужно ли нам обновление, затем не поломали ли чего. Если всё устраивает - переходим на новую версию. Пересобрать тут меньшая из проблем.

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

Ерунду пишешь. У WinAPI отличная обратная совместимость, а разница между версиями документирована.

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

Это говорит только о тупизне разработчика.

Опровергнуть меня легко - давай в студию WinAPI вызов из kernel/user/winsock со сломанным поведением.

Ад с левыми библиотеками я уже познал, спасибо. Мне тут openjpeg веселья принёс.

ТС вроде как слабоумием не страдает, но почему-то ему кажется, что писать свой Boost.Filesystem не очень хорошая затея. Вашу идею с саппортом своего поделия вместо потенциальной боли с левой библиотекой я давно осознал.

Тогда вы и на c++ зря пишете. Создавай новый топик: «как убедить лида перейти на питон?» :)

minimum viable product

шанс дать заплатить скупому дважды одним словом.

Я Вас понял: проще оставить как есть и ничего не менять. Работает кое-как - не трогай.

И это касается не только Filesystem. Он ещё своё жалкое подобие lexical_cast впихнул и много чего ещё...

Какой ты умный :-)

Сменить тимлида\компанию не предлагать.

Если ты такой умный, предлагаю организовать свою софтверную компанию и стать в ней тимлидом :-) Подтянешь туда буст для итераций по директориям, будет оригинальный lexical_cast использовать, а не подобие, и т.д. :-)

Не понял прикола про питон, так как у нас есть свой драйвер на Си с классами.

Если бы Вы вместо ёрничания сказали что-то полезное, я был бы Вам крайне признателен :)

Нет, апдейтнуть либу до версии без бага.

В котором не нужна производительность? И ты хотел бы запихать в драйвер boost (для онтопика это точно странная и богохульственная мысль, под офтопик я на плюсах дрова не писал)?

драйвер идёт отдельным проектом, с которым у нашей софтины довольно тесная интеграция. В самом драйвере нет и никогда не будет никакого буста.

на Си с классами

А буст это шаблонное исконно плюсовое поделие. Может дело в этом? Или в зависимостях от исключений и рантайма (и то и то правда можно отключить для большинства библиотек).

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

Тогда к исходному вопросу - в чём проблема интегрироваться из питона? При условии, что производительность не важна.

Интеграция чужой библиотеки в проект работодателя != пилить чужую библиотеку за бабки работодателя

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

Это не интеграция, это работу на чужого дядю уже, когда ты мог починить своё.

Если я вносил фикс в сторонюю либу в своё время, то я работал не за деньги работодателя, а за просто так. Когда же я интегрировал чужую либу к нам, то привносил какой-то функционал, правил старый, etc. И результат этой интеграции будет использоваться в нашем проекте, то есть на пользу работодателя.

Фиксил в сторонней либе я за бесплатно, а интегрировал к нам за платно.

А на практике ещё не известно, что дороже притащить в старый проект буст, или переписать его на python/js/java/.net.

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

Если я вносил фикс в сторонюю либу в своё время

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

В данном случае дешевле будет притащить буст.

А тестовой системы как таковой и нет. Созаднием сего я сейчас и занимаюсь. Юнит тестов тоже пока что нет - начнут появляться сразу после того, как я закончу с функциональными.

В данном случае дешевле будет притащить буст

По какому методу оценивал? Функциональных точек или это экспертная оценка?

Если бы Вы вместо ёрничания сказали что-то полезное, я был бы Вам крайне признателен :)

Сказал уже :-) Организовывай свою контору и пиши софт под своим началом :-) Вместо этого ты пытаешься выяснить, как навязать свою волю вышестоящему кадру на месте текущей работы :-) Причём отвечать за принятое решение по использованию много-много-мегабайтной зависимости будешь не ты, а тимлид:-) Сегодня лично тебе нужен буст, завтра лично тебе понадобится какой-нибудь зеро-м-ку, послезавтра лично ты захочешь использовать CUDA :-) Создавай компанию, становись тимлидом, бери на себя ответственность и вперёд :-) А если не можешь, то тогда уважай решения тимлида и делай полезную работу, вместо убеждений в крутости буста и лексикал_каста в нём :-) Лол :-)

По количестве строк кода, которые придётся переписать: если переписывать всё на джава\питон, то придётся переписать в сотни раз больше строк кода, нежелои при интеграции буста.

Я исхожу из мнения, что в данном кейсе стоимость строчек кода эквивалентна.