![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Сложные open-source проекты
Последний год был как-то богат на копание во внутренностях С и С++ проектов. Надо сказать, что опыта с обоими языками у меня очень мало, хотя синтаксис я знаю, представляю как программировать вообще, страуструпа прочел (до K&R не добрался). Так же мало опыта с make-файлами и прочей инфраструктурой. Посему большинство работы с оными проектами сводилось к "заставить это дело сбилдится, подправить пару мест кода, сделать dll, подключить ее к дельфи и забыть".
При этом я серьезно не понимаю одну вещь. Как для этих проектов (большинство из них open-source) появляются новые разработчики?
Гибкость языка и кроссплатформенные заморочки приводят к тому, что каждый проект содержит свой дичайший набор макросов для кроссплатформенной разработки, свои синонимы типов, кто во что горазд. Про структурирование проектов и речи нет - может, автор проекта и знает связи между модулями, но с первого взгляда они выглядят как дикий бардак. Плюс еще массовые include друг друга, да сишный билд в виде компиляция файлов в объектные модули+линковка добавляет веселости.
Т.е. человеку, чтобы въехать в это дело, надо сидеть и заниматься только этим и ничем больше месяцами. Вопрос - откуда сейчас возьмутся люди со знаниями, опытом и свободным временем для этого?
Студенты всяких околокомпьютерных специальностей могли бы - но у них нет опыта, и самое главное - нет цели использовать собственный продукт в промышленных разработках. А без такой цели все переделки будут абстрактными. Если же цель есть - то у них не будет свободного времени. Это же верно для разработчиков всевозможного коммерческого софта. Тупо начальство не поймет, если разработчик вместо реализации непосредственно нужных фич начнет улучшать используемый сервер БД или там займется теорией компиляторов, чтобы сделать в систему пару-тройку DSL.
В коммерческих продуктах понятно - взяли на работу человека, известно что он прошел собеседование, т.е. известно, чего от него ждать, посадили его к разработчику-ментору, тот его вводит в курс дела, дает задачи, итд. Ну и проекты в нормальных конторах разбиты на субмодули, над которыми можно работать независимо.
А в опен-соурсе как? Во-первых, нужно быть совсем невменяемым человеком, чтобы лезть в дебри исходников всякого немелкого софта, нужно иметь знания, опыт и свободное время, нужно убедить главных разработчиков что твои патчи вообще имеют смысл, получить доступ на коммит в репозиторий, итд итп. Да на одно только чтение списков рассылки на предмет того, не сделали ли уже то, что интересует, полдня должно уходить.
При этом я серьезно не понимаю одну вещь. Как для этих проектов (большинство из них open-source) появляются новые разработчики?
Гибкость языка и кроссплатформенные заморочки приводят к тому, что каждый проект содержит свой дичайший набор макросов для кроссплатформенной разработки, свои синонимы типов, кто во что горазд. Про структурирование проектов и речи нет - может, автор проекта и знает связи между модулями, но с первого взгляда они выглядят как дикий бардак. Плюс еще массовые include друг друга, да сишный билд в виде компиляция файлов в объектные модули+линковка добавляет веселости.
Т.е. человеку, чтобы въехать в это дело, надо сидеть и заниматься только этим и ничем больше месяцами. Вопрос - откуда сейчас возьмутся люди со знаниями, опытом и свободным временем для этого?
Студенты всяких околокомпьютерных специальностей могли бы - но у них нет опыта, и самое главное - нет цели использовать собственный продукт в промышленных разработках. А без такой цели все переделки будут абстрактными. Если же цель есть - то у них не будет свободного времени. Это же верно для разработчиков всевозможного коммерческого софта. Тупо начальство не поймет, если разработчик вместо реализации непосредственно нужных фич начнет улучшать используемый сервер БД или там займется теорией компиляторов, чтобы сделать в систему пару-тройку DSL.
В коммерческих продуктах понятно - взяли на работу человека, известно что он прошел собеседование, т.е. известно, чего от него ждать, посадили его к разработчику-ментору, тот его вводит в курс дела, дает задачи, итд. Ну и проекты в нормальных конторах разбиты на субмодули, над которыми можно работать независимо.
А в опен-соурсе как? Во-первых, нужно быть совсем невменяемым человеком, чтобы лезть в дебри исходников всякого немелкого софта, нужно иметь знания, опыт и свободное время, нужно убедить главных разработчиков что твои патчи вообще имеют смысл, получить доступ на коммит в репозиторий, итд итп. Да на одно только чтение списков рассылки на предмет того, не сделали ли уже то, что интересует, полдня должно уходить.
no subject
Из каждого проекта лезут велосипеды делающее одно и то же, но по разному.
Т.е. в одном используется boost::shared_ptr, в другом собственный умный указатель, в третьем по книжкам Александреску написанный. В результате вместо того что бы взять и начать использовать приходиться тоны адаптеров писать.
no subject
Пяток таких проектов и начинаешь понимать где, что и как лежит и/или может сломаться.
no subject
no subject
Когда-то возился с подобным проектом. Ничего такого уж страшного. Основа написана двумя-тремя людьми, остальные, хоть их и много, добавляют по капле и не вносят большого бардака.
no subject
no subject
Это от непрофессионализма. В нормальных проектах код одинаковый и при этом работает на (к примеру) на linux/windows/dsp с разными размерами базовый типов и зачастую с разным endian.
Без всяких уродливых "#ifdef LINUX" посреди кода.
В коммерческих продуктах понятно - взяли на работу человека ... А в опен-соурсе как? Ну, kernel, firefox и прочий apache с OO пишут люди, получающие за это зарплату. В большинстве своём.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Один раз написана библиотека с единым интерфейсом для работы с нитями и объектами синхронизации под разными платформами. В результате программист у себя пишет примерно так:
#include "common_sunc/threads.h"
...
...
{
...
thread_handle=create_thread(&thread_func, bla-bla-bla);
...
}
И всё. Код работает идентично на всех поддерживаемых платформах.
Я что, открыл америку?
no subject
no subject
no subject
no subject
Хотя народ все таки уже начинает новые проекты делать с кроссплатформенностью в уме, и использует готовый код, тогда это не так страшно становится.
no subject
no subject
Нет. Ведь это даже не библиотеки, а скорее wrappers. А то что код становится читаемым, и для переноса на другую платформу требуется дописать тривиальную реализацию и запустить unit tests -- это огромные преимущества.
Вообще, это всё в нормальную архитектуру проекта упирается. А когда, допустим, логика и реализация тонким слоем по всем исходникам размазана -- рано или поздно сложность в управлении всем этим хозяйством превысит любой разумный предел.
no subject
no subject
no subject
.. и с уродскими #ifdef-ами © внутри :)
no subject
no subject
no subject
(Anonymous) 2008-05-04 03:49 pm (UTC)(link)no subject
(Anonymous) 2008-05-04 03:56 pm (UTC)(link)мамба наверное точно студентами пишется, у них явная склонность к пхп:)
no subject
(Anonymous) 2008-05-04 03:57 pm (UTC)(link)no subject
(Anonymous) 2008-05-04 04:02 pm (UTC)(link)no subject
no subject
Я НЕ ВЕРЮ, что народ досконально разбирается в структуре, когда все писано в таком стиле.
Скорее всего просто "тут влепим кнопку" и все.
no subject
"Тут влепим кнопку" - это прерогатива, как ни странно, коммерческого софта, когда нет времени разбираться досконально, дед лайн пришел.
У свободного софта ограничений по времени меньше, поэтому качество выше.
no subject
no subject
Обычно для "абы как" делается архитектура плагинов. ;)
no subject
(Anonymous) 2008-05-05 05:40 am (UTC)(link)no subject
no subject
no subject
no subject
no subject
А что там? Исходники как исходники. Садишься и быстро разбираешься что к чему.
>нужно иметь знания, опыт и свободное время
А на что их не нужно?
>нужно убедить главных разработчиков что твои патчи вообще имеют смысл
Гыгы. Т.е. главные разработчики - полные придурки, что не могут прочесть патч и решить, что он полезен, и их нужно долго умасливать?
>получить доступ на коммит в репозиторий, итд итп.
Не нужно.
>Да на одно только чтение списков рассылки на предмет того, не сделали ли уже то, что интересует, полдня должно уходить.
Стоит поставить нормальный почтовый клиент, который не заставляет тратить на одно письмо по десять минут.
no subject
Абсолютно не то имелось в виду. Ребе ничего не стоит подключиться из консоли к почтовому серверу, пролистать письма быстрее, нежели это сделает некий "нормальный" почтовый клиент. Но речь ведь не об этом.
Представляете, что такое ежедневная рассылка с опенсоурс-ресурсов для разработчиков? Это куча информации по новейшим апдейтам десятков линуксотипных дистрибутивов, тысячам либ. Информации реально много, потому и долго ее осиливать..
Re: Reply to your comment...