3rd Party либы
Есть два диаметрально противоположных подхода организации работы с библиотеками на проекте: пишем все свое и берем все чужое. Мне довелось поработать в обеих ситуациях. Хочу поделиться плюсами и минусами этих подходов, а также идеями как облегчить себе жизнь.
Все Свое
Как правило это ситуация с микроконтроллерами, где вы не можете просто взять и использовать код не доработав его напильником под свое железо, или что-то очень-очень секьюрное, где паранойя о том, что везде могут быть чьи-то “закладки” не дает покоя заказчику проекта, или многоплатформенное, и вам надо иметь суперуниверсальный код.
Если вы пишете все свое, то вы сразу же отбрасываете опыт разработчика-автора либы: он уже сталкивался с вашими проблемами, он тестировал, он находил проблемы производительности, он чинил баги, которые ему зарепортили другие пользователи, он писал автотесты.
Разработка собственных либ как правило идет параллельно с разработкой вашего проекта. И вы попадаете в ситуацию: “пока враг рисует карты, мы меняем ландшафты”. Требуется версионирование собственных либ, чтобы ваш код был в синхронизации с кодом библиотек.
Если либ больше чем одна, вы очень скоро упретесь в то, что версии не стыкуются. Вам нужна либа А версии 1.2, но она не стыкуется с либой Б версии 2.3, а стыкуется только с либой Б версии 2.5, а ваш код не совместим с версией либы Б выше 2.4. Апгрейды версий придется чщательно планировать и изучать зависимости.
Откат к предыдущим версиям - ровно такая же боль. Если вы вдруг находите критический баг, который починить невозможно, и принимаете решение откатиться к предыдущему набору версий либ - вы получаете проблему того, что новый код уже опирается на какие-то новые фичи, которых не было в предыдущем наборе. Выход - врапперы над интерфейсом либ, и максимально изолировать влияние интерфейса либы на бизнеслогику кода в проекте.
Из-за параллельной разработки проекта и либ, все добро приходится собирать с исходников, от самого низа. Поэтому время сборки значительно возрастает по мере развития проекта.
Но, конечно же такой подход дает один неоспоримый плюс: вы можете найти и починить ЛЮБОЙ баг, ЛЮБЫМ способом.
Вы познаёте все, даже малейшие проблемы на своем личном опыте. И можете объяснить поведение программы.
Все чужое
Либа может быть хорошая, но ее лицензия не позволит вам использовать ее у себя.
Вы берете готовые библиотеки, и если у разработчика были прямые руки - все начинает работать сразу. Но даже если у разработчика были самые прямые руки, все равно есть какие-то особенности, про которые вы узнаете в лучшем случае на этапе тестирования, в худшем - после релиза, от пользователя.
Баги можно зарепортить, но не факт что автор согласится что это баг, или не выставит багу самый низкий приоритет отложив когда-то на потом. Или скажет, что это очень специфический случай, ради которого никто ничего переделывать не будет. То есть придется тулить костыли.
Иногда что-то будет крэшиться, и вы ничего не сможете с этим сделать. Поэтому вполне нормальным вариантом будет вынесение работы с такой либой в отдельный процесс, с которым ваше приложение общается по LPC/RPC.
Вы не управляете производительностью и потреблением ресурсов. Т.е. при выборе библиотеки нужно тщательно смотреть как ведет себя либа.
Иногда либа будет настолько сырая, что проще будет ее переписать самому, чем использовать в том виде в каком она есть.
Либа может идти в бинарях и требовать тягать за собой рантайм от какой-то лохматой версии компилятора.
Либа может быть собрана так, что будет конфликтовать с другими вашими библиотеками. Привет-привет ffmpeg например. И вам придется пересобирать либу через чудопроцедуры описанные разработчиком.
Отладочная инфа зачастую отсутствует, поэтому вы не знаете: или это ваш код так неправильно либу использует, или очередной баг в коде либы. Выход: если есть исходный код - лучше собирать либу самому, под свой проект.
Пересборка чужих либ под свои нужды - отдельный аттракцион, особенно если автор в новой версии резко изменил процедуру сборки, или добавил новые зависимости. Есть вариант облегчающий эти вещи - использовать менеджеры пакетов nuget, conan и т. п.
Либа может не иметь релизов: автор распиздяй - херачит все в master. И вы никогда не знаете - удачно вы схватили исходники, или автор вчера какую-то хрень залил.
Может банально не быть либы собранной под x64, а исходников нет. Или либа не была готова к кроссплатформенности и не собирается под вашу платформу без дополнительных изменений.
Есть патчи, которые автор либы не принял, а вам без них нельзя. При апгрейде либы вы должны их каждый раз накатывать, и тратить время на то чтобы понять, а где ж теперь тот код, который я патчил в прошлом году.
DLL Hell as is, здесь та же проблема что и при сборке всего своего - вам придется собирать набор библиотек, которые не конфликтуют между собой. Но тут за счет того, что библиотеки меняются редко, мучиться приходится не так часто.
Апгрейд версий тоже нужно тщательно планировать. Врапперы также спасают от резких изменений интерфейса.
Сборка однозначно быстрее, за счет того, что все уже в бинарях и достаточно скинуть файлы в каталог билда.














