Антишаблоны, которых следует избегать в своем коде

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

Но мы все еще можем найти антипаттерны в программном обеспечении, которое было написано какое-то время или было написано слишком быстро.

Безобидный базовый прием для быстрого решения проблемы может создать прецедент в вашей кодовой базе. Его можно скопировать в нескольких местах и ​​превратить в анти-шаблон, который вам нужно решить.

Так что же за антипаттерн?

В программном обеспечении антипаттерн - это термин, который описывает, как НЕ решать повторяющиеся проблемы в вашем коде. Антишаблоны считаются плохим дизайном программного обеспечения и обычно являются неэффективными или неясными исправлениями.  

Как правило , они также добавить «технический долг» - который является код , который вы должны вернуться и исправить правильно позже.

В этой статье я расскажу о шести антипаттернах: код спагетти , золотой молот , якорь для лодки , мертвый код , распространение кода и объект Бога .

Код спагетти

Код спагетти - самый известный антипаттерн. Это код с практически нулевой структурой.

Ничего не модулируется. Случайные файлы разбросаны по случайным каталогам. За всем потоком трудно проследить, и он полностью сплетен (как спагетти).

Обычно это проблема, когда кто-то заранее не продумал досконально ход своей программы и только начал кодировать.

Что оно делает?! Я не могу следить за этим

image.png

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

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

Вы можете узнать больше об анти-шаблоне Spaghetti Code .

Золотой молот

«Полагаю, это заманчиво, если единственный инструмент, который у вас есть, - это молоток, - обращаться со всем так, как если бы это был гвоздь». Авраам Маслоу

Представьте со мной сценарий: ваша команда разработчиков очень и очень компетентна в новой архитектуре Hammer. Это фантастически сработало для всех ваших прошлых проблем. Вы - ведущая в мире команда архитекторов Hammer.

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

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

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

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

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

Вы можете узнать больше об анти-шаблоне Golden Hammer .

Якорь лодки

Лодка Якорь антишаблоном где программисты оставить код в коде , потому что они , возможно , понадобятся позже.

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

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

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

И последняя проблема: устаревший код увеличивает время сборки, и вы можете перепутать рабочий и устаревший код. Вы даже можете начать непреднамеренно "включить" в продакшене.

Теперь вы, вероятно, понимаете, почему это называется антипаттерном «якорь лодки» - его тяжело носить (добавляет технический долг), но ничего не делает (буквально, код бесполезен, он не работает).

Вы можете прочитать больше об анти-образце якоря лодки .

Мертвый код

Приходилось ли вам когда-нибудь смотреть на код, написанный кем-то, кто больше не работает в вашей компании? Есть функция, которая ничего не делает. Но звонят отовсюду! Вы спрашиваете у всех, и никто не знает, что он делает, но все слишком обеспокоены, чтобы удалить его.

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

This is commonly described as the Dead code anti-pattern. When you can't see what is "actual" code necessary to the flow and successful execution of your program, versus what was only needed 3 years ago, and not now.

This particular anti-pattern is more common in proof on concept or research code that ended up in production.

One time at a tech meet up I met a guy who had this exact problem. He had tons of dead code, which he knew was dead, and lots he suspected was dead. But he could not get permission from management to ever remove all the dead code.

He referred to his approach as Monkey testing, where he started to comment out and turn off things to see what blew up in production. Maybe a little too risky!

If you don't fancy Monkey testing your production app, try to frame technical debt to management as "technical risk" to better explain why you think it's so important to tidy up.

Or even write down everything your particular module/section does you want to re-write, and take an iterative approach to remove piece by piece the dead code. Checking every time you haven't broken anything.

You don't have to drop a huge rewrite with thousands of changes. But you will either understand why it's so crucial and document why it's needed, or delete the dead code as you desired.

You can read more here about the Dead code anti-pattern.

Proliferation of Code

Objects or modules regularly communicate with others. If you have a clean, modularised codebase you often will need to call into other separate modules and call new functions.

The Proliferation of Code anti-pattern is when you have objects in your codebase that only exist to invoke another more important object. Its purpose is only as a middleman.

This adds an unnecessary level of abstraction (adds something that you have to remember) and serves no purpose, other than to confuse people who need to understand the flow and execution of your codebase.

A simple fix here is to just remove it. Move the responsibility of invoking the object you really want to the calling object.

You can read more here about the Proliferation of Code anti-pattern.

God Object

If everywhere in your codebase needs access to one object, it might be a God object.

God objects do too much. They are responsible for the user id, the transaction id, the customer's first and last name, the total sum of the transaction, the item/s the user is purchasing...you get the picture.

It is sometimes called the Swiss Army Knife anti-pattern because you only really need it to cut some twine, but it also can be a nail file, saw, pair of tweezers, scissors, bottle opener and a cork screw too.

In this instance you need to separate out and modularise your code better.

Programmers often compare this problem to asking for a banana, but receiving a gorilla holding a banana. You got what you asked for, but more than what you need.

The SOLID principles explicitly discuss this in object orientated languages, to help us model our software better (if you don't know what the SOLID principles are, you can read this article).

The S in the acronym stands for Single Responsibility - every class/module/function should have responsibility over one part of the system, not multiple.

You can see this problem over and over again, how about the below interface?

interface Animal { numOfLegs: string; weight: number; engine: string; model: string; sound: string; claws: boolean; wingspan: string; customerId: string; } 

Can you see by even just briefly scanning this interface that the responsibility of this is far too broad, and needs refactoring? Whatever implements this has the potential to be a God object.

How about this?

 interface Animal { numOfLegs: string; weight: number; sound: string; claws: boolean; } interface Car { engine: string; model: string; } interface Bird { wingspan: string; } interface Transaction { customerId: string; } 

Interface segregation will keep your code clear about where the responsibilities lie, and stop forcing classes that only need wingspan to also implement the engine, customerId and model  and so on.

Вы можете прочитать больше об анти-шаблоне объекта Бог .

Вывод

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

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

Я поделюсь своим письмом в Твиттере, если вам понравилась эта статья, и вы хотите увидеть больше.