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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

• Какова была ошибка.
• как его можно избежать

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Я так вдохновлен. Думаю, я попытаюсь это сделать.

Ответ 9

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

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

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

Вот ваш план.

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

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

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

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

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

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

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

Ответ 12

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