t.t писал(а): ↑28.06.2012 11:16Зависит, хотя и косвенно, в том числе и архитектура. Стандарты, документирование и code review это всё отлично. Но кроме них есть ещё один совсем не маловажный фактор, в большинстве случаев весьма влияющий на качество кода (да и архитектуры зачастую тоже): насколько этот код публичен. В штатной ситуации этот фактор, возможно, и не столь существенен; но коммерческие проекты значительную часть времени пребывают в нештатных ситуациях, потому что дедлайны, текучка кадров, да и непредсказуемые требования, всплывающие вдруг в середине проекта. Да, бывают исключения из этого правила, и среди коммерческих закрытых проектов иногда попадаются вещи с крайне стройной архитектурой и правильным кодом; но это именно исключения.
открытый проект, открытому проекту рознь. классическая схема: Вася Пупкин пишет для себя маленькую уютнинькую софтинку и выкладывает ее в сеть. все пока хорошо. кто-то начинает пользоваться - находят баги, появляются фич реквесты, баги фиксятся, идет наполнение фичами, появляются сторонние коммитеры. где-то в этот момент, возникает проблема: нужно удерживать стройность и/или гибкость архитектуры для того чтобы новые фичи и багфиксы не превратили код в страшное месиво. кто-то с этим справляет, кто-то нет. если - нет, проект, через какое-то время переходит в состояние когда все вроде бы работает, новые фичи не особо добавляются, да и добавлять их уже проблематично, разве что баги очередной заплаткой поправить. а через какое-то время начинаются форки и работа над новой™ версией.
открытость кода не обещает хорошей, да еще самодкументируемой архитектуры, и/или хорошего качества кода, как и закрытость. все по тем же правилам что и в закрытом коде: может повезет, и действительно все будет хорошо, красиво и чисто, если не повезет, а софт популярный(или в случае закрытого кода - приносит много денег): можно использовать брутфорс - 100500 обезьянок в конце-концов приведут кодовую базу в поддерживаемое состояние, или просто сделают что-то новое. Правила те же самые. Разница в том как привлекаются ресурсы. При этом схема абсолютно та же: "выстрелит" - у закрытого проекта будет больше денег, возможность нанять больше людей, у открытого проекта напрямую становится больше людей для разработки, "не выстрелит" - загнется и то, и другое. преимущества у открытой модели, конечно есть, но они за пределами качества кода.
Даже такой вот простой пример: помнишь в "Искусстве программирования под UNIX" ESR рассуждает о организации кода, типа размер одного файла не стоит делать больше 800 строк, а функция должна полностью помещаться на один экран, товарищ Мартин идет даже дальше, одна функция делает только одну вещь(например вываливание ексепшина, или if, или цикл какой-нить -это та самая одна вещь, а, например, тело цикла - это уже другая вещь и другая функция), или, тоже правило, кажется от Торвальдса: не больше трех уровней вложенности. Хорошие правила? - Да, хорошие. Как там у отрытого кода с этим? - да так же как и в среднем по больнице.
