6 типов антипаттернов, которых следует избегать при разработке программного обеспечения
Этот блог предназначен для всех тех разработчиков, которые начали прятать лица перед старшими инженерами, когда их поймали с поличным из-за беспорядка, который они создали в кодовой базе. Это привело к появлению множества ошибок в производственной среде, и все программное обеспечение стало кошмаром для других разработчиков.
Почему возник беспорядок?… Только разработчик, создавший беспорядок, может объяснить причину. Может быть, когда-нибудь он / она будет в другом настроении и станет ленивым в удалении ненужного фрагмента кода из файла, может быть, это было давление крайних сроков, или, может быть, он был просто еще одним парнем / девушкой, которые вошли в разработку и не смогли применить лучшее кодирования из-за недостатка знаний в нем.
Когда разработчик пишет чистый, хорошо структурированный, документированный, хорошо прокомментированный и просто спланированный код, он удовлетворяется им. Вы увидите улыбку на их лице, увидев самый элегантный код, который они только что написали в базе кода.
Они следуют некоторым шаблонам проектирования и используют фреймворк для ускорения процесса разработки, они также следуют некоторым лучшим практикам кодирования, чтобы сделать свой исходный код гибким, многоразовым и поддерживаемым. Но даже после всего этого вы можете обнаружить наличие антипаттернов в их программном обеспечении, которое было написано месяц назад или было написано слишком быстро из-за давления крайних сроков.
Если вы занимаетесь разработкой программного обеспечения, то наверняка вам нужно было быстро исправить некоторые ошибки. Вы попробовали базовый прием (простое решение), вы реализовали его, он сработал, и вы скопировали этот фрагмент кода в нескольких местах, чтобы исправить ту же ошибку. Проблема была решена, но вы допустили одну ошибку и создали антишаблон в своем программном обеспечении. Можете ли вы представить, что эта ошибка может создать еще одну проблему? Или это может вызвать еще одну ошибку в вашем программном обеспечении?
Надеюсь, вы поняли нашу точку зрения и поняли значение антипаттерна в разработке программного обеспечения. В этом блоге мы подробно обсудим эту тему и обсудим различные типы антипаттернов в разработке программного обеспечения. Начнем сначала с краткого введения ...
Что за антипаттерн?
Вы могли понять значение анти-паттерна из всех вышеперечисленных обсуждений, которые мы провели. Антипаттерн - это противоположная сторона паттерна проектирования. Вы также можете назвать это запахом дизайна, который вызван плохим дизайном программного обеспечения. Обычно это неэффективные или непонятные исправления. Наличие анти-шаблона в вашем коде может создать множество ошибок, и вам, возможно, придется позже исправить его должным образом.
Антипаттерны плохо влияют на ваше программное обеспечение и добавляют «технический долг» - дополнительную работу для вас ( и, конечно же, головную боль ). Давайте обсудим шесть наиболее распространенных типов антипаттернов и способы их решения при разработке программного обеспечения.
1. Код спагетти
Это один из наиболее распространенных типов антишаблонов, которые вы встретите при разработке программного обеспечения. Вы пишете код, реализуете некоторые функции, это работает, и вы продолжаете внедрять несколько других функций в свое программное обеспечение, но вы не обращали внимания на соглашения о кодировании или не делали его более чистым.
Теперь просто наблюдайте за всей структурой вашего кода, наблюдайте за полным потоком вашего программного обеспечения. Как это выглядит ?? Разве это не грязно ?? Разве файл и функции не расположены случайным образом здесь и там?
По мере роста вашей программы вы получите набор функций, случайным образом размещенных в разных файлах. Нет ничего модульного, вы будете копировать и вставлять строки кода снова и снова. Вы вносите изменения в одну функцию, а затем несколько других функций перестают работать. Это называется спагетти-кодом.
Все приложение превращается в большой комок грязи, который вы больше не можете реорганизовать, и вам, возможно, придется решить его переписать. Вы увидите неряшливую структуру без комментариев к кодированию, статические переменные / функции повсюду, несколько раз перегруженный метод и тысячи строк кода без соглашений о кодировании.
Действительно неприятно работать над проектом, в котором функции, файлы, изображения и некоторые другие части проекта не организованы. Полный поток и структура становятся беспорядочными. Обычно это случается, когда разработчики не особо задумываются о поддержании чистой структуры программного обеспечения. Они сразу же начинают писать код, не обращая внимания на ход программы.
Другим разработчикам сложно добавить в него функционал. Вся программа для них ужасна, и чтобы поработать с ней, им нужно сначала организовать все в коде. Это может привести к поломке некоторых вещей в программном обеспечении, а также станет трудно понять масштаб изменений.
2. Золотой молот
Разработка программного обеспечения - это область, в которой неважно, что если решение или шаблон сработали для одной проблемы, то они будут работать и для других проблем. Если решение подходит для проблемы A, проблемы B и проблемы C, то не обязательно, чтобы оно подходило для проблемы D.
Представьте себе сценарий, в котором вы работаете над проектом, адаптировали новое решение, совершенно новую архитектуру, и эта новая архитектура решает весь ваш прошлый набор проблем. Теперь вы попробовали эту новую архитектуру для другого набора проблем ... и вуаляаа, это сработало и для этого. Теперь вы обретаете уверенность в себе и начинаете пытаться приспособить его везде, но ... подождите, вы обнаружите, что это не работает для проблем XYZ. Вот что такое золотой молоток или серебряная пуля.
Золотой молоток может вызвать множество проблем в вашем коде. Выбранное решение может быть неэффективным решением вашей проблемы, и ваш код также может превратиться в слишком сложный код.
Помните, что при разработке программного обеспечения каждый шаблон проектирования, каждая структура или языки подходят для определенного типа проблемы. Вы не можете приспособить его везде. Зачем вы хотите вписать задачу D в свою любимую архитектуру, если перед вами плачут, что она мне не подходит?
Если вы превратите квадрат в круг, производительность вашего программного обеспечения снизится. Просто потому, что вам удобен определенный подход, и вам легче не пытаться решать все виды проблем с помощью одного и того же подхода или шаблона.
Выберите правильный набор инструментов , языков, фреймворков, шаблонов или архитектуры для конкретной проблемы. Всегда имейте несколько решений ( как минимум два) для одной проблемы. Обратите внимание на плюсы и минусы каждого из них, а затем выберите лучший.
3. Якорь лодки
Если вы занимаетесь разработкой программного обеспечения, то наверняка предсказывали, что что-то реализуете в будущем. Что, если мне понадобится реализовать функцию XYZ в будущем? Что, если это произойдет в моем коде ??
Приведенный выше вопрос «что, если» вынуждает вас добавить в вашу программу несколько дополнительных строк кода, которые сейчас не нужны. Вот что такое анти-шаблон якоря лодки в программном обеспечении. Этот антишаблон существует в коде, когда программисты оставляют фрагмент кода в кодовой базе, думая, что он может им понадобиться позже .
Вы пишете какой-то фрагмент кода, который не упоминается в текущем требовании, но вы уверены, что он вам понадобится, может быть, в следующем месяце или, может быть, через два месяца. Вы не удалите это. Вы думаете, что сразу заставите его работать, когда в будущем вас попросят его реализовать.
Это просто создает еще один антишаблон в вашем программном обеспечении. Ваши коллеги смотрят на код и пытаются понять, что именно этот конкретный фрагмент кода делает в кодовой базе. Конечно, это просто трата времени на чтение и отладку ненужных строк кода.
Проще говоря, лодка , якорь обозначают одно - тяжело нести (устаревший код, который бесполезен, бесполезен , ничего не делает в коде и добавляет технический долг).
4. Мертвый код
Мертвый код похож на Якорь лодки. Вспомните время, когда вам дали проект с большим количеством файлов, сохраненных в разных каталогах. Вы открываете один файл, видите, что там несколько строк кода, вы тестировали каждую функцию, модули и файлы, чтобы определить, что они делают в проекте, и нашли функцию, которая не выглядит так, как будто она что-то делает. Вы пытаетесь определить, почему она вызывается отовсюду, вы просите членов своей команды знать цель этой функции, но никто не уверен, что она делает.
Эту функцию оставил бывший инженер, который работал в вашей компании несколько месяцев назад. Все слишком беспокоятся, чтобы удалить эту функцию. Иногда вы видите, что он делает, но не хватает контекста. Вы понимаете поток, но похоже, что эта функция больше не требуется в вашем файле. Этот тип анти-паттерна известен как мертвый код. Как следует из названия, он ничего не делает в вашем коде.
Мертвый код - это в основном фрагмент кода в файле, который был написан пару лет назад для создания некоторой функциональности, но теперь он больше не нужен. Ваша программа нигде не завершится, если эта функция будет полностью удалена.
Полностью удалить мертвый код будет рискованно. Вы можете провести тестирование на обезьянах, если не хотите удалять мертвый код. Закомментируйте этот фрагмент кода, отключите все и посмотрите, что происходит в производственной среде. Вы также можете использовать итеративный подход для удаления кода по частям из своей кодовой базы. Продолжайте проверять функциональность своего программного обеспечения, чтобы убедиться, что вы ничего не сломали.
5. Бог-объект и бог-класс
Есть ли в вашем коде какой-либо объект или класс, который выполняет слишком много действий? Этот класс или объект отвечает за слишком много вещей. Имя пользователя, фамилия, идентификатор пользователя, идентификатор транзакции, общая сумма транзакции, список товаров, которые пользователь покупает, и т. Д.
Типичный бог-класс / объект-бог берет на себя много обязанностей и много зависимостей. Класс Бога контролирует многие другие классы. Если большая часть кода нуждается в доступе к одному объекту, то этот объект может быть божественным объектом.
Этот антипаттерн нарушает принцип «единой ответственности». Можете ли вы представить сценарий, в котором вы реализовали класс, вы начинаете добавлять в него что-то (потому что вам было лень создать другой класс), вы продолжаете это делать, этот класс со временем рос, весь другой фрагмент кода обращается к этому классу и однажды вы обнаружили, что его стало трудно поддерживать.
Эта ситуация может стать кошмаром для многих разработчиков. Бог-классы сложно тестировать, поддерживать, отлаживать и документировать. Возможно, вы начали разрабатывать свое приложение без класса бога, но когда требования добавляются и размер команды растет день ото дня, один четко определенный класс в какой-то момент превращается в классы богов.
Чтобы решить эту проблему, вам нужно лучше разделить и разбить код на модули. Иногда программисты сравнивают это с очень забавным примером. Вы просите банан, но вы получили гориллу, держащую банан. Вы получили то, что хотели, но больше, чем вам было нужно.
Ниже приведен пример интерфейса, в котором слишком много информации…
interface Car {
carName: строка;
двигатель: строка;
модель: струна;
год: номер;
numOfLegs: строка;
вес: число;
звук: струна;
когти: логическое;
размах крыльев: тетива;
customerId: строка;
}Четко соблюдайте приведенный выше интерфейс. Вы можете видеть, что в нем слишком много информации. Так много обязанностей делают его слишком широким и требует рефакторинга. Это объект Бога. Ниже приведено решение указанной выше проблемы ...
interface Car {
carName: строка;
двигатель: строка;
модель: струна;
год: номер;
}
interface Animal {
numOfLegs: строка;
вес: число;
звук: струна;
когти: логическое;
}
interface Bird {
размах крыльев: тетива;
}
interface Transaction {
customerId: строка;
}Следуйте принципу единой ответственности и разделения интерфейсов, чтобы решить эту проблему. Кроме того, не забывайте регулярно проверять код и выявлять технические долги.
6. Копирование и вставка программ
Вы можете легко найти пример этого анти-паттерна при проверке кода младшими разработчиками или стажерами. Младшим разработчикам или стажерам не хватает опыта разработки, и они сталкиваются с трудностями при создании некоторых функций или написании кода с нуля. Они пытаются скопировать и вставить код из некоторых ресурсов, таких как StackOverflow, Github, или из других блогов или видео. Они копируют и вставляют эти коды в свой собственный файл без какого-либо тестирования или анализа воздействия.
Этот анти-шаблон действует как вирус в вашем программном обеспечении, и для решения этой проблемы вам необходимо изменить код везде, где он был скопирован. Это происходит из- за плохого понимания основ, таких как структуры циклов, функции и подпрограммы.
Вы можете избежать этого антипаттерна часто и тщательно проверяя код. Код следует тщательно протестировать, а также проанализировать влияние, если вы реализуете это в своей программе. Он должен быть тщательно рассмотрен и одобрен старшими разработчиками в команде. Кроме того, проведите рефакторинг кода, чтобы абстрагировать каждое появление в одной функции или методе.
Заключение
Не паникуйте и не считайте себя плохим разработчиком, если вы видите в своем коде антипаттерн. Ошибки ведут к улучшению. Для большинства антипаттернов в программном обеспечении вы найдете общее решение для всех, а именно… анализ кода и рефакторинг кода. Надеюсь, эта статья была полезна для вас, чтобы собрать некоторую информацию об антипаттернах.
Если вы хотите узнать больше о рефакторинге кода, ниже приведены несколько полезных ссылок ...
- 7 причин, почему рефакторинг кода важен в разработке программного обеспечения
- 7 методов рефакторинга кода в программной инженерии