Вероятно, большая часть кода, который вы когда-либо видели, немного попахивает. В худшем случае код просто воняет. Скорее всего, это в свой код неприятный запах вы добавили сами. Но чем именно пахнет код?
Плохой запах — это поверхностный признак того, что может быть глубинной проблемой с вашей системой или качеством кода. В большинстве случаев плохой запах требует определенного рефакторинга. Хотя плохо пахнущие программы и работают, но это показатель низкого качества кода.
В этой статье мы рассмотрим восемь распространенных ошибок, приводящих к тому, что код начинает пованивать.
Лучшие запахи легко обнаружить, и в большинстве случаев они приводят к действительно интересным проблемам, — Мартин Фаулер.
1. Стрельба дробью
Вы когда-нибудь сталкивались с ситуацией, когда небольшое изменение в каком-либо классе приводит к тому, что вам приходится менять много разных классов? Ну, это примерно и есть “стрельба дробью” или “shotgun surgery”.
Для меня, запах дробовика — один из моих «любимых». Я видел, как многие разработчики вводили этот шаблон в свой код. Это неизбежно приводит к множеству повторяющегося кода. Таким образом, проблемы с этим стилем в основном такие же, как и при любом другом дублировании кода.
Дублирование одной и той же логики во многих местах может значительно увеличить затраты на внесение изменений на поздних этапах. Это приведет к увеличению времени разработки. Даже небольшие функции потребуют больше времени на разработку, поскольку база кода станет все более и более неуправляемой.
2. Странные решения
Странное решение — это когда во всей системе одна проблема решается одним способом, а другая, похожая, в той же системе решается другим.
Одним из признаков таких решений является странные или противоречивые реализации. Этого запах обычно вы можете распознать по дублированному, но слегка измененному коду.
Чтобы избавиться от странный решения, вы должны начать с определения вашего предпочтительного решения. В некоторых случаях реже используемое решение может быть более правильным, если оно лучше, чем решение, которое используется чаще.
Определив предпочитаемое решение, вы можете начать удалять странные решения из кода и заменять их на предпочтительное.
После того, как вы внедрили предпочтительное решение, согласованное во всей вашей кодовой базе, вы сможете переместить все экземпляры этого решения в одно место, тем самым устраняя дублирование.
3. Усложнение очевидного
Мы все видели код, в котором шаблоны проектирования были введены просто так. Особенно грешат этим молодые разработчики. Это их способ показать себя и дать понять другим разработчикам, насколько хорошо они умеют программировать. Независимо от того, что они знают, это снижает качество кода.
Но когда именно мы можем сказать, что кто-то излишне усложняет? Хорошее практическое правило — вы усложняете, когда пишете код, который решает проблемы, которых у вас нет.
Наихудший вид чрезмерного усложнения обычно совершается во имя создания расширяемого и удобного кода — при этом обычно достигается полная противоположность.
4. Слишком много параметров
Роберт К. Мартин сказал следующее о параметрах в своей книге «Чистый код: руководство по гибкой разработке программного обеспечения»:
Идеальное число аргументов для функции равно нулю (niladic). Далее следует один (монадическое), за которым следует два (диадическое). По возможности следует избегать трех аргументов (триадных). Использование более трех аргументов требует особого обоснования, и их не следует использовать в любом случае.
Я думаю, что это хороший итог. Используйте как можно меньше параметров.
Если вы обнаружите, что передаете группу данных, полученных от другого объекта, в качестве параметров, подумайте о возможности передачи самого объекта в метод.
Как только вы уменьшите количество параметров, используемых в методах, вы получите более читаемый и более короткий код.
5. Длинные методы
Мы все видели методы, которые занимали более ста строк кода. Верить в качество этого кода невозможно.
Причина появления этого плохого кода очень проста. В большинстве случаев код добавляется в метод, но никогда не удаляется. Поскольку писать код легче, чем читать, этот код остается незамеченным, пока метод не превращается в уродливый и негабаритный, и начинает плохо пахнуть.
Длинные методы, как правило, имеют более чем одну ответственность. Лучше всего придерживаться единой схемы ответственности. Это означает, что метод может делать только одну, и только одну вещь.
6. Непоследовательное именование
Чтобы обеспечить читаемость кода и поддерживать его в удобном виде, наименование должно выполняться правильно.
Недавно я написал пост о некоторых простых правилах, которым вы можете следовать, чтобы создавать значимые имена в своем коде. И трудно переоценить то, насколько важны хорошие имена переменных. Выбор хороших имен требует времени, но экономит он больше времени, чем на это расходуется.
Проблема с именами заключается в том, что когда вы программируете, вы принимаете решения об именах, но это время, когда решения оказываются наименее эффективными.
Все свежо в вашем уме. Вы знаете, что делать, вы знаете архитектуру и любая странная функцию, которую вы создаете, имеет смысл.
Однако всякий раз после выхода, проект входит в фазу технического обслуживания. На данный момент это самая длинная фаза, и именно здесь имена становятся важными.
Существует много разных способов присвоения имен, каждый из которых имеет свои плюсы и минусы. Самое главное, чтобы эти соглашения были согласованы, и вы их придерживались.
7. Скопления данных
Иногда вы обнаруживаете, что один и тот же небольшой набор параметров постоянно кочует по различным разделам вашей кодовой базы. Эти отдельные значения называются скоплениями данных.
Если несколько методов принимает один и тот же набор параметров, это может быть признаком того, что эти параметры связаны. Чтобы сохранить группу параметров вместе, может быть полезно объединить их в новый объект. Это улучшит организацию вашей кодовой базы.
Наличие скопления данных само по себе не является ошибкой, но это может быть индикатором более глубокой проблемы.
8. Посредники
Иногда у вас есть класс, который имеет много методов, которые ничего не делают, кроме как делегируют другому методу в другом классе. В этом случае делегируемый класс считается middle-man классом.
В некоторых случаях использование такого среднего класса считается полезным. Но в большинстве случаев было бы лучше избавиться от такого среднего класса.
Для этого вы должны попытаться связаться напрямую с классом, который реализует поведение, а не проходить через посредника.