....продожение. Начало.
Как нетрудно было догадаться из предыдущего поста, пожалуй единственным подходящим решением проблем, возникающих при разработке портабельных систем, является абстракция и обобщенное программирование - сильные стороны C++. Описание техник можно поискать в серии книг C++ In Depth, книгах Мейерса и прочих гуру, я же приведу некоторые мысли относительно моментов, на которые следует обратить внимание, если вы используете для разработки сторонние библиотеки/компоненты.
Наличие довольно большого колличества библиотек для решения самых разнообразных задач, компилируемых под несколько основных платформ, существенно облегчает работу программиста. Однако все же существует несколько вопросов, которые возникают при использовании сторонней библиотеки при разработке продукта, и практически все они относятся к качеству кода...
Первым моментом, на который стоит обратить внимание, пожалуй, будет стабильность кодовой базы. Согласитесь, не совсем приятно будет, когда при выпуске новой версии программного продукта вы решили заодно проапгрейдить библиотеки и обнаружили, что разработчики одной из них заодно с пофикшеными багами поменяли API и билд сваливается.
Вторым - то насколько этот компонент подвергается тестированию, что повышает вероятность отлова багов до выпуска релизов, а вместе с этим и вероятность обойтись без лишней головной боли.
Третьим - наличие поддержки и ее вменяемости. Да я понимаю, что у вас комманда "звезд", которые умеют читать код по диагонали и нюхом чуять баги. Но они приходят и уходят и, вполне вероятно, что поддержкой все же придется воспользоваться.
Четвертым - maintainable ли код? Насколько легко будет споровождать его (если он открыт) в случае, если разработчики "забьют" на компонент? Насколько легко сопровождать код, написанный с использованием этой библиотеки? (так как в большинстве случаев библиотека и язык, на котором она написана, диктуют стиль программирования). Насколько легко вы воспринимаете идиомы, используемые при написании такого кода?
Пятым фактором является портируемость - то, что вынесено в заголовок данного поста, поэтому по умолчанию подразумевается портируемость библиотеки. Однако тут нужно учесть ряд моментов, как-то: есть ли зависимости от третьих библиотек? насколько все сказанное выше относится к этим библиотекам? Понятно, что в ряде случаев такую оценку провести попросту невозможно, поэтому зачастую просто полагаются на разработчиков и если они говорят, что "portable", - значит "portable" и все тут.
Шестым фактором является наличие возможности локализации. Можно ли использовать библиотеку/компонент в другой временной/географической зоне? нужны ли изменения?
Вот такие вот пироги. Все сказанное, конечно, так - абстрактные мысли, не подкрепленные личным опытом, поэтому хотелось бы услышать мнения людей, которым действительно приходилось сталкиваться с подобными проблемами, может чего упустил? написал неправильно? Из тех кого я читаю, на ум приходит пожалуй только Alex Ott.
Велкам в камменты, как говориться ;-).
Как нетрудно было догадаться из предыдущего поста, пожалуй единственным подходящим решением проблем, возникающих при разработке портабельных систем, является абстракция и обобщенное программирование - сильные стороны C++. Описание техник можно поискать в серии книг C++ In Depth, книгах Мейерса и прочих гуру, я же приведу некоторые мысли относительно моментов, на которые следует обратить внимание, если вы используете для разработки сторонние библиотеки/компоненты.
Наличие довольно большого колличества библиотек для решения самых разнообразных задач, компилируемых под несколько основных платформ, существенно облегчает работу программиста. Однако все же существует несколько вопросов, которые возникают при использовании сторонней библиотеки при разработке продукта, и практически все они относятся к качеству кода...
Первым моментом, на который стоит обратить внимание, пожалуй, будет стабильность кодовой базы. Согласитесь, не совсем приятно будет, когда при выпуске новой версии программного продукта вы решили заодно проапгрейдить библиотеки и обнаружили, что разработчики одной из них заодно с пофикшеными багами поменяли API и билд сваливается.
Вторым - то насколько этот компонент подвергается тестированию, что повышает вероятность отлова багов до выпуска релизов, а вместе с этим и вероятность обойтись без лишней головной боли.
Третьим - наличие поддержки и ее вменяемости. Да я понимаю, что у вас комманда "звезд", которые умеют читать код по диагонали и нюхом чуять баги. Но они приходят и уходят и, вполне вероятно, что поддержкой все же придется воспользоваться.
Четвертым - maintainable ли код? Насколько легко будет споровождать его (если он открыт) в случае, если разработчики "забьют" на компонент? Насколько легко сопровождать код, написанный с использованием этой библиотеки? (так как в большинстве случаев библиотека и язык, на котором она написана, диктуют стиль программирования). Насколько легко вы воспринимаете идиомы, используемые при написании такого кода?
Пятым фактором является портируемость - то, что вынесено в заголовок данного поста, поэтому по умолчанию подразумевается портируемость библиотеки. Однако тут нужно учесть ряд моментов, как-то: есть ли зависимости от третьих библиотек? насколько все сказанное выше относится к этим библиотекам? Понятно, что в ряде случаев такую оценку провести попросту невозможно, поэтому зачастую просто полагаются на разработчиков и если они говорят, что "portable", - значит "portable" и все тут.
Шестым фактором является наличие возможности локализации. Можно ли использовать библиотеку/компонент в другой временной/географической зоне? нужны ли изменения?
Вот такие вот пироги. Все сказанное, конечно, так - абстрактные мысли, не подкрепленные личным опытом, поэтому хотелось бы услышать мнения людей, которым действительно приходилось сталкиваться с подобными проблемами, может чего упустил? написал неправильно? Из тех кого я читаю, на ум приходит пожалуй только Alex Ott.
Велкам в камменты, как говориться ;-).