Сложные open-source проекты

[metaclass]

Последний год был как-то богат на копание во внутренностях С и С++ проектов. Надо сказать, что опыта с обоими языками у меня очень мало, хотя синтаксис я знаю, представляю как программировать вообще, страуструпа прочел (до K&R не добрался). Так же мало опыта с make-файлами и прочей инфраструктурой. Посему большинство работы с оными проектами сводилось к "заставить это дело сбилдится, подправить пару мест кода, сделать dll, подключить ее к дельфи и забыть".

При этом я серьезно не понимаю одну вещь. Как для этих проектов (большинство из них open-source) появляются новые разработчики?

Гибкость языка и кроссплатформенные заморочки приводят к тому, что каждый проект содержит свой дичайший набор макросов для кроссплатформенной разработки, свои синонимы типов, кто во что горазд. Про структурирование проектов и речи нет - может, автор проекта и знает связи между модулями, но с первого взгляда они выглядят как дикий бардак. Плюс еще массовые include друг друга, да сишный билд в виде компиляция файлов в объектные модули+линковка добавляет веселости.

Т.е. человеку, чтобы въехать в это дело, надо сидеть и заниматься только этим и ничем больше месяцами. Вопрос - откуда сейчас возьмутся люди со знаниями, опытом и свободным временем для этого?
Студенты всяких околокомпьютерных специальностей могли бы - но у них нет опыта, и самое главное - нет цели использовать собственный продукт в промышленных разработках. А без такой цели все переделки будут абстрактными. Если же цель есть - то у них не будет свободного времени. Это же верно для разработчиков всевозможного коммерческого софта. Тупо начальство не поймет, если разработчик вместо реализации непосредственно нужных фич начнет улучшать используемый сервер БД или там займется теорией компиляторов, чтобы сделать в систему пару-тройку DSL.

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

Comments

[qehgt.livejournal.com]

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

Это от непрофессионализма. В нормальных проектах код одинаковый и при этом работает на (к примеру) на linux/windows/dsp с разными размерами базовый типов и зачастую с разным endian.

Без всяких уродливых "#ifdef LINUX" посреди кода.

В коммерческих продуктах понятно - взяли на работу человека ... А в опен-соурсе как? Ну, kernel, firefox и прочий apache с OO пишут люди, получающие за это зарплату. В большинстве своём.

[psilogic.livejournal.com]

Ну-ка расскажите мне, как в "нормальных проектах" реализованы треды без всяких уродливых #ifdef LINUX... :)

[inhate.livejournal.com]

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

[psilogic.livejournal.com]

Голословненько :)

[inhate.livejournal.com]

заползи на forum.linux.by и попробуй спросить - там есть минимум два человека которые именно этим и занимаются на работе...

[qehgt.livejournal.com]

А что не понятно-то?

Один раз написана библиотека с единым интерфейсом для работы с нитями и объектами синхронизации под разными платформами. В результате программист у себя пишет примерно так:

#include "common_sunc/threads.h"
...
...
{
...
thread_handle=create_thread(&thread_func, bla-bla-bla);
...
}

И всё. Код работает идентично на всех поддерживаемых платформах.

Я что, открыл америку?

[noop.livejournal.com]

Зачастую сложнее писать и отлаживать библиотеку такого рода, нежели вставить набор #ifdef. Просто потому, что обычно проект вырастает в кроссплатформенный из реализации для одной отдельно взятой платформы, следовательно код не переписывается, а лишь расширяется. Переход с уже отлаженного, хоть и грязного кода на новую реализацию через удобную библиотечку выглядит вроде как заманчивым, но требует глобальной переделки скажем, пары-тройки модулей. И если прежний уже отлажен и работает - то кому надо снова ловить старые баги? Каждый программер ведь считает, что после него уже доделывать нечего :)

[qehgt.livejournal.com]

>Зачастую сложнее писать и отлаживать библиотеку такого рода, нежели вставить набор #ifdef.
Нет. Ведь это даже не библиотеки, а скорее wrappers. А то что код становится читаемым, и для переноса на другую платформу требуется дописать тривиальную реализацию и запустить unit tests -- это огромные преимущества.

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

[noop.livejournal.com]

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

[(Anonymous)]

#ifdef это скорее то, что решается во время компиляции. Остальное от лукавого.

[metaclass.livejournal.com]

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

[psilogic.livejournal.com]

совсем от #ifdef-ов не спрятаться, хотя можно их замести под ковер - в какой-нибудь отдельно стоящий модуль, DLL... Вот у меня только что native.obj в проекте скомпилился ;)

[psilogic.livejournal.com]

[ Один раз написана библиотека с единым интерфейсом ]

.. и с уродскими #ifdef-ами © внутри :)

[inhate.livejournal.com]

кажется есть реальный открытый пример - apr - можно пересчитать #ifdef'ы ради объективности :)