The Architecture of Open Source Applications

Ты английского не знаешь совсем-совсем?

Владею в совершенстве =)

Тогда что тебе не ясно? Ты не знаешь что это за организация такая «Amnesty International» или тебя интересует почему Amazon нередаёт им 4 бакса с каждой покупки этой книги?

Ага, вижу твои исправления. Но всё равно не понимаю суть вопроса...

Чем крупнее торговая площадка тем больше она берет за свои услуги?

Меня больше заинтересовало, чем же таким архитектура опенсурсных приложений отличается от всех остальных, что автор так усердно напирает на этот аспект в названии?

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

Это в теории, видимо. На практике обычно как раз наоборот. Вот я и удивился. :)

ну дак книжка про теорию скорей всего

куча людей пишет как хочет, как им нравится и радует душу, хакает по хардкору

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

куча людей пишет как хочет, как им нравится и радует душу, хакает по хардкору

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

И тут кровавый ынтырпрайз предлагает жрать что дали :}

если попробовать использовать правила галстуков в опенсорце - его просто перестанут писать, его не будет. Поэтому у опенсорца свои методы к построению архитектуры.

(* в том смысле, что не каждая компания - обязательно кровавый ынтерпрайз в смысле IBM и Газпром. Может быть маленький аутсорц по написанию биллингов для домашнего говнопровайдера интернета, но правила они все равно используют анальные)

Например, у галстуков обычно один файл (или модуль) правит много людей, поэтому код четко структурирован на уровне самого файла (модуля), и используются языки с акцентом на это, типа Java. А в опенсорце люди кодят как хотят, поэтому зачастую нереально понять что находится в очередном файле, и структура выходит на уровень интерфейса этого файла в целом, типа «я экспортирую вот такие функции с такими параметрами, а больше вам знать ничего не надо». И соответственно можно применять соответствующие языки и технологии - например, написать внутри файла лютый монолитный однострочник на Clojure - несколько человек никак не могут редактировать однострочник одновременно, но мы уже условились что этого и так никто не делает.

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

Если создателей несколько, и каждый держит свой форк со своим мастером, по набору фич отличающийся от других, мы должны сделать кучу вещей - например, для общих фич нужен кворум, а кастомные фичи должны быть оформлены как feature commits, где каждый коммит называется в формате «добавить фичу $featurename» и относительно независим от окружающего кода. В противоположность кровавому ынтерпрайзу, где коммиты обычно представляют собой просто описание «что было сделано», не изолированы друг от друга никак, и накатить коммит из одной ветки в другую простым образом невозможно (каждый коммит сильносвязан с предыдущими, никаких feature branches нету, итп). А для создания изолированных feature commits нужно делать специальную архитектуру, например основанную на изолированных плагинах с общими extension points (которые как раз имплементятся через кворум)

Это же регулирует напримегр, размер модуля. Если там write-once code (например, там Clojure, код очень readable но неавтору непонятно как его изменить), то проще переписать с нуля, чем исправить. Чтобы переписывать надо было как можно меньше, логично иметь очень маленькиие файлы/модули, например зависимость которая всего лишь добивает нули к строке слева :)

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

То есть в целом, у опенсорца как раз есть совершенно характерные свои архитектуры, которые надо знать и юзать.

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

Ну, таким способом, который ты описал, паровоз не собрать. Если каждый будет тащить колеса разного диаметра и шатуны разной длины, то все эта хрень взорвется еще когда ты котел прогревать будешь. К чему это я: проекты побольше требуют управления. А управлять стаей эгоманов сложно. Должен быть человек, который говорит «плевать, что тебе тут хочется ядро писать, сегодня ты будешь делать эту вот кнопочку. И попробуй только сделать на „пошли в жопу“.» Поэтому самые успешные опенсурсные проекты это мелкие утилиты и либы, которые пишет пара человек. Самые убогие это всякие монструозные линуксовые DE или иксы. Кривые и забагованные.

Все Ъ? По ссылке же даже статьи открываются. В книге написано как реализована архитектура некоторых open source проектов, а не теория о построении архитектуры.

в опенсорце люди кодят как хотят

В итоге возникают совершенно феерические баги, которые приходится ловить неделями. Один тут накоммитил, другой там... И все вроде как работает... 364.999 дня в году. Оказывается, что один воспользовался левой фичей ядра вместо «правой» (мы же никогда не ломаем юзерспейс, да!), другой не учел существование «левой» фичи, и не счел необходимым добавить еще одну проверку в код (лишнюю, по мнению любого здорового человека), ну а третий просто наколбасил хрень. Из-за этих «мелочей» у одного-единственного клиента приложение раз в пару дней сходит с ума. В понедельник я приду на работу, приготовлю патчи для всех этих чудес, разбросанных по нескольким опенсорс-проектам. И эти люди будут с надменностью посылать меня на три русские буквы, потому что им обязательно что-нибудь очень-очень не понравится, если я только пошлю им свои патчи. А спорить с ними неделями возможности не имею, другие дела стоят.

Вот она, беда опенсорса - отсутствие архитектуры в целом как таковой, помноженный на диктат ярких личностей. Хороша затея, да масштабируется плохо.

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

Ну фиг знает, если посмотреть стандарты (или они рекомендации?) от GNU, то с ума сойти можно.

Меня больше заинтересовало, чем же таким архитектура опенсурсных приложений отличается от всех остальных, что автор так усердно напирает на этот аспект в названии?

Эта книжка про архитектуру разных штук от авторов этих штук. По главе на приложение (например глава про архитектуру sendmail). Хз про что оп ниже втирает.

Книжки, кстати, хорошие.

то есть ты сначала говоришь что не знаешь что это и о чем, а потом сравниваешь?

Перечитай еще раз. И еще раз. Пока не отпустит.

можно сказать так, а можно наоборот, да

Ты привел примеры из вообще любой разработки + набросил парочку взаимоисключающих параграфов.

куча людей пишет как хочет, как им нравится и радует душу, хакает по хардкору

В каждом проекте есть свои гайдлайны и ограничения. Так что тот же самый интерпрайз, только денег не платят.