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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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