Zeus писал(а):На ПК операционная система, а на МК она у вас есть?
Вы не находите, что между "система из модулей" и "ОС" есть небольшая такая разница. Нефиговых таких масштабов Речь шла о возможности разработки командой программистов модулей\блоков, из которых можно собрать продукт. У нас на МК так ORFA реализована - есть драйвера из которых собирается прошивка. Драйвера пишутся независимо, с небольшими оговорами по поводу общего железа конечно. Но не суть - главное что я спокойно меняю принципы управления сервами и никому не надо переписывать драйвер I2C или GPIO или ADC - всё работает.
ИМХО это реально и двигаться от общего к частному. Лучше завести сразу под это дело инструменты, чтобы не тыкаться на страницах форума. Сначала задача совсем общая, потом разбивается на модули (набор модулей можно согласовывать всем вместе), потом модуль разбивается на куски и тогда уже каждый может брать кусок и делать его. Походу описывая интерфейсы. Делать по мере - не сразу все дробить, а когда будет кому это делать, так как в процессе наверняка будут изменения и переписывать и переиначивать структуру будет напряг.
можно посмотреть на гибкие методологии и делать итерациями, делать тогда когда будет кому.
и так, прочитал я рекомендованные вами труды и узнал что оказывается, то что я называл "черными ящиками" весь цивилизованный мир называет "модульное программирование"
отсюда следующий вопрос, кто нибудь имеет опыт модульного программирования (желательно в команде)?
кстати, вот помоему довольно неплохое описание принципов модульного программирования
К слову - модульное программирование в чистом виде давно уже устарело. Нынче как минимум в моде ООП, т.е. модули объединяются в объекты и т.п.
Кстати по твоей ссылке не понял, что они имеют в виду под "модуль имеет 1 вход и 1 выход".
Если уж начал - почитай про итерационный подход к разработке ПО - реально почти всё ПО сейчас именно так разрабатывается. Никто не проектирует всё до последнего гвоздика сразу и в ходе разработки появляются препятствия и возможности, которые намного эффективней учесть в дальнейшем движении, чем игнорировать. Что конечно не отменяет планирования, проектирования архитектуры решения и т.п.
=DeaD= писал(а):Кстати по твоей ссылке не понял, что они имеют в виду под "модуль имеет 1 вход и 1 выход".
наверное, имеется ввиду метод = модуль, т.к ему передаем параметры, и он возвращает результат вычислений. Хотя нифига не понятно, как тогда с классами быть, ведь в них не только методы есть, и есть методы, которые ничего не возвращают, т.е vоid.
Да вообще мутное утверждение, наверное имели в виду модуль=функция и что формат передаваемых параметров и возвращаемого ответа фиксирован и един для функции.
=DeaD= писал(а):наверное имели в виду модуль=функция
я это и написал лично мне удаленная командная разработка _чего-либо_ кажется диким и низко эффективным, по крайней мере вначале разработки, но пришлось однажды участвовать, но у нас небыло никаких модулей, архитектором было составленно тз, где по пунктам было расписано кто и что должен сделать, а потом тл собирал всё в кучу, руководствуясь JavaDoc и UML.
небыло такого понятия, 1 человек реализовывал 1 пункт тз исходя из знаний, потому как все технологии используемые в проекте не знал никто, кроме тл, поэтому один пункт тз обширнее чем метод. Может это и покажется неудобно, но рефакторинг особо не нужен тогда.
я не знаю как они в С++ называются, в jаvа они Listener. Я писал слушатель папок, который мониторил некоторые папки на сервере, в общем это не один метод, возможно группа тогда уж, но я не знаю к чему отнести интерфейсы, ибо ниразу это не метод, а значит и не модуль
Добавлено спустя 1 минуту 25 секунд: Re: Методика работы программистов в команде (метод черных ящиков это я к тому, что не так - я первый модуль, ты второй, он третий, вон те четвертый и пятый.
а методы объекта чем не модули?
я запутался вроде.