Есть ли польза от компиляции кода по ходу дела?

183

Недавно у меня было собеседование, на котором мне дали час, чтобы написать настоящий код. Это не было огромное количество, вероятно, менее 100 строк. Примерно через 45 минут я скомпилировал, запустил его и заставил работать. Возможно, я потратил 5-10 минут на разработку ошибок компиляции и пару незначительных ошибок, но в целом все было очень гладко. (Кстати, я получил предложение от них.)

Однако, то, что озадачило меня, было то, что после того, как я передал законченный код, интервьюер сказал мне, что единственное, что я сделал неправильно, это «не компилирую, как я иду». Я спросил его, в чем разница, и он сказал: «Что бы вы сделали, если бы вы закончили код, а он не скомпилировался вовремя».

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

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

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

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

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

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

CaptainCodeman
источник
54
Или это, или то, что мои привычки называются плохими привычками людьми с разными привычками.
CaptainCodeman
9
@DocBrown Сравнение действительно, если конечная цель имеет правильный продукт. Программа, которая «работает», не лучше, чем программа, которая работает неправильно. Вы не можете ожидать, что компиляция проверит ваш код для вас больше, чем вы можете ожидать, что проверка орфографии исправит ваши грамматические ошибки.
CaptainCodeman
7
То, мешает ли компиляция вашему рабочему процессу, очень субъективно и зависит от языка, среды сборки, размера / сложности проекта и т. Д. ИМО с большей вероятностью станет проблемой для крупных устаревших проектов.
pjc50
64
Я полностью согласен с ОП. Я не могу понять, как кто-то может судить о своих рабочих привычках, например, когда он / она использует для запуска компилятор. Единственное, что имеет значение, это результат усилий. Это правильно? Это ремонтопригодно? Работает ли он в ожидаемые сроки? Сколько времени это заняло? Это интересные вопросы. Все остальное - произвольный БС. Если собеседник пишет 2 часа идеального кода, который компилируется с первой попытки, в чем проблема? Только потому, что интервьюер делает это по-другому? Боже мой
JensG
9
Следует также отметить, что для некоторых языков и сред IDE (Java / [Eclipse | NetBeans | и т. Д.], C # / Visual Studio, ...) среда IDE уже компилирует все в фоновом режиме в реальном времени, как вы вводите в эффект дает вам немедленную петлю обратной связи о том, сделали ли вы ошибку. Можно было бы надеяться, что разработчики IDE провели какое-то исследование в поддержку этого подхода к компиляции по ходу работы.
Огр псалом33

Ответы:

223

Есть ли польза от компиляции по ходу дела?

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

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

Если взять пример, скажем, вы программировали на C-подобном языке и забыли }где-то в середине программы.

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

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


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

Одед
источник
72
Действительно, для подобных синтаксических ошибок современные IDE по существу компилируются и перекомпилируются все время, чтобы сделать ваш цикл обратной связи настолько коротким, насколько это возможно, и это неоправданно полезно для выявления мелких ошибок.
Фоши
12
@CaptainCodeman - я бы сказал, что есть некоторые ошибки компиляции, из-за которых вам нужно копаться в большом количестве кода. Это более верно для больших кодовых баз и больших наборов изменений.
Одед
29
Иногда компилятор дает вам подсказку вместо подсказки, например, ошибки шаблона gcc.
pjc50
14
@ pjc50: абсолютно (с этим легче справиться, не меняя слишком много вещей сразу перед следующей компиляцией, чтобы вы точно знали, что вы изменили в конце).
Док Браун
21
Идея не в том, чтобы просто скомпилировать случайно. Это компилировать на каждом значимом шаге, компилировать, когда вы ожидаете, что он все еще будет работать должным образом. Например, я скомпилирую для проверки, чтобы убедиться, что объекты создаются / удаляются должным образом, или чтобы убедиться, что события запускаются правильно для нового класса, который я создал. Если я создаю класс и каким-то образом подключаю его к своей программе, я хочу убедиться, что я сделал это правильно, прежде чем приступать к подключению большего количества материала к моему приложению. Менее важно с маленькими приложениями, жизненно важными для больших.
Thebluefish
108

Компиляция - это форма теста, особенно в языках, в которых широко используются такие типы, как Haskell или ML . На других языках это синтаксическое сканирование, которое мало что говорит.

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

Не все системы сборки работают быстро. Я работал над проектом (C ++) , где Make будет тратить 30 секунд только стат «тин все , чтобы определить , нужно ли строить или нет, а большинство файлов будут занять несколько минут , чтобы построить , если вы сделали изменения. Мы не хотели делать это чаще, чем каждые 10-15 минут. Кто-то, без сомнения, предоставит анекдот о том, что во время компиляции вы берете колоду перфокарт и переносите их в другое здание ...

Скомпилируйте, когда вы почувствуете, что выполнили полный концептуальный блок в своей голове и готовы его проверить. Раз в минуту или раз в неделю в зависимости от рабочего процесса.

pjc50
источник
25
когда вы берете свои перфокарты в сисопы для загрузки, убедитесь, что вы никогда их не уроните, потому что возвращение их в правильном порядке - настоящая PitA! Ах, в те дни, когда основным инструментом отладки была резинка.
gbjbaanb
3
Когда я только начинал программировать, я измерял свой прогресс по тому, сколько кода я мог написать без компиляции - по существу, по качеству моего ментального компилятора. Сначала было несколько символов, затем несколько строк. Теперь мне все равно. Я много компилирую для небольших изменений, я просто хочу увидеть эффект, я очень мало компилирую, когда делаю структурную компоновку проекта.
Фил
Хм. Просто хочу сказать, что хорошо написанный C ++ файл не должен занимать более нескольких секунд для компиляции. Если это дольше, это запах плохого кода. И если он настолько большой, что у make есть проблемы, я бы сказал, что приложение слишком монолитное. У «моего» make никогда не было проблем, и даже после компиляции Linux.
Френель
2
Когда я ушел, было 1,5 миллиона LOC. Обратите внимание, что Linux - это C, а не C ++; в gcc шаблоны кажутся медленными, и если вы сделали что-то умное и полезное, что происходит с медленной компиляцией, нет простого способа профилировать компилятор, чтобы понять, что это было.
pjc50
21
@gbjbaanb Я думаю, что было бы лучше сказать «времена, когда контроль над источниками был резинкой». ;)
JasonMArcher
35

Итак, мой вопрос заключается в следующем: я что-то пропустил?

Да, ваш разум не является компилятором. Хотя компилятор может сделать n переключений контекста в секунду, ваш ум не может. Количество переключений контекста, которые ваш ум может сделать за день, зависит от ряда факторов, таких как опыт / знакомство с базой кода, насколько вы погружены в код, насколько чистым является код, насколько сложна проблема, которую вы решаете, насколько вы устали, если вас часто прерывают или в шумной обстановке и так далее.

Компиляция базы кода (все одновременно) в первый раз (например, «проект с 20 файлами») заставит вас переключать контекст с того, о чем вы думаете (например, «здесь это значение установлено на 5, затем в for for blablabla, и комплексный алгоритм возвращает правильное значение при возврате ") к проблеме компиляции, которая совершенно не связана с тем, о чем вы думаете (разные имена файлов / модулей / функций / предварительных условий / синтаксиса / переменных, предварительных условий и т. д. ).

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

Есть ли польза от компиляции по ходу дела?

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

Если вы компилируете в очень короткие итерации (это предполагает, что процесс компиляции оптимизирован, чтобы занять короткое время), можно исправить ошибки компиляции, не выходя из «зоны».

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

Это также распространяется сообществом разработчиков программного обеспечения, но на это есть веские причины.

В моем понимании это недопустимый аргумент, потому что «получение кода для компиляции» для заданной длины кода обычно включает в себя исправление постоянного числа ошибок компиляции и занимает довольно постоянное количество времени

Для меня это звучит так, будто у вас мало (или нет) опыта в обслуживании средних и больших унаследованных кодовых баз (сотни или тысячи исходных файлов). Именно здесь это отношение (т.е. «компилируйся по ходу дела») поможет больше всего, и именно здесь вы формируете такую ​​привычку.

Я полагаю, что люди, которые вас интересовали, пришли к аналогичному выводу («у вас мало или совсем нет опыта работы с большими кодами»).

utnapistim
источник
1
«скомпилируйте и измените десять» - множество ситуаций, когда это самая маленькая значимая единица измерения; например, добавление нового параметра в функцию и все ее сайты вызовов.
pjc50
7
Переключатели контекста. Ты прикалываешься, да? Если мы говорим об автоматической фоновой компиляции, чтобы указать синтаксические ошибки в вашем коде по ходу дела, это нормально. Но самое быстрое переключение контекста не сможет сказать вам, правильно ли реализована логика алгоритма или подходит ли алгоритм вообще. Но это то, что отличает рабочее решение от аккуратно организованного, безошибочного компиляции и быстрого, но совершенно неверного кода.
JensG
5
@JenS, нет, я не шучу. Необходимость перепрыгнуть весь код, чтобы исправить ошибки компиляции, гарантирует, что вы больше не думаете о проблеме, которую решаете в данный момент (выводит вас из зоны). Если вместо этого вы можете компилировать при написании кода, вы можете продолжать работать над проверкой алгоритма, а не синтаксиса. Самый быстрый способ обработки переключений контекста - убедиться, что они вам не понадобятся). Мой пост действительно предполагает идеальный мир (с быстрой компиляцией C ++ больших баз кода и минимизированными взаимозависимостями).
utnapistim
1
@JensG, что кажется логической ошибкой: речь идет не о выборе между скомпилированным кодом и дерьмовым кодом, а о любых возможных преимуществах компиляции более одного раза.
Йорг
1
Я сомневаюсь, что утверждение о том, что разбить концентрацию в десятки раз за короткое время для исправления единичных синтаксических ошибок, быстрее, чем разбить ее один раз и исправить дюжину синтаксических ошибок за один раз (после того, как вы беспокоитесь о своем реальном алгоритме). Это, конечно, не так, как переключатели контекста работают в вычислениях (мы пытаемся оптимизировать пропускную способность здесь, в конце концов). И я работал над проектом с около 500k LoC кода C ++, который развивался более десяти лет, так что я надеюсь, что мы еще не взяли карту неопытности?
Во
26

Я думаю, здесь есть больше, чем небольшой профессиональный снобизм. Смысл, по-видимому, в том, что «если у вас никогда не было необходимости регулярно компилировать, то вы никогда не работали с чем-то таким сложным - получите больше опыта и вернитесь, когда научитесь работать именно так, как мы».

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

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

Если вы не поклонник постоянной перекомпиляции, значит, вы в хорошей компании. Вот Дональд Кнут:

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


Все это, как говорится ... если вы работаете в контексте, где компиляция - это бесплатное действие, то почему бы и нет? Дома, в личных проектах, я нажимаю ctrl-S примерно каждые 30 секунд, а ярлык «компиляция» почти так же часто, в IDE, которая постоянно запускает код через интерфейс компилятора, чтобы обеспечить подсвечивание ошибок в реальном времени. Зачем отказываться от бесплатного обеда?

DeveloperInDevelopment
источник
Я не согласен с тем, что компиляция бесплатна, отвлекающие средства стоят дорого! Но в остальном хороший ответ, спасибо :)
CaptainCodeman
Возможно, мне следовало сделать жирный, выделенный курсивом "if" вместо "iff" ... Я думаю, что в зависимости от проекта, компилятора и среды это может быть чертовски близко к свободному действию. Если у вас есть второе окно или экран для вывода компилятора, вы можете компилировать почти так же часто, как останавливаетесь. Если бы вы были действительно хардкорным (а я нет), вам бы даже не пришлось отвлекаться от своего кода - при условии, что компилятор выдал достаточно подробных ошибок, чтобы зарегистрироваться на вашем периферийном зрении. Опять же, если компиляция выполняется достаточно быстро, в противном случае см. Выше.
DeveloperInDevelopment
2
I hit ctrl-S about once every 30 seconds, Я, вероятно, экономлю вдвое чаще, лол. Это действительно плохая привычка. Иногда я сохраняю в середине строки кода, а затем снова сохраняю в конце. Всякий раз, когда я перестаю думать на секунду и не печатать, я сохраняю.
Cruncher
21

Есть преимущества для компиляции, как вы идете. Но я очень согласен с тем, что выполнение задачи - это нормальная стратегия кодирования.

Самым значительным преимуществом инкрементной компиляции является менталитет, который многие приобретают, если они ждут окончания, чтобы скомпилировать и протестировать : в конце мы больше заинтересованы в том, чтобы заставить код работать, чем что-либо еще в этой точке. Мы говорим: «О, просто нужно добавить эту скобку, чтобы компилятор перестал жаловаться» или «о, просто нужно использовать это заглавные буквы», не думая, есть ли скрытая семантическая ошибка, которую скрывает эта синтаксическая ошибка. Я действительно считаю, что синтаксические ошибки часто вкладываются в семантические ошибки (обратное неверно).

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

ЛВС
источник
5
+1 за освещение связи между семантическими и синтаксическими ошибками
Док Браун
15

Я понимаю преимущества тестирования вашего кода по мере продвижения, но зачем компилировать?

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

Крайний случай - разработка через тестирование (TDD). Очевидно, что TDD не работает с вашей стратегией, поскольку TDD означает чрезвычайно короткие циклы проверки записи, компиляции (должна завершиться неудачей), записи кода, повторной компиляции, выполнения теста, исправления ошибок, повторной компиляции, рефакторинга, компиляции -снова, пробный тест, и так далее ...

Так что не каждый делает TDD, по крайней мере, не всегда (я тоже, я признаю). С вашей текущей стратегией у вас никогда не будет возможности даже попробовать TDD. Но даже если вы не используете TDD, IMHO крайне полезно проверять ваш код более регулярно - что невозможно, если вы не компилируете его регулярно. А когда ваш тест не пройден, вы запускаете его для отладки (что может помочь вам понять, почему красивый алгоритм, который вы написали за несколько минут до того, не ведет себя так хорошо, как вы думали, что должен). И чем больше кода вы пишете без компиляции, тем больше кода вы пишете без тестирования, и тем больше вероятность того, что вы столкнетесь с ситуацией, когда вы не можете предсказать, что время для устранения проблемы равно «O (1)», так как вы написали.

Док Браун
источник
1
Я согласен с вами, но я думаю, что есть разница между компиляцией программы, потому что вы хотите ее запустить, и компиляцией, когда нет ничего значащего для тестирования (или для исправления ошибок компиляции).
CaptainCodeman
@CaptainCodeman: Я думаю, что при написании 100 строк кода почти всегда должно быть много мелких частей, которые можно было бы индивидуально проверить на свои собственные. 100 строк кода обычно означают что-то между 4 и 15 функциями (или> 20, если вы кодируете в стиле Боба Мартина).
Док Браун
5
@CaptainCodeman: В TDD никогда не бывает «ничего значащего» для тестирования. Классический пример - вы хотите написать новый класс (давайте назовем его Foo), затем первое, что вы делаете, это создаете модульный тест и пишите, new Foo();что, очевидно, не удастся скомпилировать, поскольку вы не написали определение класса. В TDD это веская причина для запуска компилятора - это доказывает, что ваш модульный тест работает (с ошибкой).
Slebetman
@ Slebetman: спасибо за этот полезный комментарий. Я хотел бы добавить, что ИМХО это не ограничивается TDD. При написании 100 строк кода всегда есть что-то значимое для проверки между ними, независимо от того, используете ли вы TDD или нет.
Док Браун
14

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

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

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

Чтобы не отметить вас за это, доверие должно быть оправдано. Если бы вы потратили 45 минут на написание чего-либо без компиляции, а затем потребовали еще 45 минут на его отладку, я бы сильно об этом сказал.

Карл Билефельдт
источник
8

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

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

Другое дело для обычных сборок: ничто не мешает вам начать компиляцию, как только у вас есть полный блок написанного кода, который должен скомпилироваться. Затем вы можете продолжить писать больше кода, пока идет компиляция, до тех пор, пока вы не сохраните новые изменения до завершения компиляции. Так что практически не тратится время на ожидание сборки. Если вы подождете, пока не напишете все, что собираетесь написать в то время, вам придется ждать компиляции без каких-либо действий. Это в основном ручная версия того, что современные IDE могут делать автоматически в фоновом режиме.

Хайд
источник
Интересно, что это хорошая причина для регулярной компиляции, даже если компиляция идет медленно . Хорошая точка зрения.
Слёске
3

Для достаточно опытного программиста компиляция кода никогда не является узким местом.

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

Я регулярно пишу код весь день без компиляции, затем скомпилирую и просто исправлю, какие синтаксические ошибки и предупреждения компилятор сообщает перед тем, как зафиксировать свой код (с пометкой «нужно проверить!» ). У меня нет проблем с очисткой более 1000 строк кода на C или C ++ всего за несколько минут.

С другой стороны, отладка и тестирование - это то, что нужно. Логические ошибки возникают по разным причинам, и мне еще предстоит встретиться с компилятором, который расскажет мне о подпрограмме, которую я совершенно забыл написать, или заметит, что мое двоичное дерево не работает, потому что я вставил, node->leftкогда это должно было быть node->right.

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

PS - Если бы я смотрел ваш обзор кода, прочитав его, я бы нанял вас на месте. Это то, что профессионал делает каждый раз.

паритет
источник
4
«Мне еще предстоит встретиться с компилятором, который расскажет мне о подпрограмме, которую я совершенно забыл написать». Я полностью полагаюсь на то, что компилятор сообщит мне, когда я не выполнил далеко идущие изменения. Иногда я даже переименовываю переменную, чтобы предотвратить успешную компиляцию, пока не проверил каждый экземпляр ее использования и не дал им все новое имя. Я не понимаю, как вы можете сказать, что вы не сталкивались с компилятором, который не предупредит вас, если чего-то не хватает. Если вы не пишете пустые подпрограммы-заполнители, а потом забываете о них, в этом случае вам помогут небеса.
Ян Голдби,
@par Спасибо за ваш ответ; Приятно осознавать, что я не единственный, кто так кодирует!
CaptainCodeman
3
@CaptainCodeman Я хорошо знаю, что логические ошибки более коварны, чем ошибки компилятора. Но это было его утверждение о том, что компилятор не может рассказать вам об отсутствующем коде, который я хотел оспорить. Если вы сознательно не пишете неправильный (или неполный) код, который компилируется ... но это скорее побеждает аргумент, что ошибки, которые компилятор не может уловить, являются реальной проблемой IMO. Черт возьми, я даже использую компилятор, чтобы переместить каретку на строку, где мне нужно написать код. Но, может быть, я очень ленивый.
Ян Голдби,
1
@IanGoldby: Вы полностью упустили момент, и я бы даже сказал, что вы решили исказить мои слова. Компилятор не может предупредить вас о пропущенном коде так же, как я не могу сказать вам, что вы будете есть на завтрак завтра. Преднамеренно вводить синтаксические ошибки, чтобы компилятор напомнил вам о чем-то - это техника программирования; это не квалифицируется как ошибка и не дает компилятору экстрасенсорные способности.
паритет
1
@par Я прошу прощения за оскорбление, которое я, очевидно, вызвал своим комментарием - оно не было предназначено, и я, конечно, не собирался искажать то, что вы сказали. Теперь я вижу, что когда вы пишете неполный код, который, тем не менее, компилируется, вы практикуете, чтобы гарантировать, что его нельзя забыть, добавив #warning или TODO. Это законная техника. Важная вещь, с которой мы оба согласны, заключается в том, что код, который компилируется, но не работает, гораздо более опасен, чем код, который не компилируется.
Ян Голдби
3

Нет, откладывать компиляцию вполне разумно, пока вы не выполнили достаточное количество кода (а «достаточное количество» зависит от кодера и кода, который пишется).

Например, если вы замечательный программист, который тратит время на то, чтобы все сделать правильно, и вы не пишете большие объемы или сложный код, то регулярная компиляция - это пустая трата и, вероятно, отвлечение. Если нет, то компиляция каждой функции может быть полезной. Это зависит от человека.

В качестве контр-примера представьте, что вы пишете код JavaScript - здесь нет компилятора. Вместо этого (учитывая природу большей части кода JavaScript) вы должны запустить программу (или обновить страницу), чтобы увидеть результаты своего кодирования. Теперь вы не можете сделать это, пока не напишите достаточно кода, чтобы иметь смысл. В результате, разработчики JavaScript склонны «компилировать» так часто, как могут, что не всегда очень часто.

Короче говоря, здесь нет правильного ответа - интервьюер не ошибается, но и вы тоже. Делай то, что делает тебя продуктивным, и забудь, что кто-то говорит тебе, что ты должен делать. Есть много более важных факторов, связанных с кодированием, чем ваша склонность к F7регулярным попаданиям (или нет) не имеет абсолютно никакого значения.

gbjbaanb
источник
Ваш второй абзац неясен; Вы можете отредактировать его, чтобы было ясно, должен ли «удивительный кодер» регулярно компилироваться или нет. (Вы добавили «t» и изменили «нет» на «нет»?)
DougM
@ DougM - очень сильно.
gbjbaanb
Нередко скриптовый код разрабатывается «вживую», то есть выполняется в среде REPL. Таким образом, «компиляция» действительно происходит постоянно, большая часть кода, записанного в исходный файл, также была выполнена один раз. Не все пишут код сценария таким образом, но я бы сказал, что любой, кто привык и любит относительную «безопасность» статически типизированных языков и ошибки компилятора, возникающие из-за плохого кода, должен так работать на языках сценариев.
Hyde
2

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

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

Лорен Печтель
источник
1

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

Мой опыт совершенно другой: менее 5% ошибок компиляции, которые я получаю, связаны с синтаксисом . Я хорошо знаю язык, когда я получаю ошибки, это в основном ошибки типа, говорящие мне, что семантика неверна.

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: Я также могу сделать аналогию с контролем источников, когда целая команда работает над одними и теми же источниками. Компиляция по мере продвижения - это как частые коммиты, это помогает избежать большой боли в конце, когда вам нужно объединить и разобраться во всем.

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

Еще одним преимуществом является то, что при работе с вашим кодом, если вы постоянно его компилируете или почти компилируете, вы можете воспользоваться множеством семантических функций IDE (безопасное переименование, рефакторинг, поиск использования символа ...) ,

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

Элдрич Конундрум
источник
1
Я обычно отключаю надоедливые «функции» компилятора, такие как автоматическое форматирование, рисование красных линий под вашим текстом и т. Д., Так как считаю, что я более продуктивен без этих тупых функций.
CaptainCodeman
1

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

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

Затем нужно немного времени для написания кода, который компилируется.

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

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

gnasher729
источник
Это имеет большой смысл. На мой взгляд, хороший разработчик должен уметь писать код на бумаге весь день, а потом в конце дня набирать его.
CaptainCodeman
1

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

Компании в наши дни не просто заинтересованы в готовом продукте. Они хотят знать, что все это время было «под контролем». Для них «попасть туда - это половина удовольствия».

Том Ау
источник
кажется, это не дает ничего существенного по сравнению с тем, что было опубликовано в предыдущих 16 ответах
gnat
2
Спасибо, но о какой потере мы говорим? Конечно, если вы не сделали что-то радикальное, например, случайно написали не на том языке, вам никогда не пришлось бы переписывать код просто из-за ошибок компиляции.
CaptainCodeman
@CaptainCodeman: это заставляет компании чувствовать себя лучше и является формой «страхования». Это то, что стоит денег, но заставляет большинство людей (включая менеджеров) «лучше спать по ночам».
Том Аю
@gnat: Я пытался подчеркнуть, что большинство преимуществ были «корпоративного» уровня, и программист должен это делать, потому что начальник сказал ему об этом, а не потому, что программист считает, что это правильно или неправильно.
Том Аю
хорошие моменты в пользу «более короткой петли обратной связи» уже были сделаны и хорошо объяснены в самом первом ответе здесь; Я, честно говоря, не понимаю, как вбивание догадок о «компаниях в наши дни» добавляет что-то достойное к тому, что уже было сказано
комнат
1

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

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

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

Я не утверждаю, что мой подход - это «один верный путь», но он мне очень помог. Подобно многим программным методологиям, которые начинаются с заглавной буквы, существует равное количество «мандатов» для проведения интервью. Они все нары. Вы должны делать то, что работает для вас и вашего бизнеса.

Марк Э. Хаас
источник
0

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

Для того, чтобы протестировать эти маленькие кусочки, вам нужно скомпилировать.

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

Пер Александерссон
источник
0

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

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

Laurent
источник
Похоже, это не дает ничего существенного по сравнению с тем, что было опубликовано в предыдущих 15 ответах
gnat