Идеального кода не существует. Средний программист обязан посвящать большую часть своего времени исправлению кода. В одном из моих предыдущих блогов я определил, что означает Скорость программиста. Исправление ошибок в коде способствует отрицательной скорости, т. е. даже если вы работаете сверхурочно, чтобы исправить ошибки, вы на самом деле обесцениваете свою скорость, потому что на самом деле вы не добавляете ценности продукту, а вместо этого пытаетесь скрыть дерьмо, которое вы или кто-то другой произвел.
Каждый программист сталкивается с проблемой отладки кода для исправления ошибок. Теперь единственной продуктивной мерой, которую можно предпринять здесь, является эффективная отладка, чтобы вы тратили минимальное время на исправление проблем. Для достижения эффективности самое важное — организовать процесс написания кода. Если вы будете следовать лучшим практикам при написании кода, вероятность того, что вы допустите ошибки, будет меньше.
Рассмотрим случай, когда ваши спецификации начинают глючить после последней интеграции в код. Теперь грубый способ поиска проблемы будет заключаться в просмотре всего кода и выяснении решения, которое явно неэффективно. Но если вы постоянно интегрируете код при создании зеленых сборок, вы можете легко проверить последнюю зеленую сборку и сравнить ее с текущим кодом, чтобы выявить различия, которые, по сути, должны быть причиной ошибки. Это Diff Debug, термин, придуманный Мартином Фаулером.
Самый важный урок здесь — знать об отладке diff. Это работает только тогда, когда у вас есть проблема с регрессией, и вам нужен тест и разумный процесс сборки, чтобы вы могли найти проблему достаточно быстро.
Блог Фаулера об отладке Diff-https://martinfowler.com/bliki/DiffDebugging.html
