Подскажите по раздельной отладке кода, Как отлаживают программы, которые пишут сразу несколько программистов Опции

[Николай Иванович...]

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

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

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

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

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

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

Сообщение отредактировал Николай Иванович Приходько - Oct 1 2008, 09:36

[MrYuran]

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

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

[Николай Иванович...]

А вы видели программы, где имеется две функции main()?

Нет. А Вы?

[DRUID3]

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

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

[Николай Иванович...]

А Вы никогда не перетягивали чужие исходники в виде готовых функций в свой проект?... Вот так и пишутся.

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

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

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

[yes]

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

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

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

[MrYuran]

Или к примеру я реализовал свою часть используя текущую версию кода коллеги. А коллега взял, да и изменил интерфейс к своей части. И что? Я из-за него должен переделывать свою часть? Не. Как-то это неправильно.

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

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

[Николай Иванович...]

Проект делят обычно на относительно автономные модули, так что их спокойно можно писать и отлаживать по отдельности.

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


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

[MrYuran]

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

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

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

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

[Николай Иванович...]

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

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

Сообщение отредактировал Николай Иванович Приходько - Oct 7 2008, 11:05

[andron86]

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

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

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

[Николай Иванович...]

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

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

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

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

[andron86]

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

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

[Николай Иванович...]

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

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

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

[andron86]

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

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

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

Сообщение отредактировал andron86 - Oct 7 2008, 12:05

[Николай Иванович...]

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

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

[Demeny]

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

[Harbour]

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