Здравствуйте, _hum_, Вы писали:
__>я немного про другое спрашивал — как с такими временами перекомпиляции можно выполнять разработку проекта (тот же дебагинг)?
это одна из главных причин, по которой отладка вручную заменяется тестами

__>и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти)

Для примера:
У меня Qt на C2D c 8Gb RAM с CL=/MP собирался где то часов 6.
Сейчас на i7 5960X с 64Gb RAM где то минут 25 от силы.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, _hum_, Вы писали:

__>>так в том-т и дело, что логически не разбивается. вот есть у меня модель данных, и есть GUI с главным окном, в котором куча закладок, каждая из которых отображает какую-то сторону модели и позволяет ее редактировать. и получается эдакая "звезда", которую непонятно, как можно разбить на отдельные модули.

К>Уменьшай связность по хедерам.
К>Пимплы, предобъявления классов, фабрики.
К>

К>// main.h

К>#include "some_view.h" // плохо!
К>class SomeView; // хорошо!

К>class MainWindow {
К>  SomeView* child_;
К>  ...
К>};

К>///////////////////

К>// main.cpp

К>#include "main.h"
К>#include "some_view.h"

К>MainWindow::Create() {
К>  child_ = new SomeView(); // неплохо
К>  child_ = NewSomeView(); // лучше, потому что можно спрятать толстую реализацию за интерфейс и тонкую фабрику
К>};
К>

спасибо. а что делать с

1.h
class CFoo
{
public:
 struct TFoo{}
};


2.h

void foo(CSubFoo::TFoo& X);

?

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, _hum_, Вы писали:
__>>я немного про другое спрашивал — как с такими временами перекомпиляции можно выполнять разработку проекта (тот же дебагинг)?
__>это одна из главных причин, по которой отладка вручную заменяется тестами

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

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

Здравствуйте, nen777w, Вы писали:

__>>и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти)

N>Для примера:
N>У меня Qt на C2D c 8Gb RAM с CL=/MP собирался где то часов 6.
N>Сейчас на i7 5960X с 64Gb RAM где то минут 25 от силы.

ну, так вы не боитесь, что проект немножко подрастет, и вы опять скатитесь к тому же времени (уверены, что скорость роста времени компиляции от размера проекта сублинейное?)

Здравствуйте, _hum_, Вы писали:

__>а можно для тех, кто в танке, как-то поразвернутее, или ссылку на статью, где бы эта тема раскрывалась?

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

__>просто для меня тест — это просто предусловие и постусловие, позволяющее контролировать целостность кода при его изменениях.
__>как это может помочь автоматически избегать ошибок в процесс написания программы, ума не приложу.

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

Вот смотри. Сейчас ваш процесс выглядит примерно так.

Тимлид: Нужно [исправить баг А|реализовать стори B|быстро что-то подправить в модуле C]
Разраб: Yes, sir!

Разработчк изменяет пару строк кода где-то очень глубоко в кишках исходников. И говорит "готово!". А тимлид "А ты проверил?". И разработчик идет курить бамбук, пока все пересобирается, чтобы потом еще полчаса вручную докликивать программу в состояние, в котором он может косвенно проверить часть функциональности внесенного изменения. Обнаруживает баг в багфиксе и все по-новому. Два часа рабочего времени жестоко убито. Мотивация утопилась в унитазе, а профессиональная гордость хлещет водяру из горла.

А вот как выглядит процесс разработки здорового человека:
Разраб: так, что у нас тут в беклоге вниманием обделено? О! Поддержка формата времени протокола (страшная аббривеатура) в сетевом модуле.
Разраб: Ага, понятно, наконец-то мы будет показывать настоящее время, а не забивать его <unknown>. Так, где у нас спецификация...
(5 минут)
Разраб: Я хочу того же, что курили аффтфры спецификации протокола. Открывает Wireshark и выдергивает из сетевой сессии с прибором сообщения, содержащие оные типы. В случае отсутствия прибора или wireshark'a изобретает Hex-dump нужного PDU самостоятельно или заимствует его из спецификации, если аффтары озаботились примерами. В процессе придумывает забавные примеры невалидного элемента. Добавляет в протокола поддержку нового типа, а в проект юнит-тестов — проверку работы парсера, используюя награбленные или придуманные сырые данные. Не забывает тест, в котором на вход парсера подается мусор или специально инвалидированные данные. Щелкает "билд" на юнит-тест проекте. Оный собирает измененную либу парсера протокола, собирается сам и запускается. В консоли — 2 failed tests, которые разработчик нарочно зафейлил, чтобы проверить сам себя. Исправляет проваленные тесты, добавляет новые для граничных условий и обнаруженных серых пятен в спецификации, перезапускает билд. Через 5 минут — XXX tests passed.

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

Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!

Здравствуйте, landerhigh, Вы писали:

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

L>Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!

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

Здравствуйте, _hum_, Вы писали:

__>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.

Что-то ты белаешь неправильно. Это твой проект?
Посмотри-подумай, как ты добился таких выдающихся результатов.

У меня проект — 1 МБ (несжатых).
Полностью собирается за одну (!!!) секунду.
Если правка в одном файле — то я просто не успеваю морнуть.

Может быть не нужны тебе эти шаблоны?
Чё зря страдать-то?

Здравствуйте, Stanislav V. Zudin, Вы писали:

L>>Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!
SVZ>Звучит красиво. А на деле, млин, угрохается пара дней на несколько юнит тестов, и никакой гарантии, что покрыты все случаи. После чего на тесты кладется ооот-такой болт.
SVZ>Проходили.

Все это проходили. Потому что приделывать юнит-тесты к проекту, который изначально писался без них... там не только мотивация, там к унитазу очередь выстроится топиться.

Поэтому я и говорю — в подобных случаях помочь может только фанатичный адепт церкви святого gUnit и пророка его TDD. С полным арсеналом средств святой инквизиции и горящими глазами.

Здравствуйте, landerhigh, Вы писали:

L>>>Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!
SVZ>>Звучит красиво. А на деле, млин, угрохается пара дней на несколько юнит тестов, и никакой гарантии, что покрыты все случаи. После чего на тесты кладется ооот-такой болт.
SVZ>>Проходили.

L>Все это проходили. Потому что приделывать юнит-тесты к проекту, который изначально писался без них... там не только мотивация, там к унитазу очередь выстроится топиться.

От проекта тоже зависит. Скажем, для какого-нибудь моделирования юнит-тесты вообще бесполезны. Можно только смотреть результаты моделирования и сравнивать с эталоном.

L>Поэтому я и говорю — в подобных случаях помочь может только фанатичный адепт церкви святого gUnit и пророка его TDD. С полным арсеналом средств святой инквизиции и горящими глазами.

В добавок надо время выделять отдельно на написание тестов (это ИМХО главная сложность). А времени, как обычно, катастрофически не хватает.

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, _hum_, Вы писали:

__>>а можно для тех, кто в танке, как-то поразвернутее, или ссылку на статью, где бы эта тема раскрывалась?


L>А вот как выглядит процесс разработки здорового человека:

	text
	L>Разраб: так, что у нас тут в беклоге вниманием обделено? О! Поддержка формата времени протокола (страшная аббривеатура) в сетевом модуле. L>Разраб: Ага, понятно, наконец-то мы будет показывать настоящее время, а не забивать его <unknown>. Так, где у нас спецификация... L>(5 минут) L>Разраб: Я хочу того же, что курили аффтфры спецификации протокола. Открывает Wireshark и выдергивает из сетевой сессии с прибором сообщения, содержащие оные типы. В случае отсутствия прибора или wireshark'a изобретает Hex-dump нужного PDU самостоятельно или заимствует его из спецификации, если аффтары озаботились примерами. В процессе придумывает забавные примеры невалидного элемента. Добавляет в протокола поддержку нового типа, а в проект юнит-тестов — проверку работы парсера, используюя награбленные или придуманные сырые данные. Не забывает тест, в котором на вход парсера подается мусор или специально инвалидированные данные. Щелкает "билд" на юнит-тест проекте. Оный собирает измененную либу парсера протокола, собирается сам и запускается. В консоли — 2 failed tests, которые разработчик нарочно зафейлил, чтобы проверить сам себя. Исправляет проваленные тесты, добавляет новые для граничных условий и обнаруженных серых пятен в спецификации, перезапускает билд. Через 5 минут — XXX tests passed. L>В итоге — полностью реализовананя новая функциональность, покрытая тестами и даже в некоторых случаях прошедшая regression — ранее написанные тесты покажут, если новая функциональность вносит breaking change. Причем, за время, которого не хватило бы на полную сборку проекта и хотя бы один ручной тестовый прогон. Причем, проект автоматически прогоняет даже такие условия, которые во время ручного теста проверить невозможно. L>Это звучит как утопия, и привычные к методам разработки каменного века в это не верят, пока сами не увидят. Но как бы то ни было — вы все еще пользуетесь отладчиком при разработке? Тогда мы идем к вам!

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

Здравствуйте, alpha21264, Вы писали:

A>Здравствуйте, _hum_, Вы писали:

__>>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.

A>Что-то ты белаешь неправильно. Это твой проект?

да

A>Посмотри-подумай, как ты добился таких выдающихся результатов.

думаю, из-за шаблонов

A>У меня проект — 1 МБ (несжатых).

несжатых у меня собственных файлов (не включая библиотек) — 9Мб

A>Полностью собирается за одну (!!!) секунду.
A>Если правка в одном файле — то я просто не успеваю морнуть.

смотря в каком. если в cpp, который к тому же слабо связан с другими, то конечно, будет быстро

A>Может быть не нужны тебе эти шаблоны?
A>Чё зря страдать-то?

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

L>>Все это проходили. Потому что приделывать юнит-тесты к проекту, который изначально писался без них... там не только мотивация, там к унитазу очередь выстроится топиться.
SVZ>От проекта тоже зависит. Скажем, для какого-нибудь моделирования юнит-тесты вообще бесполезны. Можно только смотреть результаты моделирования и сравнивать с эталоном.

Ээээ.. если есть эталон, то что мешает написать тест, который и будет сравнивать? Сюда автотесты подходят аж бегом.

L>>Поэтому я и говорю — в подобных случаях помочь может только фанатичный адепт церкви святого gUnit и пророка его TDD. С полным арсеналом средств святой инквизиции и горящими глазами.
SVZ>В добавок надо время выделять отдельно на написание тестов (это ИМХО главная сложность). А времени, как обычно, катастрофически не хватает.

А вот эта проблема несколько странная. У тех, кто привык использовать автотесты в разработке, оценка времени на разработку всегда включает время на написание тестов.

Здравствуйте, _hum_, Вы писали:

__>извините, но вы здесь описали вариант, когда либо готовый код правится, либо к готовому коду добавляется еще один готовый функциональный блок, и проверяется их совместимость. я нигде не увидел собственного написания.
__>ну, простейший пример — вам сказал тим лид — нужно написать функцию, транспонирующую матрицу. как в этом случае будет выглядеть работа с тестами без дебагера?

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

Здравствуйте, _hum_, Вы писали:

__>извините, но вы здесь описали вариант, когда либо готовый код правится, либо к готовому коду добавляется еще один готовый функциональный блок, и проверяется их совместимость. я нигде не увидел собственного написания.

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

__>ну, простейший пример — вам сказал тим лид — нужно написать функцию, транспонирующую матрицу. как в этом случае будет выглядеть работа с тестами без дебагера?

Вот сходил ты в курилку и придумал, что назовешь свою функцию

    Matrix transpose(const Matrix& original);

Налил кофе и написал следующие три теста

    TEST(transposeMatrix, transposeNegative)
    {
        // this is more a border case test
        ASSERT_TRUE(transpose(emptyMatrix).empty());   // Also checks that we don't crash if matrix is empty
    }

    TEST(transposeMatrix, transposePositiveSymmetrical)
    {
        Matrix symmetricalMatrix = ...; // Initialize
        Matrix expected = ...; // Manually transposed matrix
        ASSERT_EQ(expected, transpose(symmetricalMatrix));
        ASSERT_EQ(symmetricalMatrix, transpose(transpose(symmetricalMatrix)));
    }

    TEST(transposeMatrix, transposePositiveAsymmetrical)
    {
        Matrix asymmetricalMatrix = ...; // Initialize
        Matrix expected = ...; // Manually transposed matrix
        ASSERT_EQ(expected, transpose(asymmetricalMatrix ));
        ASSERT_EQ(asymmetricalMatrix , transpose(transpose(asymmetricalMatrix )));
    }

Потом написал собственно код транспонирования.

Запустил тест. На все-про-все 5 минут времени и у тебя гораздо более полное покрытие, нежели ты может добиться ручными проверками в отладчике.


Ты мне лучше скажи, зачем тут вообще отладчик может понадобиться?

Здравствуйте, tdiff, Вы писали:

T>Вот-вот, такое бодрое описание как всё зашибись, только в нём ничего нет про, собственно, разработку новой функциональности.

Ребята, вы меня пугаете:

Разраб: так, что у нас тут в беклоге вниманием обделено? О! Поддержка формата времени протокола (страшная аббривеатура) в сетевом модуле.

Здравствуйте, landerhigh, Вы писали:

L>Ребята, вы меня пугаете:

L>

L>

Разраб: так, что у нас тут в беклоге вниманием обделено? О! Поддержка формата времени протокола (страшная аббривеатура) в сетевом модуле.

Прекрасно, и что? Как будто написать парсер времени — это такой самоочевидный кусок кода из 1 строки.

Я верю, что есть люди, которые на бумажке пишут алгоритмы любой сложности и отлаживают их исключительно по входным выходным данным. Но, честно говоря, не совсем понимаю, как им это удаётся. Пусть программист сделал ошибку и его алгоритм расходится в заоблачные дали. При этом в своём классном тесте он видит что-то в духе "assertion failed: result != 1337 (actual result = 23152135)". Неужели метод пристального взгляда — наилучший способ понять, где ошибка? Я полагаю, что во многих случаях под дебаггером можно разобраться гораздо быстрее.

Здравствуйте, tdiff, Вы писали:

L>>Ребята, вы меня пугаете:

L>>

L>>

Разраб: так, что у нас тут в беклоге вниманием обделено? О! Поддержка формата времени протокола (страшная аббривеатура) в сетевом модуле.

T>Прекрасно, и что? Как будто написать парсер времени — это такой самоочевидный кусок кода из 1 строки.

Это парсер метки времени хитровыдуманного индустриального протокола, который несет в себе, кроме собственно метки времени, еще кучу всякой ерунды полезной информации вроде индикатора качества часов, источника синхронизации, индикатора аварии и т.п, причем ужато все это самым извращенным способом, до которого можно было додуматься только под веществами. Те, кто могут такое делать в одну строку, какают фиалками и ездят на единорогах

T>Я верю, что есть люди, которые на бумажке пишут алгоритмы любой сложности и отлаживают их исключительно по входным выходным данным. Но, честно говоря, не совсем понимаю, как им это удаётся.
T>Пусть программист сделал ошибку и его алгоритм расходится в заоблачные дали.

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

T>Я полагаю, что во многих случаях под дебаггером можно разобраться гораздо быстрее.

Нет. Дебаггер для разработчика — это даже не каменный топор. Это намного хуже.


P.S. Я всегда говорил, что на время разработки у программистов нужно отбирать отладчик.

Здравствуйте, landerhigh, Вы писали:

L>Это парсер метки времени хитровыдуманного индустриального протокола, который несет в себе, кроме собственно метки времени, еще кучу всякой ерунды полезной информации вроде индикатора качества часов, источника синхронизации, индикатора аварии и т.п, причем ужато все это самым извращенным способом, до которого можно было додуматься только под веществами. Те, кто могут такое делать в одну строку, какают фиалками и ездят на единорогах

Вот я по то же. black-box тестирование алгоритма может сказать только то, что он в некоторых случаях работает правильно или нет.
Если алгоритм достаточно сложен, и мы знаем, что он неисправен, далеко не всегда тесты помогут выявить ошибку.

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

Так что именно будет понятно из теста-то? Что ничего не работает? Что дальше делать?

L>И, что характерно, написание такого теста (один раз, к слову сказать), займет меньше времени, чем просто запустить программу под отладчиком. Один раз. И, что будет оценено намного позже, этот тест будет там тогда, когда о нем уже забудут и какой-то джуниор в попытке "улучшить" алгоритм его сломает. И этот тест тут же даст ему по рукам.

Я совершенно не пытаюсь сказать, что тесты не нужны.

Здравствуйте, tdiff, Вы писали:

T>Вот я по то же. black-box тестирование алгоритма может сказать только то, что он в некоторых случаях работает правильно или нет.

Это не black-box, это white-box. Вы можете посмотреть внутрь ящика и сказать "Ба!"

T>Если алгоритм достаточно сложен, и мы знаем, что он неисправен, далеко не всегда тесты помогут выявить ошибку.

Если вы подозреваете, что в алгоритме есть баг, просто пишете тест, воспроизводящий условия, при котором, как вы подозреваете, алгоритм ломается. Это просто и быстро. Проверяете свои подозрения. В отладчике в общем случае это сделать уже невозможно.

L>>Если это программист, то он знает, какие условия нужно проверять. В том числе он также напишет тест, проверяющий, не расходится ли алгоритм в заоблачные дали. И так его и назовет. И если этот тест провалится, то даже никакого "пристального взгляда" не понадобится, все будет понятно сразу.
T>Так что именно будет понятно из теста-то? Что ничего не работает? Что дальше делать?

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

L>>И, что характерно, написание такого теста (один раз, к слову сказать), займет меньше времени, чем просто запустить программу под отладчиком. Один раз. И, что будет оценено намного позже, этот тест будет там тогда, когда о нем уже забудут и какой-то джуниор в попытке "улучшить" алгоритм его сломает. И этот тест тут же даст ему по рукам.
T>Я совершенно не пытаюсь сказать, что тесты не нужны.

Тесты — необходимы. Отладчик — вреден.