Vigorous Hive  »  Разработчикам »  Запахи плохого кода
Клиентам
Продукты
Разработчикам
Другие проекты
О компании
Запахи плохого кода

Запахи плохого кода (от английского Code Smells) также иногда называемые Кодом с душком - это ключевые признаки необходимости рефакторинга. В процессе рефакторинга мы избавляемся от запахов, обеспечивая возможность дальнейшего развития приложения с той-же или большей скоростью. При использовании методологии TDD сеанс рефакторинга проводится в среднем раз в 10 минут. Если точнее - после завершения реализации каждого функционального требования. Отсутствие регулярного рефакторинга с течением времени способно полностью парализовать проект и тогда вам скорее всего прийдется выбросить несколько лет разработки и потратить еще пару лет чтоб переписать с нуля. Поэтому запахи надо убивать пока они маленькие.
Дублирование
Повторяющиеся или подобные участки кода. Это основной запах от которого следует избавлятся в первую очередь. Не устраненное дублирование приводит к необходимости вносить одинаковые изменения в различных участках кода, что закономерным образом снижает скорость разработки в разы.
Никогда не разговаривай с незнакомцами
Использование вот таких конструкций:   value = ObjectA->ObjectB->GetValue(); Почему это плохо? Потому что код который обращается к классу начинает сильно зависеть от структуры этого класса. В итоге, если мы хотим убрать свойство ObjectB из класса А, например заменить переменную на вызов фабричного метода мы вынуждены бегать по всему коду и править все вызовы. Кроме того код обращающися к объекту А начинает зависить еще и от структуры объекта Б и опять же изменение структуры Б, влечет многочисленные правки по всему коду.
Магические константы (или просто Магия)
Фрагмент кода содержит значение (например: число или строку) откуда оно взялось и почему равно именно этому - по текущему фрагменту кода определить затруднительно или невозможно.
Код непонятен без комментариев
Частая причина - код одного метода выполняет несколько логически слабо связанных действий. Лучше вынести их в отдельные методы, названия этих методов отразят суть происходящего, комментарии станут лишними.
Длинный метод
Если метод занимает более страницы, вполне вероятно что в нем скрыты логически разные блоки, также в длинных методах часто присутствует дублирование в неявном виде, когда дублирующий код раскидан по телу метода отчего его становится сложно обнаружить.
Длинный класс
Как и в случае с длинным методом, длинный класс также может содержать скрытое дублирование. Кроме того это может свидетельствовать о том что в одном классе смешанно несколько логически несвязанных или слабо связанных абстракций, что затрудняет поиск нужного фрагмента кода в приложении.
Кик (от английского KICK  - Keep It Complex Kamicadze) или Укус Небестного Архитектора
Попытка создать универсальную архитектуру приложения, вместо того чтобы следовать необходимости. Начинающие программисты часто склонны увлекатся поиском универсальных решений, решением сложных архитектурных задачь. В итоге как правило - перегруженная архитектура, которую трудоемко поддерживать, убытки организации из-за большого количества времени потраченного на её создание, а самое главное - универсальности не получается. И не может получиться. А почему? А потому что приложение с помошью которого вы можете заставить компьютер делать абсолютно любые действия методом нехитрой настройки уже созданно и называется оно Компилятор. Следуйте принципу KISS - Keep Is Simple Stupid, то есть пишите простой и понятный код реализующий именно ту задачу которую необходимо решить в данный момент, возможность легко разобратся в существующем даст вам гораздо больше универсальности.
Использование глобальных переменных
Ничто так не повышает связность кода как использование глобальных переменных. Одна из тех вещей которые нельзя делать никогда. Если уж совсем никак - используйте паттерн Одиночка (Singleton), хотя-бы это избавит вас от необходимости таскать кусок кода гле происходит инициализация глобальной перенной. Но Синглетон - это крайний вариант, если вы решились на его использование, у вас должны быть для этого серьезные основания.
Руки прочь от данных
Никогда ни при каких обстоятельсвах не правьте данные "руками". Забудьте навсегда о phpmyadmin и надстройках вроде mod_custom в Joomla. Это не для вас, это для админов. Это для того чтоб затыкать дыры когда программист не справился с задачей. У программиста на любое изменение БД должен быть скрипт.
Класс имеет более одной зоны отвественности / One responsibility class
По сути, это иначе сформулированный старый принцип ООП. Принцип декомпозиции. Когда мы проектируем архитектуру, мы абстрагируем логические блоки в виде классов. Если у нас класс начинает работать с несколькими логически не связанными единицами, значит наша абстракция более не верна. Значит нам нужно разбить класс на несколько. Например - в процессе устранения дублирования у нас выделился метод отвечающий за установление соединения с удаленным сервером. Мы выносим этот метод в отдельный класс, называем его скажем TFarFarAwayServer. Таким образом у нас появилась новая абстракция - удаленный сервер.