Когда вы пишете свой код, вы реагируете на ошибки заранее или реагируете?

Question

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

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

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

Answer 1

Всегда должен быть баланс.

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

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

Answer 2

Какой вид программирования?На это невозможно ответить вообще.(Это все равно, что спросить: «Ты носишь шлем во время игры?» - ну, играя что ?)

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

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

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

Answer 3

ИМХО, слово «ошибка» (или его свободный синоним «ошибка») само по себе означает, что это поведение программы не было предусмотрено.

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

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

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

Answer 4

Я выступаю за активный подход.

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

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

Answer 5

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

Answer 6

Я обычно задаю себе кучу «что если» при кодировании, например:

• Пользователь нажимает кнопку, что если он не выбрал дату?
• Пользовательпечатает в окне поиска, что если они попытаются ввести там html?
• Текст метки зависит от значения с общего диска, что если он не сопоставлен?

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

Answer 7

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

• Разработка на основе тестов (это может показаться упреждающим)
• Строгая статическая типизация (реактивная, но часть жесткого итеративного цикла разработки,как, впрочем, это обеспечивается моим компилятором ML, и я много компилирую)

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

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