Вы, наверное, много читали и слушали о Clean Code и, вероятно, устали от таких сокращений, как YAGNI, DRY и KISS. Все это обычно попадает прямо в корзину вашего мозга, потому что вы недостаточно тренируетесь.
После многих лет чтения чужого кода в обзорах кода я разработал «глаз», чтобы ловить плохой код, и я думаю, что вы тоже можете разработать его, читая сценарии, которые я разработал.
Следующие ниже примеры не обязательно являются ошибочным кодом, я имею в виду, представьте, что в них нет ошибок и они выполняют свою работу, но они не так удобны в обслуживании, как могли бы. Прочтите каждый пример, попытайтесь определить проблему и представьте, что бы вы сделали для ее решения.
(не читайте, пока не закончите код выше)
Проблема в этом примере - произвольные числа, которые используются в операторе if. Из контекста метода вы можете сделать вывод, что 21 - это установленный законом возраст для употребления алкоголя, а 20 - это цена пива, но на первый взгляд это не так просто. Обычно их называют magic numbers.
Один из способов решить эту проблему - создать именованные константы для чисел. Это облегчает чтение.
Кроме того, если в будущем что-то изменится, например, цена на пиво, оно будет менее подвержено ошибкам, изменив постоянное значение вместо поиска и замены появления 20.
(Не забудьте сначала попытаться определить это самостоятельно). В этом операторе return происходит слишком много всего. Человек, который написал это, умен, чтобы использовать идиоматические функции для решения задач в строке или в паре строк кода, поэтому это называется clever code.
Просто четко укажите, каково предполагаемое поведение, и сделайте его легким для чтения, даже если это означает разбиение кода на большее количество строк.
Между примером и решением было много шагов по рефакторингу, но уверяю вас, что оба они ведут себя одинаково.
Если партнер защищает свой умный код, говоря, что решение увеличивает размер приложения, это, вероятно, неверно, большинство современных языков при компиляции или минификации будут меньше любого умного кода, созданного человеком.
У этого метода слишком много обязанностей. Каждый раз, когда кто-то добавляет новую фигуру, также нужно будет создать новый оператор if/else. Также в этом случае вычисления площади являются однострочными, но если они станут более сложными, например, для проверки входных данных, этот метод станет огромным.
Разделите их на стратегии с их собственным методом, таким образом, если они вырастут в размерах, их будет легче поддерживать.
Обратите внимание, что мы также улучшили механизм выбора стратегии, используя словарь вместо нескольких операторов if/else.
Что ж, это на сегодня практика, я надеюсь, что это поможет вам почувствовать себя паукообразным при следующей проверке кода, которую вы проведете.
Вскоре я добавлю больше примеров в следующем посте. Если у вас есть идеи для других сценариев, разместите их в разделе комментариев.
Первоначально опубликовано на ederdiaz.dev
