| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Обсуждение работы > Разделение труда в крупных программных проектах |
| Автор: KaraKum 20.3.2008, 23:37 |
| Доброе время суток. Хотел бы узнать как организовывается коллективная работа большого количества разроботчиков (большее 1) программного обеспечения (в т.ч. и игр, ОС и так далее)? Вобщем реальные менеджеры и те у кого просто есть идеи по этому поводу - делитесь. Буду рад вашим ответам! |
| Автор: Samotnik 21.3.2008, 18:49 |
| KaraKum, Оч просто : Есть Project Manager который Бог, царь и папа на проекте. Есть группки по 12 (примерно) челов, которые разрабатывают проект. Там : Программер лидер, девелоперы и тестеры. В общих чертах, это все ! Если что по конкрентнее, спрашивайте ! |
| Автор: KaraKum 21.3.2008, 20:33 |
| Вот как раз конкретность меня и удивляет! Как можно распределить труд между многими программерами, а потом соединить их результаты в один, если, конечно, они не дизайнеры, который делают всякие 3D-модели, картинки или ролики? Я сам занимаюсь программированием игр, совсем недавно и в-одиночку, и нет почти ни одного элемента, который можно написать без понимания всего механизма игры. - Как я это понимаю. И кажется, что на обговаривание общих моментов они тратят значительно больше времени, чем на само программирование. |
| Автор: Daevaorn 21.3.2008, 23:21 | ||
Существует эта проектирования, на котором разрабатывается вся система в некоторой детализации. Так что все исполнители осведомлены о системе в целом, но лучше всего знаю только свою часть. |
| Автор: KaraKum 22.3.2008, 00:08 | ||||
Но остаётся не понятным как организовывается такой коллективный труд именно с программной точки зрения? Даются указания по созданию конкретных классов или функций, которые должны выполнять определённые операции? - примерно так? И если можно, пожалуйста, как можно конкретнее. |
| Автор: Samotnik 22.3.2008, 00:47 |
| KaraKum, Вобщем : Есть задача : написать программу икс (Х) Ты собираеш себе команду, которые пишут на разных языках (Си шарп, донет, джава..) а потом ты с помощью мавена всю эту крастоу билдеш !! Что не понятно ???? |
| Автор: KaraKum 22.3.2008, 09:28 | ||
Не понятно именно разделение обязанностей. Допустим такой пример: нужно сделать игровой движок и было решено разделить задачи проектирования циклов игры и организации поддержки лан-игры, соответственно, между двумя программистами. Так вот, как можно создать поддержку лан-игры не зная досканально реализацию и сам код циклов игры? По-моеуму второму придётся его знать настолько досконально, что, наверное, потратится столько времени на его осмысление, почти равноценное его же написанию. И ещё важным вопросом является принятие организатором решений о сложности некоторых моментов и соотвествующее их распределение между программистами, чтобы каждому - одинакого. Я в этом деле новичок и хочу узнать как можно больше, поэтому не судите строго  . |
| Автор: skyboy 23.3.2008, 00:10 | ||||
приведу простой пример: когда пишешь программу, скажем, под Windows, ты не только без знания структуры системы можешь обойтись, но и даже без интерфейса составляющих систему библиотек: windows API. Ты берешь какую-то абстрактную библиотеку, в которой есть функция "нарисовать окно" и "нарисовать кнопку". хорошо спроектированная система должна иметь такую структуру, чтоб принимать минимально необходимый набор данных и выдавать однозначный результат. в таком случае её просто описать и просто использовать, не зная ничего о её внутреннем устройстве. возможно, в некоторых случаях, несколько человек могут работать над объемной, но единственной задачей(конкретная подсистема рендеринга или правила поведения ИИ), и в таком случае будут знать код "друг друга"(на самом деле это будет "общий код"), но при правильном руководстве ни к каким проблемам это привести не должно. Даже методология разработки есть такая: "экстремальное программирование". насколько мне известно(в теории, на практике применять не доводилось), одним из китов методологии является "разработка в паре".
это сложная система и её вполне можно разбить на подсистемы. вообще, главное условие правильного проектирования(когда получается наиболее гибкая и устойчивая система) - сильносвязанные модули со слабыми связями друг с другом. т.е. если передача от одной подсистемы к другой - то немного и только необходимое. кстати, именно поэтому не рекомендуется использовать глобальные переменные(в любом проекте): они создают "лишние"(ещё и неявные) связи и уменьшают устойчивость системы. |
| Автор: zeehond 23.3.2008, 21:30 |
| если чисто технически - обычно выглядит таким образом система разбивается на подсистемы, которые друг с другом связаны слабее, чем компоненты внутри системы по каждой подсистеме команда ведущих специалистов (типа оч. крутых 1-3 шт.) разрабатывает некий скелет, где функциональность построена вертикально, т.е. оно уже дышит, но почти все фичи реализованы затычками потом специалистам уже менее крутым даётся задача в рамках уже данного скелета добавлять фичи типа "вот тебе API, вот тебе пример как делать компонент - сделай ещё 20 штук таких же, по функциональной спецификации" ведущие при этом пасут, что там некрутые себе делают, и по необходимости ими подруливают по необходимости вносят изменения в "скелет" ну и если там какие-то возникают стратегические геморрои (а их возникает обычно немеряно), то ведущие специалисты соответственно между собой в узком кругу решают, каким образом это лучше или эскалируют бизнес-людям  вот как-то так |
| Автор: KaraKum 25.3.2008, 10:14 |
| Вот именно про написание общего для нескольких программистов кода я и хотел узнать. Но ведь, на само написание небольшого кода уходит едва ли несколько минут если уже понимаешь его, а вот на проектировку могут уйти дни, недели, а то и месяцы, а, как сказано выше, определённый круг программистов, работающих над общей задачей понимают этот общий код. Всё-таки не избежать издержек от масштабности труда при коллективных проектах, то есть, наверное, получается так, что чем больше персонал, работающий над одним проектом, тем меньше пользы от каждого. Я правильно понимаю? |
| Автор: Shurr 25.3.2008, 17:24 |
| KaraKum Если рассматривать с технической точки зрения, то общий код никогда не пишется одновременно (за исключением особых практик, таких как вышеупомянутое парное программирование в XP). Даже если несколько человек пишут близкие по фукциональности вещи - все равно происходит разделение: два человека в один момент времени не изменяют одно и то же место в коде. В дальнейшем все это сводится в системе контроля версий. Т.е. общий код может разрабатываться несколькими людьми, но в разные моменты времени. С точки зрения понимания всего кода для написания своей части - вовсе не обязательно, что все должны знать весь код. Для этого есть общая архитектура, интерфейсы взаимодействия отдельных модулей. Что находится за интерфейсом, которым ты пользуешься - знать не обязательно. С точки же зрения управления всей этой толпой - каждый кусок кода должны знать несколько человек. Это обеспечивает выживание проекта в случае ухода одного или нескольких разработчиков, что в более-менее больших проектов случается всегда; нельзя надеяться, что по прошествии нескольких лет команда из 10-50 человек сохранит свой исходный состав. Как ты правильно заметил, производительность коллектива из N человек не равняется N-кратной производительностью одного человека. Но факторов здесь достаточно много, и они могут влиять как в отрицательную, так и в положительную сторону. Так отрицательными фаторами являются затраты на коммуникацию, изучение чужого кода, сложность распараллеливания задач и пр. В то же время есть и положительные, например увеличение общей производительности команды за счет разбиения задач согласно квалификации исполнителей (то, что делают опытные разработчики - слишком сложно для джуниоров; то, что делают джуниоры - слишком скучно для опытных), также происходит повышение квалификации разработчиков за счет общения с более опытными коллегами. Насчет того, что на проектирование уходит много времени - да, это достаточно затратный период, но большую систему без четко спроектированной, продуманной архитектуры поднять практически невозможно. Даже если все написано и работает - для сложных систем это только начало длительной фазы поддержки, сложность которой напрямую зависит от того, насколько хорошо была продумана архитектура. |
| Автор: KaraKum 25.3.2008, 17:59 |
| Мдаа.. сложное это дело - организация коллективного труда. А теперь расскажите, пожалуйста, об известных фактах о сроках и составах сотрудников каких-нибудь известных вам проектов по классификации. Например в играх - это создатели движка, реализаторы лан-игры, дизайнеры, звукооператоры, сценаристы и так далее. |
| Автор: skyboy 25.3.2008, 18:25 |
| KaraKum, ты реферат пишешь? это зависит от руководителя и сложности задачи: небольшая casual-игра не требует "сценаристов" и прочие ньюансы. или ты думаешь, что реально можно получить ответы на все вопросы? |
| Автор: KaraKum 26.3.2008, 00:25 |
| Хочу знать о фактах - может кто-то уже учавствовал вообще в программных проектах - и не особо важно в каких - играх, ОС, простые проги, проги для программистов и так далее - полезна любая информация. |
