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

[metaclass]

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

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

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

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

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

Comments

[kkirsanov.livejournal.com]

А самое весёлое начинается когда несколько опенсорс-прожектов приходиться использовать в 3-м проекте.

Из каждого проекта лезут велосипеды делающее одно и то же, но по разному.
Т.е. в одном используется boost::shared_ptr, в другом собственный умный указатель, в третьем по книжкам Александреску написанный. В результате вместо того что бы взять и начать использовать приходиться тоны адаптеров писать.

[metaclass.livejournal.com]

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

[thesz.livejournal.com]

Дело привычки.

Пяток таких проектов и начинаешь понимать где, что и как лежит и/или может сломаться.

[vp.livejournal.com]

Дык речь о трудоемкости.
Я НЕ ВЕРЮ, что народ досконально разбирается в структуре, когда все писано в таком стиле.
Скорее всего просто "тут влепим кнопку" и все.

[thesz.livejournal.com]

Э-э, нет.

"Тут влепим кнопку" - это прерогатива, как ни странно, коммерческого софта, когда нет времени разбираться досконально, дед лайн пришел.

У свободного софта ограничений по времени меньше, поэтому качество выше.

[metaclass.livejournal.com]

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

[thesz.livejournal.com]

Главы проектов не пропустят. ;)

Обычно для "абы как" делается архитектура плагинов. ;)

[inhate.livejournal.com]

Во главе нормального живого проекта стоят адекватные люди. Им шлются патчи. "Мальчег с улицы" не получает доступа к основному репозитарию. Особо обиженные иногда форкакют проекты. Иногда это хорошо. Т.е. подход: "ну спасибо что хоть както это реализовали" не катит. Во главе не слишком коммерциализированого опенсорца зачастую стоят маньяки-перфекционисты типа Тео.

[jek-hor.livejournal.com]

Ребе, вы таки не поверите, но очень большому количеству разработчиков в таких проектах ещё и деньги за это платят.

[ex-biespart.livejournal.com]

+1

[metaclass.livejournal.com]

Брр, может у них еще и проект-менеджеры и начальство с кнутом и пряником есть, которое требует "продукт нужен вчера"? И корпоративный дух, насаждаемый HR-отделами? :)

[jek-hor.livejournal.com]

Вполне может быть. Ведь многие подобные проекты разрабатываются по чьему-то заказу. Например, ЕМНИП, в первой тройке коммитеров в ядро Linux находятся IBM и RedHat.

[metaclass.livejournal.com]

Ага, про коммитеров в ядро я читал, но мысль о том, что на работу берут человека садят и говорят - с "сегодняшнего дня ты работаешь над ядром линукса" меня чем-то пугает :)

[(Anonymous)]

А чего страшного, страшнее было бы "с сегодняшнего дня ты работаешь над ядром виндовса"

[inhate.livejournal.com]

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

[psilogic.livejournal.com]

Иногда интересно сбацать что-то свое - не за бабло, а именно из интереса. А потом другие начинают использовать, ну и пошло...

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

[metaclass.livejournal.com]

Когда начинаешь с нуля, тут понятно. А интересно, как народ въезжает в немелкий проект с его середины, и откуда у этого народа на это время.

[psilogic.livejournal.com]

Ну вот про себя могу сказать. Откуда время - так не круглые же сутки работаешь. 8 часов сон, 8 часов работа, остальное - для себя. Вот из этого "для себя" и берется время. Как въезжает - а так же, как въезжаешь в модуль, оставшийся от уволившегося коллеги на обычной работе, никаких принципиальных отличий. Разве что знаешь, что если че сломаешь, ругать некому :)

[metaclass.livejournal.com]

А, у людей еще время для себя бывает? :)

[psilogic.livejournal.com]

Ну рабство вроде как в 1917-м отменили... :)

[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'ы ради объективности :)

[noop.livejournal.com]

Хмм... Вообще-то не секрет, что очень очень многие опен-сорс проекты пишутся студентами. У них как раз есть время висеть на комьюнити итд. Можно потом писать, что "учавствовал в разработке ядра Linux", например. Ожидать "высшего пилотажа" в программировании от таких товарищей не стоит. Более-менее серьезные вещи пишутся либо за зарплату от спонсоров, либо дядьками-энтузиастами, которые на работе получают достаточно, а работают нечасто.

[(Anonymous)]

>не секрет, что очень очень многие опен-сорс проекты пишутся студентами

мамба наверное точно студентами пишется, у них явная склонность к пхп:)

[(Anonymous)]

Пример, oracle-64 bit например десятка. Таскает за собой шкаф 32х битных скелетов, посему требует сертифицированную ось(пути к библиотекам, свой ld_preload и прочие бубны). С другой стороны свободные постгрес или мускуль собираются даже на самом страшном железе и осях, всё что открыто, довольно быстро(более или менее) переписывается и унифицируется(читайте чточто про мало опыта с make-файлами и прочей инфраструктурой где у open всё в порядке и собирается на автотулзах на всяком дерьмище). Иначе это как я уже выразился шкафы со скелетами старой архитектуры, до которых никому нет дела.

[metaclass.livejournal.com]

Вот автотулсы и пугают. Если makefile я понимаю примерно как устроен, то как работает всякие конфигуре и прочее - не представлю, а внутренности файла нечитабельны вообще.

[(Anonymous)]

Это просто набор макросов, некоторые с параметрами, оттуда всё и генерится, посему читать это обычно ненадо:) http://sources.redhat.com/autobook/ очень хорошая книжка, с примерами.

[dottedmag.livejournal.com]

>Во-первых, нужно быть совсем невменяемым человеком, чтобы лезть в дебри исходников всякого немелкого софта

А что там? Исходники как исходники. Садишься и быстро разбираешься что к чему.

>нужно иметь знания, опыт и свободное время

А на что их не нужно?

>нужно убедить главных разработчиков что твои патчи вообще имеют смысл

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

>получить доступ на коммит в репозиторий, итд итп.

Не нужно.

>Да на одно только чтение списков рассылки на предмет того, не сделали ли уже то, что интересует, полдня должно уходить.

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

[archangel-rhn.livejournal.com]

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

Абсолютно не то имелось в виду. Ребе ничего не стоит подключиться из консоли к почтовому серверу, пролистать письма быстрее, нежели это сделает некий "нормальный" почтовый клиент. Но речь ведь не об этом.
Представляете, что такое ежедневная рассылка с опенсоурс-ресурсов для разработчиков? Это куча информации по новейшим апдейтам десятков линуксотипных дистрибутивов, тысячам либ. Информации реально много, потому и долго ее осиливать..

Re: Reply to your comment...

[dottedmag.livejournal.com]

Вас обманули, таких рассылок не существует. Ни один человек в нормальном состоянии ума не будет читать всё.