모든 개발자는 구조화되고 단순하게 계획되고 잘 설명 된 코드를 작성하기를 원합니다. 따라야 할 명확한 규칙과 염두에 두어야 할 프레임 워크를 제공하는 수많은 디자인 패턴도 있습니다.

그러나 우리는 시간이 지남에 따라 작성되었거나 너무 빨리 작성된 소프트웨어에서 여전히 안티 패턴을 찾을 수 있습니다.

문제를 빠르게 해결하기위한 무해한 기본 해킹은 코드베이스에서 선례를 만들 수 있습니다. 여러 장소에 걸쳐 복사 할 수 있으며 해결해야하는 안티 패턴으로 바뀔 수 있습니다.

그래서 안티 패턴이란 무엇입니까?

소프트웨어에서 안티 패턴은 코드에서 반복되는 문제를 해결하지 않는 방법을 설명하는 용어입니다. 안티 패턴은 잘못된 소프트웨어 디자인으로 간주되며 일반적으로 효과가 없거나 모호한 수정입니다.  

또한 일반적으로 "기술적 부채"를 추가합니다.이 코드는 나중에 돌아와서 올바르게 수정 해야 합니다.

이 기사에서 논의 할 6 가지 안티 패턴은 Spaghetti Code , Golden Hammer , Boat Anchor , Dead Code , Proliferation of Code 및 God Object 입니다.

스파게티 코드

스파게티 코드 는 가장 잘 알려진 안티 패턴입니다. 구조가 거의 0 인 코드입니다.

모듈화 된 것은 없습니다. 임의의 디렉토리에 흩어져있는 임의의 파일이 있습니다. 전체 흐름을 따라 가기가 어렵고 스파게티처럼 완전히 얽혀 있습니다.

일반적으로 이것은 누군가가 미리 프로그램의 흐름을 신중하게 생각하지 않고 방금 코딩을 시작한 문제입니다.

그것은 무엇을합니까?! 나는 이것을 따를 수 없다

이것은 유지 관리의 악몽 일뿐만 아니라 새로운 기능을 추가하는 것을 거의 불가능하게 만듭니다.

그러한 고고학 / 추측 작업을 할 때 발생하는 수많은 문제를 예견하는 것이 불가능하기 때문에 끊임없이 일을 깨뜨 리거나 변경 범위를 이해하지 못하거나 작업에 대한 정확한 추정치를 제공합니다.

스파게티 코드 안티 패턴 에 대한 자세한 내용은 여기에서 확인할 수 있습니다 .

황금 망치

"당신이 가진 유일한 도구가 망치라면 모든 것을 못처럼 취급하는 것이 유혹적 일 것 같습니다." 아브라함 매슬로

저와 함께 한 시나리오를 상상해보십시오. 여러분의 개발 팀은 새로운 Hammer 아키텍처에 대해 매우 능숙합니다. 과거의 모든 문제에 대해 환상적으로 작동했습니다. 당신은 세계 최고의 Hammer 아키텍처 팀입니다.

하지만 이제는 모든 것이 항상이 아키텍처를 사용합니다. 납작 머리 나사? 망치. 십자 나사? 망치. 앨런 렌치가 필요하세요? 아니, 망치지 마.

당신은하지 않는 건축 방식 적용하기 시작 확실히 당신이 필요에 맞게하지만 일을 얻을 수 있습니다. 한 가지 패턴에 지나치게 의존하고 있으며 최상의 작업을위한 최상의 도구를 배워야합니다.

사각형을 원 모양으로 만들려고하기 때문에 전체 프로그램이 성능에 심각한 타격을 줄 수 있습니다. 이 문제에 대해 해머 아키텍처를 사용하여 코드를 작성하고 프로그램을 실행하는 데 두 배의 시간이 걸린다는 것을 알고 있지만 더 쉽고 편합니다 .

또한 예측할 수 없습니다. 다른 언어에는 직면 한 문제와 자체 표준에 대한 공통적 인 수정 사항이 있습니다. 한 언어로 잘 작동하는 모든 규칙을 문제없이 다음 언어로 적용 할 수는 없습니다.

커리어에서 지속적으로 배우는 것을 소홀히하지 마십시오. 문제에 맞는 언어를 선택하십시오. 건축에 대해 생각하고 안락한 영역을 넓히십시오. 새로운 도구와 직면 한 문제에 접근하는 새로운 방법을 조사하고 조사하십시오.

Golden Hammer 안티 패턴 에 대한 자세한 내용은 여기에서 읽을 수 있습니다 .

보트 앵커

보트 앵커 있기 때문에 프로그래머들이 코드베이스에 코드를 떠날 경우 안티 패턴은 그들이 나중에 필요할 수 있습니다.

그들은 사양을 약간 벗어난 코드를 작성했으며 아직 필요하지 않지만 다음 달에 그렇게 될 것이라고 확신합니다. 그래서 그들은 그것을 삭제하고 싶지 않습니다. 프로덕션으로 전송하고 나중에 필요할 때 신속하게 작동시킬 수 있습니다.

그러나 이것은 쓸모없는 코드를 모두 포함하는 코드베이스에서 유지 관리 악몽을 유발합니다. 가장 큰 문제는 동료들이 사용하는 코드와 비교하여 어떤 코드가 쓸모없고 흐름을 변경하지 않는지 파악하는 데 어려움을 겪을 것이라는 점입니다.

당신이 핫 픽스를하고 있고 은행에서 자금을 인출하기 위해 고객의 카드 세부 정보를 API로 보내는 책임이 무엇인지 필사적으로 조사하고 있다고 상상해보십시오. 코드베이스에서 올바른 위치에 있지 않다는 사실을 깨닫지 못하고 쓸모없는 코드를 읽고 디버깅하는 데 시간을 낭비 할 수 있습니다.

마지막 문제는 쓸모없는 코드로 인해 빌드 시간이 길어지고 작업 코드와 쓸모없는 코드가 섞일 수 있다는 것입니다. 프로덕션에서 실수로 "켜기"시작할 수도 있습니다.

이제 보트 앵커 안티 패턴이라고 불리는 이유를 알 수있을 것입니다. 휴대하기는 무겁지만 (기술적 인 부채를 추가) 아무것도하지 않습니다 (말 그대로 코드는 목적이없고 작동하지 않습니다).

보트 앵커 방지 패턴 에 대한 자세한 내용은 여기에서 읽을 수 있습니다 .

데드 코드

Have you ever had to look at code written by someone who doesn't work at your company any longer? There's a function that doesn't look like it is doing anything. But it is called from everywhere! You ask around and no-one else is quite sure what it's doing, but everyone's too worried to delete it.

Sometimes you can see what it's doing, but the context is missing. You are able to read and understand the flow, but why? It doesn't look like we need to hit that endpoint anymore. The response is always the same response for every different user.

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.

여기에서 신 개체 안티 패턴 에 대해 자세히 읽을 수 있습니다 .

결론

대규모 코드베이스에서는 기술 부채 관리, 새로운 개발 시작 및 제품의 버그 대기열 관리 사이에 일정한 균형이 있습니다.

이 기사가 안티 패턴의 래빗 홀 아래로 내려갈 때를 발견하고이를 깨끗하게 해결하는 몇 가지 도구를 제공했기를 바랍니다.

이 기사를 즐겼고 더보고 싶다면 트위터에 글을 공유합니다.