Подскажите по раздельной отладке кода. Что это за зверь такой и как она (эта самая раздельная отладка) реализуется на практике.

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

А как это возможно если в программе на C++ только одна функция main?

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

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

Объясняю несколько сумбурно, но я надеюсь Вы меня поняли. Главный вопрос: как компилировать и отлаживать свой кусок программы НЕЗАВИСИМО от кусков программы, которые пишут другие программеры

А вы видели программы, где имеется две функции main()?
Интересно, к примеру, при использовании билдера кто-то вообще смотрит, что там в функции мэйн написано?

Нет. А Вы?

А Вы никогда не перетягивали чужие исходники в виде готовых функций в свой проект?... Вот так и пишутся.
Пишете у себя свой кусок, тестируете его со своим main() , а руководитель добавит в дерево проекта и соберет когда будет необходимость. Если задача была поставлена правильно и задание выполнено корректно - проблем не будет. Но если то руководитель или тестировщик заметят, что что-то не так - они Вам "намекнут" . Основной груз, здесь, на руководителе проекта - разбивать задание на подзадания корректно учитывая работу всей системы.

А если нет "готовых" функций у коллеги, а мне уже нужно как-то отлаживать свою часть программы?
Неужели винды и другие крупные программистские проекты писались путём "перетягивания" кода друг у друга?

"Не верю"(с) - Станиславский.

Наверняка для крупных проектов существует какой-то механизм раздельной отладки кусков программы разными программистами. Т.е. чтоб один программист не был СИЛЬНО завязан на скорость коддинга другого программиста. А то получается я свой кусок кода напишу, а мой коллега "тормозит". Или к примеру я реализовал свою часть используя текущую версию кода коллеги. А коллега взял, да и изменил интерфейс к своей части. И что? Я из-за него должен переделывать свою часть? Не. Как-то это неправильно. Наверняка в Microsoft есть какие-то механизмы для раздельного написания, компиляции и отладки частей программы.

по этому делу есть куча программистких книжек - как Вы представляете отладку проектов типа того же виндовса или линукса?

но трудоемкость возрастает - то есть если разбили на 2 части, то каждому программисту достанется не 1/2, а 3/4 работы - вот такая арифметика

основные инструменты - руки.sys и система контроля версий (нужно отметить, что у микрософта это все не самого лучшего качества)

Конечно, неправильно!
Любая коллективная работа начинается с подробного описания структуры и параметров взаимодействия.
Причём не только в программировании.
Допустим, несколько человек проектируют блок.
У каждого своя плата.
Договорились, начали.
Каждый разрабатывает и тестирует свою плату отдельно, исходя из ТЗ.
Естественно, что никто просто так не может изменить внешние интерфейсы своей платы (тип разъёмов, пины, сигналы) без согласования с остальными. Так же и с программами.

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

Да как можно отлаживать по отдельности если 99% моего кода - это вызовы кода других 23-х программистов


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

а вас сильно волнует, когда вы пишете printf() или sin(), сколько программистов писали этот код?

Естественно.
Причём некоторые временные заглушки могут остаться навсегда.
Говорят, в той же винде их тысячи.

А где можно почитать о том как в MS VС++ писать и (главное главное) отлаживать код когда одну прогу пишут сразу несколько программистов? Какие есть программные средства для этого? Где можно прочесть о том как писался и отлаживася по кускам код Винды? Unix-а и т.п.?

Ведь наверняка ест какие-то средства "гальванической развязки" программистов друг от друга при работе в большом программном проекте.

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

может вам что-то вроде этого надо: Model-Driven Software Development (MDSD) - UML 2.0, SysML (Rhapsody)

Вот именно, что готовыми, а не теми, которые ещё сами "в процессе"


Т.е. по описалову того, что должны делать эти функции пишите заглушки?

ну да, типа "заглушки"

А при разработке Винды кто пишет заглушку модуля? Тот же чел, что и разрабатывает сам модуль?
Т.е. как там всё организовано?

Чел начала пишет заглушку своего модуля. Отдаёт её всем челам, которые юзают его модуль. А сам спокойно пишет свой модуль. А потом когда модуль готов - забирает заглушку и отдаёт всесто неё рабоающий модуль? Так?

Вам же в 4 и 7 посту всё описали. обычно "заглушки" все сами себе и пишут.

А в чём же тогда выгода раздельной разработки? Если я буду должен написать заглушки для всех 853-х модулей о которых я понятия не имею (ведь ими занимаются мои коллеги и они знают об этих модулях всё и кто как не они смогут написать заглушку своего модуля лучше всего)

Для отладки своего куска кода большого программного продукта отдельно от остальных можно пользоваться технологией "юнит тестов" (unit tests).
Юнит-тест - это простейшая программа-оболочка, которая вызывает собственно Вашу основную функцию, над которой Вы работаете в большом проекте и которую собираетесь отлаживать, развивать и поддерживать в работоспособном состоянии. Юнит-тест моделирует основные входные ситуации, в том числе и заведомо ошибочные, и анализирует результат. Имея такой юнит-тест, легко не только отлаживать, но и развивать и сопровождать Ваш кусок кода, например, внеся какие-то изменения в Вашу функцию, можно оперативно убедиться, что модуль работает исправно, вычисляет правильно, от ошибочных ситуаций не валит всё приложение.
Например, Вы пишете функцию вычисления синуса double my_sinus(double angle). Тогда очевидным юнит-тестом для неё будет программа, вызывающая её с набором известных значений и анализирующая результаты на правильность (по таблице Брадиса ), а также вызывающая её с заведомо гигантскими аргументами.
Данный подход очень схож с тестбенчами в разработке FPGA ядер.

в идеале тест должен быть написан так чтобы код прошел по coverage на 100%. Ясен пень - это никак не гарантирует, что при сборке модуля, из-за архитектурных просчетов, что-то будет вообще работать