Самое худшее, что может произойти с разработчиком, — это застрять в своей нынешней квалификации. Когда вы знаете о пробелах в собственных знаниях, но не понимаете, чем можно улучшить ситуацию. Второй из худших раскладов — вы долгое время доверяете своему текущему уровню знаний. Поверьте на слово: если хоть один из разработчиков в команде не спорит с вами хотя бы по одной строчке кода каждую неделю, то вся эта команда деградирует.
В данной статье я расскажу про Code Smells — это определенные признаки, указывающие на необходимость рефакторинга текущего кода с целью его улучшения.
Примечание: все примеры взяты из реальных проектов, найденных на GitHub.
Code Smells (код с душком)
Code Smells — это некий набор общих признаков, которые указывают на то, что код недостаточно хорош, и для его чистоты потребуется рефакторинг.
— Дублированный код и логика
Так уж сложилось, что разработчики — народ ленивый, и во многих аспектах это даже неплохо. Однако лень и копи-паст строчек кода — не самое удачное сочетание. Такое действие может привести к наиболее типичным изъянам в коде, то есть к логическому задвоению, как примере ниже.
Для того, чтобы избавиться от столь явных проблем в коде, необходимо выделить красную часть в отдельный метод, который мы также сможем использовать там, где нужно.
— Длинные методы и классы
Уверен, все мы совершали эту ошибку, добавляя еще один оператор if() или for() к существующему методу для проверки данных пользователя или его авторизации. Короче говоря, так делать не стоит. Если вам нужна такая проверка, то создайте для нее собственный метод. Идеальный метод должен состоять из 4–20 строк. Если строк больше, то извлеките часть их них в новый метод. То же касается и классов: чем меньше, тем лучше. Особенно, если вы придерживаетесь принципа единственной ответственности.
— Дублирующие методы в тех же или разных классах
Еще один изъян кода, о котором не стоит забывать, — это наличие двух методов с одинаковым функционалом. Пример ниже поможет вам все понять.
— Расходящиеся модификации класса
Если вы хоть раз читали о принципах SOLID (особенно о единственной ответственности), то должны знать, что в одном классе должна существовать только одна причина для изменения кода. То есть, в классе User не должно быть функции, связанных с продуктами или преобразованием файла. Этот code smell можно легко исправить извлечением постороннего метода в новый класс, например, в класс Product или FileSystem.
— Стрельба дробью
Стрельба дробью — антипаттерн в разработке ПО (прим. переводчика) и это полная противоположность расходящимся модификациям. В данном случае, вы будете менять множество классов по единой причине. То есть для применения какого-либо действия всем этим классам потребуется одна и та же причина изменения. Например, вам нужно создать новое правило пользователя «Суперадминистратор», после чего вы должны будете отредактировать ряд методов в классах Profile, Products и Employees. В таком случае призадумайтесь о том, чтобы сгруппировать эти методы в один единый класс, чтобы этот новый класс имел единую причину изменения.
— Завистливая функция
Иногда в своем классе вы находите метод, который активно пользуется другим классом. В таком случае стоит переместить этот метод в тот самый используемый класс. Посмотрите на картинку ниже. Разве не логично будет перенести getFullAddress() из класса User в ContactInfo, раз вся его работа сводится к использованию методов ContactInfo.
— Группы данных
Иногда вы встречаете множество функций с почти одинаковым списком параметров. Этот тип параметров, используемых только вместе, и вызывает code smell группы данных. Взгляните на пример ниже. Вы увидите, что почти все типы бронирования требуют паспортных данных.
Здесь лучше перенести паспортные данные в собственный класс, а затем передавать объект PassportInfo в методы резервирования. Это отличный пример повторного использования кода. Но помните, что длинные списки параметров могут привести к ошибкам кода, конфликтам и осложнению модульного тестирования.
Перевод статьи Mohamed Aladdin: Become An Expert Developer with These Advanced Coding Tips (part 1)
