roboforum.ru

Поделитесь кто знает методиками ведения проектов командой программистов.
В первую очередь интересует:
1. Степень детализации блоков
2. Формат (представление) входных / выходных данных блоков
3. Документирование
4. ну и вообще с чего начинать и откуда рыть

Сильно зависит от структуры команды - может быть или не быть расслоение команды:
1. По крутизне (общий уровень);
2. По компетенциям (кто что делает в команде);

Может быть имеет смысл насильно ввести разделение по компетенциям (кто архитектор, кто реализатор, кто тестер и т.п.). Зависит от решаемых задач.

Форматы входа и выхода при делении разработки между программистами или вообще на блоки - описывать надо полностью. Какой формат конкретно выбирать под описание - зависит от того, что описываем

Документирование - логично выстроенная структура программы, правильные и короткие названия функций и переменных - снимают до 60-80% проблем с отсутствием документации.

Ну и общую структуру программы верхнего уровня, задумку и что на какие блоки делится надо конечно иметь описанное на не более чем 1-2 листах А4.

Добавлено спустя 4 минуты 4 секунды:
В команде равных сработавшихся программистов в жестких сроках может быть всякая экзотика типа экстремального программирования - это когда в пределе на 2 человек дают 1 компьютер и они по очереди пишут код. Со стороны кажется неэффективным, но на самом деле это очень тяжелый и эффективный режим! Только нельзя его долго держать, не комфортно. Лучше такой режим включать в критическом состоянии типа проваливаемых дедлайнов и т.п. - не более чем на 2-3 дня.
1. Во-первых практически никаких посиделок в личной почте \ контактах и т.п.
2. Во-вторых человек начинает писать код сразу так, что его должен понять как минимум напарник
3. В-третьих у человека который отошел от компа появляется время подумать, что исключает затупливание на одном месте, ибо затупил - вали от компа

1) Степень детализации блоков завсит от конкретно разрабатываемого ПО. Желательно чем лучше детализация, тем быстрее и конкретнее будут выполнены эти блоки
2) На уровне типов (там, где я работал, конкретно обсуждали даже параметры функий и процедур)
3) Документация обязательна но в свободной форме конкретно по той части проекта, которую программист разрабатывает. Начальник отдела собирает куски кода и документации, собирает их вместе (с программистами) и пишет более общую документацию
4) Не все программисты могут работать в команде. С этого и начинать - набирать Команду

не... я вообще про другое...

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

или по другому, можно ли создать проект из множества "черных ящиков" у которых есть только входные и выходные параметры?

Смотря какой проект, но в принципе если указать конкретно параметры на входе и на выходе - думаю можно

Добавлено спустя 30 секунд:
Но программа не обязательно оптимизированная будет

2EdGull: Фу ты блин надо же так закамуфлироваться

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

Добавлено спустя 58 секунд:

galex1981 писал(а):Но программа не обязательно оптимизированная будет

Всегда есть баланс между производительностью и модульностью.

так такая структура как раз и создается до начала разработки черных ящиков

Это ты кому и на что ответил?

Методика сильно зависит от того - в живую ли идет работа или она удаленная для большинства.

Добавлено спустя 1 минуту:
Re: Методика работы программистов в команде (метод черных ящиков
А вообще советую почитать "Совершенный код", там вроде описывались проблемы работы в команде и их решение.

Всё это чепуха, насчёт «архитектора проекта» которые всё распишет до мельчайших деталей. У меня начальник по образованию инженер-системотехник (железячник) по началу пару лет тоже пытался нам структурные блоки и алгоритмы разрабатываемых программ рисовать. Да только в начале разработки программист и сам плохо понимает, как он будет реализовывать тот или иной блок, а ещё разработка зачастую имеет эволюционный характер (от простого к сложному, от грамосткого к совершенному). Так что в начале проекта нужно представлять что вы хотите получить в общих чертах, и блоки разрисовывать не детально, а в общем и целом. То же самое с интерфейсами, всё в общих чертах, а детали появиться в ходе разработки. Для начала нужно сделать простенький макет программы, посмотреть на него, поплеваться, покритиковать как следует, сделать правильные выводы и начать следующую итерацию разработки (всё наново с учётом полученного опыта).

Ну в общем, это работа, много работы

Если архитектор расписывает всем всё до мельчайших подробностей - его срочно надо лечить

Нееет...
Не делайте этого

EdGull писал(а):хочется чтобы "почти каждый" желающий который выразит желание внести свой вклад, мог бы написать блок не сильно вникая в общую структуру. ... можно ли создать проект из множества "черных ящиков" у которых есть только входные и выходные параметры?

Я думаю для МК это нереально сделать. По сути такие ящики это скечи ARDUINO или римеры для других компиляторов и МК. Все они по отдельности работают, а вот произвольно свалить их в одну прогу врядли получится - возникнут конфликты между ними по использованию железа.

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

МК/ПК - однофигственно.

Можно на ПК одним черным ящиком захапать видеодевайс и никому не давать ничего.
А можно на МК написать модули, как мы в ORFA сделали драйверы, которые собирать в единую систему.

Всё реально, было бы желание

На ПК операционная система, а на МК она у вас есть?
Слышал на PIC18 сделали PICOS вроде система реального времени и там можно "мелкие программы" выполнять типа "параллельно" как на ПК.
А по поводу разрабатываемых "черных блоков" - конечно можно.
Самое главное четко написать требования к "входам"/"выходами" и типам данных этих блоков.
А блоками могут быть хоть функции, хоть процедуры, хоть драйверы и т.п.