Что за зверь: анти-паттерны — часть 3

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

Программирование копипастом

Copy and Paste Programming — это, наверное, самый древний из анти-паттернов. Он проявляется в ситуациях, когда необходимо написать две функции, и разработчик не придумывает ничего лучше, как написать одну и скопировать ее. Да, он вносит во вторую некоторые изменения, в разной степени позволяющие ей соответствовать требованиям, но часто в этом есть свои нюансы. Подобная ситуация часто возникает в спешке, с горящими сроками, недосыпами и прочими прелестями жизни. В таком режиме очень легко что-то пропустить, забыть и не довести до ума. А такие скопированные кусочки — лучшее поле для подобных промашек. Программисты забывают вносить изменения, которые подгонят копипаст под требования. Другая ситуация — баг в оригинальном коде, который вы решили скопировать. Таким способом вы можете разнести «заражение» по нескольким проектам. Из-за этого усложняется поддержка и code review.

Как выпускникам IT-курсов избежать жесткого кодирования

Анти-паттерн Hard Code предусматривает, что программист будет добавлять в проект данные об окружении. Жестко прописанные значения имеют что-то общее с анти-паттерном «магические числа». Добавлять что-то вроде путей к файлам, имена устройств, процессов и прочего — не лучшая идея. Такой код предельно сложно переносить, так как он может исправно функционировать исключительно на машине автора, и то до переименования объектов или их переноса. Когда возникает необходимость отладить материал, возникает очередная проблема — найти места с жестким кодом достаточно сложно, поэтому исправление может занять неоправданно много времени. Тем не менее, подобных ситуаций легко избежать — еще до начала работы прописать запрет на Hard code и ответственно проводить code review. Если это ваш первый проект и вы все еще учитесь на IT-курсах в EasyCode, можно спросить совета у преподавателя. Наши менторы с радостью поделятся своим опытом и ответят на вопросы.

Лодочный якорь в IT

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

Изобретение велосипеда в программировании

Reinventing the wheel — это противоположность программированию копипастом. Разработчик создает решения, которые уже существуют на площадках с открытым кодом. Часто уже готовые варианты будут лучше, чем то, что придумает программист в рамках времени до дедлайна. Не стоит расстраиваться, если это оказывается правдой — на площадках с открытым кодом все способы перепроверены сотни раз, над ними поработало очень много программистов (возможно, более опытных), которые улучшили все, что только возможно. Изобретение велосипеда приводит к снижению качества кода и эффективности работы, ведь разработчик может создать неоптимальное решение или вовсе не справиться с задачей. Пользуясь готовыми способами важно не скатываться в программирование копипастом. Нельзя полностью отказывать себе в шансе побороть проблему ручками. В том числе и об этом рассказывают на онлайновых IT-курсах в EasyCode.

Изобретение одноколесного велосипеда

Анти-паттерн Reinventing the square wheel очень похож на прошлый пункт, но с плохим исходом. То есть, для проекта необходимо определенное решение и разработчик создает его, но плохо. При этом хороший вариант уже существует и успешно используется тысячами других людей. Опасность такого сценария — потеря времени и сил, помноженная на два. То есть, сначала создается что-то непригодное, а после прилагаются усилия на рефакторинг и замену подходящим материалом.

Подводя итоги серии из трех статей можно сказать, что анти-паттерны являются главными врагами программиста. Они приходят в жизнь разработчика во времена нехватки опыта/профессионализма или при нехватке времени. Спешка часто лишает проект качественного планирования, code review и других полезных вещей. Стоит помнить о стандартных ошибках и искоренять их еще на этапе намерения, иначе есть риск получить неработоспособную систему. Поэтому, если у вас есть возможность влиять на сроки, справедливо оценивайте сложность и закладывайте время на все нюансы. Поучиться этому можно во время выполнения домашних заданий и курсовых работах курсов по frontend в Харькове и онлайн.

Заметили ошибку? Выделите ее и нажмите Ctrl+Enter, чтобы сообщить нам.

04.03.2019
148
Автор: Ася Яскер