Каков наилучший подход для кодирования в среде медленной компиляции?

Question

Раньше я писал код на C # в стиле TDD - пишу / или изменяю небольшой фрагмент кода, перекомпилирую за 10 секунд все решение, повторно запускаю тесты и снова. Легко ...

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

Моя производительность все еще в порядке для небольших проектов, но она ухудшается, когда с увеличением размера проекта и после того, как время компиляции достигает 10+ минут, оно становится действительно плохим. И если я найду ошибку, мне придется снова начать компиляцию и т. Д. Это просто расстраивает.

Таким образом, я пришел к выводу, что для маленьких кусочков (как и прежде) это неприемлемо - любые рекомендации, как я могу в течение часа или около того привыкать к старой привычке кодирования, при просмотре кода вручную (не полагаясь на быстрый Компилятор C #), и только перекомпиляция / повторный запуск модульных тестов один раз в пару часов.

С C # и TDD было очень легко написать код эволюционным путем - после дюжины итераций, независимо от того, с какой ерунды я начинал, заканчивался хорошим кодом, но он просто больше не работал для меня (в среда медленной компиляции).

Буду очень признателен за ваши отзывы и отзывы.

p.s. не знаете, как пометить вопрос - любой желающий может пометить вопрос соответствующим образом.

Приветствие.

Answer 1

Я обнаружил, что перекомпиляция и тестирование выводят меня из «зоны», поэтому, чтобы получить преимущества TDD, я довольно часто помещаю в репозиторий git и запускаю фоновый процесс, который проверяет любые new commit, запускает полный набор тестов и комментирует объект commit в git с результатом. Когда я подхожу к нему (обычно вечером), я возвращаюсь к результатам теста, исправляю любые проблемы и «переписываю историю», а затем снова запускаю тесты для новой истории. Таким образом, мне не нужно прерывать свою работу даже на короткое время, необходимое для перекомпиляции (большей части) моих проектов.

Answer 2

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

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

Answer 3

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

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

Вторичной задачей может быть, например, «ускорить частичное время компиляции основной задачи за счет уменьшения межкомпонентных зависимостей». Несмотря на это, вы, возможно, достигли жесткого предела, когда требуется 10 минут для того, чтобы связать исполняемый файл вашей программы, поскольку разделение объекта на несколько dll, как хак для разработки, вероятно, не очень хорошая идея. Ключевым моментом, который следует избегать, является выполнение второстепенной задачи: «нажми SO» или this .

Answer 4

Я не понимаю, почему вы не можете использовать TDD с C ++.Я использовал CppUnit еще в 2001 году, поэтому я предполагаю, что он все еще на месте.

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

Возможно, ваша чашка чая будет полезна для круиз-контроля, Team City или другого процесса сборки и тестирования.Вы можете просто зарегистрироваться как можно быстрее и позволить автоматической сборке произойти на другом сервере.