Основы запаха кода Ruby / Rails 04

Запахи кода и их рефакторинг могут быть очень пугающими и пугающими для новичков. В этой серии я постарался сделать их понятными как для опытных разработчиков Ruby, так и для начинающих.

В этой заключительной статье упоминается еще несколько запахов, на которые вы должны обратить внимание, и резюмируется, чего хотел добиться этот небольшой сериал. Последний запах, если хотите …

темы

• Комментарии
• Callbacks
• Плохие имена
• Примеси
• Скопления данных

Последний дуновение

Последняя статья в этой серии напоминает бонусный раунд. Я хотел познакомить вас с еще несколькими запахами, которые можно устранить быстро и без особых суеты. Один для дороги, так сказать. Я думаю, что благодаря знаниям, которые вы собрали из предыдущих статей, большинству из них даже не понадобятся примеры кода, чтобы разобраться в этом.

Когда вы откроете книгу о рефакторинге, вы легко найдете больше запахов, чем мы обсуждали. Тем не менее, с этими основными под вашим поясом, вы будете хорошо подготовлены, чтобы справиться с любым из них.

Комментарии

Щедро примененные комментарии редко бывают хорошей идеей — вероятно, никогда. Почему нет? Потому что это может означать, что ваш дизайн не говорит сам за себя. Это означает, что ваш код, вероятно, настолько сложен для понимания, что требует буквального объяснения.

Прежде всего, кто хочет пройти через куски текста в вашем коде или, что еще хуже, через код, который трудно понять. Джекпот, если оба являются обычным явлением. Это просто дурной тон и не очень внимательный к людям, которые идут за тобой — не обижайся, мазохисты, мучай себя в будущем, сколько хочешь.

Вы хотите написать код, который достаточно выразителен сам по себе. Создавайте классы и методы, которые говорят сами за себя. В лучшем случае они рассказывают историю, которой легко следовать. Это, вероятно, одна из причин, почему соглашения о конфигурации стали настолько влиятельными. Изобретая колесо, конечно, иногда хорошая практика для улучшения вашего понимания и изучения новой территории, но в быстро меняющихся средах разработки ваши коллеги ищут ясности и быстрой навигации — не только в ваших файлах, но и в создаваемой ментальной карте. в вашем коде.

Я не хочу углубляться в совершенно новую тему, но во всем этом большую роль играет наименование. А чрезмерное комментирование в вашем коде слегка противоречит хорошей практике именования и соглашениям. Не поймите меня неправильно, замечательно добавлять комментарии — просто оставайтесь на пути, который «освещает» ваш код, а не отвлекает от него. Комментарии, конечно, не должны быть инструкциями для умного кода, который в большинстве случаев можно расшифровать, потому что вы хотели похвастаться. Если вы сохраняете свои методы простыми — как следует — и называете все с вниманием, то вам не нужно писать целые романы между вашим кодом.

Держитесь подальше от следующего:

• Списки Todo
• Мертвый код закомментирован
• Комментарии в методах тела
• Более одного комментария на метод

Также полезно разбивать части методов с помощью метода extract и давать этой части метода имя, которое говорит нам об его ответственности, — вместо того, чтобы все детали загромождали понимание высокого уровня того, что происходит в теле метода.

Что легче читать? Ежу понятно конечно! Используйте бесплатный пробег, который вы получаете, называя вещи правильно с помощью извлеченных методов. Это делает ваш код намного умнее и легче усваивается, плюс, конечно, преимущества рефакторинга в одном месте при повторном использовании. Бьюсь об заклад, это поможет сократить ваши комментарии на очень значительную сумму.

Callbacks

Это простой. Не используйте обратные вызовы, которые не связаны с логикой постоянства! Ваши объекты имеют жизненный цикл постоянства — создание, сохранение и удаление объектов, так сказать, — и вы не хотите «загрязнять» эту логику другим поведением, таким как бизнес-логика ваших классов.

Сохраняйте это простым, помните? Типичными примерами того, чего следует избегать, являются отправка электронных писем, обработка платежей и прочее. Почему? Потому что отладка и рефакторинг вашего кода должны быть максимально простыми, а грязные обратные вызовы имеют репутацию вмешательства в эти планы. Обратные вызовы делают слишком легким замазывание воды и многократное попадание в ногу.

Еще один проблемный момент в отношении обратных вызовов заключается в том, что они могут скрыть реализацию бизнес-логики в таких методах, как #save или #create . Так что не ленитесь и ругайте их только потому, что это кажется удобным!

Конечно, самая большая проблема — это объединение проблем. Зачем, например, метод создания SpectreAgent иметь дело с доставкой #mission_assignment или чего-то еще? Как часто, просто потому, что мы можем сделать это — легко — не значит, что мы должны. Это гарантированный укус в задницу, ожидающий случиться. Решение на самом деле довольно простое. Если поведение обратного вызова не имеет ничего общего с постоянством, просто создайте для него другой метод, и все готово.

Плохие имена

Плохой выбор имени имеет серьезные последствия. По сути, вы напрасно тратите время других людей или, что еще лучше, свое собственное время, если вам придется пересматривать этот фрагмент кода в будущем. Код, который вы пишете, представляет собой набор инструкций, которые должны быть прочитаны вами и другими людьми, поэтому чисто логический, супер прозаический, слишком умный или, что еще хуже, простой ленивый подход к именованию вещей — одна из худших вещей, которую вы можете оставить позади. Стремитесь сделать ваш код легче для понимания, предоставляя лучшие имена.

Ясность превосходит ложную сообразительность или излишнюю лаконичность в любой день недели! Трудись по методам именования, переменных и классов, которые позволяют легко следовать какой-нить.

Я не хочу заходить так далеко, чтобы сказать, что вы должны стремиться рассказать историю, но если вы можете, сделайте это! Машины не являются теми, кто должен «читать» ваш код — они, конечно же, управляются ими. Может быть, это одна из причин, почему термин «Автор программного обеспечения» в последнее время немного растёт. Я не говорю, что инженерный аспект должен быть уменьшен, но написание программного обеспечения — это больше, чем написание бездушных инструкций для машин — по крайней мере, элегантного программного обеспечения, которое вызывает радость в работе.

Не волнуйтесь, если это окажется намного сложнее, чем вы думали. Обозначение, как известно, сложно!

Примеси

Mixins — это запах? Ну, скажем, они могут быть вонючими. Многократное наследование через Mixins может быть полезным, но есть пара вещей, которые делают их менее полезными, чем вы могли подумать, когда начинали с ООП:

• Их сложнее проверить.
• У них не может быть своего собственного государства.
• Они немного «загрязняют» пространство имен.
• Не всегда ясно, откуда взялась функциональность, поскольку она смешана.
• Они могут резко увеличить размер классов или количество методов. Правило маленьких классов, помнишь?

Я предлагаю вам немного прочитать « Композиция над наследованием ». Суть в том, что вам следует больше полагаться на повторное использование собственных, отдельно составленных классов, чем на наследование или создание подклассов. Миксины — это форма наследования, которая может найти хорошее применение, но также должна вызывать подозрения.

Скопления данных

Остерегайтесь повторной передачи одних и тех же нескольких аргументов в ваши методы. Это часто говорит о том, что у них есть отношения, которые могут быть извлечены в собственный класс, что, в свою очередь, может существенно упростить передачу данных этим методам за счет уменьшения размера аргументов. Стоит ли взвешивать, стоит ли вводить новую зависимость?

Этот запах — еще одна форма тонкого дублирования, с которой мы можем справиться лучше. Хорошим примером является передача длинного списка аргументов, которые составляют адрес и информацию о кредитной карте. Почему бы не упаковать все это в существующий класс или сначала извлечь новый класс и вместо этого передать объекты адреса и кредитной карты? Еще один способ думать об этом — иметь объект диапазона вместо начала и конца. Если у вас есть переменные экземпляра, которые соответствуют этому запаху, то извлечение класса стоит рассмотреть. В других случаях объект параметра может предлагать такое же качество абстракции.

Вы будете знать, что добились небольшого выигрыша, если ваша система будет проще для понимания, и вы обнаружите новую концепцию — например, кредитную карту — которую вы можете инкапсулировать в объект.

Последние мысли

Поздравляем! Вы значительно улучшили свои навыки ООП! Статус босса приближается. Нет, серьезно, отличная работа, если вся эта тема была для вас довольно новой!

В качестве последней рекомендации, я хочу, чтобы вы убрали одну вещь. Пожалуйста, помните, что не существует рецепта, который всегда будет работать. Вам нужно будет взвесить каждую проблему по-разному и часто смешивать различные методы в соответствии с вашими потребностями. Кроме того, на протяжении всей вашей карьеры, это, скорее всего, то, с чем вы никогда не перестанете бороться — я думаю, что это хорошая борьба, творческая и сложная.

Это небольшая догадка, но я чувствую, что если вы поняли большинство тем, которые мы затронули, вы сможете хорошо писать код, который любят находить другие разработчики. Спасибо за то, что уделили время прочтению этого небольшого сериала, и желаем удачи, став счастливым хакером!