Важность проверки кода: отказ от проверки кода из-за того, что она выглядит запутанной, может в конечном итоге дорого вам обойтись, так как вам придется добавлять в этот код, а он изначально не был хорошо структурирован.
Есть один хороший эвристический прием, когда нужно что-то реструктурировать: если в классе слишком много всего, что вы не можете удержать в голове, укажите это в своем обзоре — попросите людей выделить это в отдельный класс.
Это также буква S в SOLID — принцип единой ответственности. Вы можете получить технические и спорить, что такое ответственность. Но если вы не можете держать в голове все, что происходит на уроке, это уже слишком. Если тесты для этого класса выглядят большими и/или сложными, это уже слишком.
Меньший класс обеспечит более всестороннее тестирование кода, поскольку вы можете увидеть все различные варианты поведения. Каждый класс будет намного легче понять также.
Как вы гарантируете, что у вас не будет взрыва класса? Взрыв класса — это плохо, когда у вас есть 1 объект, который должен зависеть от 20 объектов для выполнения своей работы. Если 1 объект зависит только от 5 — он достаточно мал, чтобы понять, как он работает. Каждый из этих объектов может зависеть от 4 других объектов, и в контексте каждого класса легко понять, что они делают. Это хорошо.
Много классов — это не проблема, много зависимостей — это проблема. Если у каждого класса есть небольшое количество зависимостей, где у каждой зависимости есть небольшая сфокусированная миссия, это будет легко понять и легко использовать. поддерживать, и это хорошо.
Первоначально опубликовано на www.floatingpoint.ca.
