Раздавить этих тварей

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

Привыкай, или откладывай!

Разобраться с ошибками (подходы)

Очистите свой участок

Один из способов избавиться от ошибок в коде - это вообще не писать их!

  • Тестирование
  • Модульность
  • Простота и ясность

При тестировании (используйте это Руководство по TDD Swift) вероятность появления ошибок в вашем коде гораздо меньше, поскольку он тестируется еще до того, как он будет приближен к производству.

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

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

Написание //TODO нормально для отсутствующей функциональности, но неполный код не следует возвращать - и это отличное применение аннотации в вашем коде!

Не игнорируйте предупреждения

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

Другой способ выразить это:

Сделай один раз - сделай правильно.

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

Подумайте о том, чтобы игнорировать свои проблемы

Это кажется нелогичным, но вы можете игнорировать некоторые свои проблемы и надеяться, что они исчезнут. Непрофессионально? Конечно. Не рекомендуется? Это сложно.

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

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

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

Используйте средство отслеживания проблем

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

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

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

Проверить при предположениях

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

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

Предположения: предпосылки для возникновения проблемы.

Теории. Имеющиеся у вас идеи можно последовательно проверять в поисках решения.

Блок гнезда (сузить проблему)

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

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

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

Вернитесь к тому моменту, когда все было хорошо (контроль версий)

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

Создать MVP

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

Проверьте основной дизайн

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

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

Если вы попали в такую ​​ситуацию, надеюсь, вы нашли ее раньше ...

Ошибки записи

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

Их запись также требует некоторой тонкости и понимания подхода к разработке программного обеспечения.

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

  • Воспроизводимость: можно ли воспроизвести?
  • Серьезность: насколько важно исправление ошибки?

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

Когда все потеряно (Стратегии)

Одна из важнейших стратегий решения проблем заключается в следующем:

  • сделать перерыв
  • выспаться без стресса

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

Ошибки прочь (Заключение)

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

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

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