Каковы эффективные способы регистрации и отслеживания ошибок программирования?

Question

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

• Какую информацию о моих ошибках я должен хранить трек, так что я могу улучшить как программист?

И еще пара вопросов, связанных с этим:

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

Answer 1

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

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

Я нашел лучший способ использовать это, внедрив ваши правила в анализатор кода, такой как fxcop.

Answer 2

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

Answer 3

Да, отслеживание ваших личных ошибок выгодно. Обратитесь к SEI для многочисленных точек данных ( здесь одна наугад). Одной из таких методологий является Personal Software Process (PSP) . Слишком долго, чтобы войти сюда, но вот книга об этом . Также есть эта бесплатная публикация SEI на PSP.

Если вы отказываетесь от SEI и думаете, что Agile - это то, что вам нужно, вы, вероятно, получите больше пользы от такой книги, как Чистый код: Руководство по мастерству Agile Software (сайт издателя) .

Итог: дисциплинированный разработчик = хороший, недисциплинированный разработчик = плохой.

Answer 4

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

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

Кроме того, чтобы добавить к выше, что собирать:

• каковы симптомы ошибки (чтобы вы могли найти ее позже)
• как вы на самом деле решили это

Answer 5

• в чем была ошибка
• как этого избежать

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

Answer 6

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

Answer 7

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

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

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

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

Answer 8

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

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

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

1. Вы не предоставили достаточно информации о планировании заранее.
2. В борьбе, чтобы справиться, вы совершили еще одну ошибку, которая привела к решению проблемы и восстановлению.

В ретроспективе (всегда 20/20) вы можете увидеть решение, которое было неверным. Однако в то время было основано на наилучшей доступной информации. Это не ошибка. Любое предложение, начинающееся с «Если бы мы знали, что Х ...» бесполезно для анализа ошибок. Вы можете попытаться составить контрольный список всех вещей, которые вам необходимо знать в следующий раз, когда вы примете это решение. Но в следующий раз вы не будете принимать именно это решение, и какая-то другая информация окажется отсутствующей.

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

Answer 9

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

Читайте блоги других людей. Напиши свое. Вам не нужно публиковать это. Но вы должны превратить каждую ошибку в историю.

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

Вот ваш набросок.

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

Вы также должны записывать свои успехи почти в той же форме.

• Context. Что происходило.
• Ситуация. Проблема, которую вы пытались решить.
• Что вы сделали. Почему это было хорошо.
• Что вы узнали.

Если есть сомнения, посмотрите фильм. Шутки в сторону. Персонажи сталкиваются с выбором, делают ошибки и оправляются от этих ошибок. Эта сюжетная линия - сущность драмы. Ошибка это то же самое.

Answer 10

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

Я так вдохновлен, я думаю, что попробую это завтра.