개요

좋은 프로그램을 개발하는 것은 올바르지 못한 개발 방식을 피함으로부터 시작됩니다. 우리는 이를 안티 패턴이라 부릅니다. 오늘은 Anti patterns in software development 기사를 읽고 안티 패턴에 대한 여러 종류를 작성해볼 예정입니다.

이 포스트는 총 4가지 구성으로 되어 있는데 알아야 할 내용들에 대해서만 작성할 예정입니다.

Anti Pattern 종류

• Anti patterns in software development itself
• Anti patterns in software development processes
• Anti patterns in software architecture
• Anti patterns in software organisations

1. 소프트웨어 개발 간 발생하는 Anti-Pattern

Onion

기존에 남겨져 있는 레거시 코드를 개선하기 위해 추가 레이어를 구현해 이를 감싸는 행위를 Onion이라 부릅니다. 기존의 코드를 문제없이 사용할 수 있다는 점은 물론 좋지만 맨 처음에 있었던 레거시 코드를 계속해서 유지해야 되는 문제가 발생합니다.

Onion이 되기 이전에 내부 로직을 리팩토링하고 개선하는 습관을 기릅시다.

Boat anchor

현재 사용하고 있지 않지만 나중을 위해 남겨놓은 코드를 Boat anchor라 부릅니다. 종종 남겨놓은 코드가 필요해 사용할 경우 이는 유용할 수 있으나 남겨놓은 코드만드로 프로젝트의 무게가 커지는 문제가 발생합니다.
현재 프로젝트에서 이용하는 코드 이외의 모든 불필요한 코드는 복잡성을 증가시키고 가독성을 낮추니 제거합니다.

Dead end

최신화 하기 위해 최신 버전을 업데이트할 경우, 기존에 사용하던 종속성이 종종 사라지는 슬픈 문제가 발생합니다. 이런 경우에는 로직을 개선하기도 애매한 상황이어서 리소스 낭비가 발생합니다.

최대한 Deprecated 될만한 요소들은 사용하지 않고 릴리즈 버전을 읽어가며 무엇이 변경되었는지 확인하는 습관을 길러야 합니다.

Cut-and-Paste-Programming

이건 제가 자주하는 행동이자 큰 문제인데 복사-붙여넣기 프로그래밍입니다. 코드는 불필요하게 증가하며 개발 당시에는 생산성이 높았어도 전체적으로 보았을 경우 생산성은 감소하게 됩니다. 또한, 복붙한 내용이 결함이 있는 코드일 경우 모든 복붙한 부분에서 에러가 발생하니 기존 코드를 복사-붙여넣기 하는 방식은 최대한 지양합니다.

Kitchen sink

단일 클래스 혹은 인터페이스에서 너무 많은 기능을 가져 지나치게 복잡한 경우를 Kitchen sink라 부릅니다. 하나의 클래스로 가능한 모든 용도로 사용할 수 있도록 개발할 경우 다음과 같은 문제가 발생합니다.

• 문서화 및 유지보수의 어려움
• 디버깅의 어려움

결국 개발은 개발자가 하는 것이기 때문에 최대한 개발자가 읽을 수 있을 정도의 크기로 클래스를 구성하는 것이 바람직 합니다.

Golden Hammer

문제 해결에 있어 새로운 접근 방식을 배우거나 더 적합한 방법을 찾는 데 시간을 투자하지 않고 기존에 보편적으로 이용하는 기술을 이용하는 것을 Gold Hammer라 지칭합니다. 개발자는 항상 보편적인 해결 방안을 생각하지 않고 문제 해결에 있어 더 좋은 해결 방안에 대해 물색하고 도전 해야 합니다.
(공부는 덤)
대표적인 예시로서는 기존에 존재하던 Design Pattern에 대한 맹신이 있을 것 같습니다.(ex)싱글톤, 데코레이터 등등)

Continuous Obsolescence

개발자가 최신 버전을 따라가지 못할 경우 발생하는 문제를 Continuous Obsolescence라 지칭합니다. 최신 버전이 릴리즈 될 경우, 어떤 부분이 개선되었는지 확인하고 이용해보는 노력이 필요합니다.

2. 소프트웨어 개발 프로세스 Anti patterns

Not invented here syndrome

모든 것을 스스로 하는 습관은 대표적인 안티 패턴 중 하나입니다. 보편적으로 생성되어 있는 라이브러리들은 나보다 똑똑한 여러명의 개발자들이 고안해 낸 코드입니다.
따라서, 무언가를 하기 이전에 어떠한 프레임워크, 라이브러리 등이 있는지 한 번 조사해보고 이후에 문제 해결을 위해 코딩하는 것을 추천드립니다.

Hoarders

계속해서 Commit을 쌓아놨다가 한 번에 PR을 진행하는 코더들을 Hoarders라 부릅니다.
다른 사람이 내 코드를 보고 리뷰해주는 것을 두려워하지 말고 다른 사람이 집중할 수 있는 수준의 양을 가독성 있게 지속적으로 공유하는 능력을 길러야 합니다.

혼자만 코드를 가지고 있는 시간이 길어질수록 팀의 협업 또한 줄어든다는 것을 생각하며 최대한 공유하기 위해 노력합니다.

Byte nudging

해결해야 할 문제가 있는데 어떻게 해결해야될지 방법을 모를 경우 우리는 오랫동안 생각하고 고민합니다.
이것저것 깨작깨작 확인하며 수정만 하고 전반적인 시스템 구조를 이해하지 않은 채 내가 보고 있는 파일만을 집중해 바라봅니다. 우리는 이를 Byte nudging이라 부릅니다.

시스템의 큰 구조를 보고 계획을 세운 뒤 차근차근 해결해 나가는 마음가짐으로 문제 해결에 임했으면 좋겠습니다.

Bumble Bee

깊은 이슈까지 들어가지 않고 겉만 핥는 개발자들을 Bumble Bee라 부릅니다. 단기간에는 작은 변화에 있어 반영이 가능하겠지만 주요 변경사항 개발에 있어서는 취약한 모습을 보입니다.

성취감과 지속적으로 발전하는 개발자가 되기 위해서 무거운 주제 또한 해결하려는 의지를 보이고 도전해야 합니다.

Wave through

PR을 해주는 리뷰어로서 다른 사람의 코드 리뷰를 할 때 그냥 나쁘지 않네~ 하고 넘어간 경험이 있을겁니다. 저 또한 리뷰를 할 때 잘 모르는 도메인일 경우 그냥 approve한 적도 있었던 슬픈 추억이 있습니다..

코드 리뷰는 단순히 팀원의 코드를 확인하고 개선해주는 것이 아닌 협업과 지식의 교환, 학습의 장입니다. PR 리뷰에서 더 많은 것을 얻어갈 수 있도록 노력해야 됩니다.

좋은 코드를 경험하는 것 그 자체만으로도 한 단계 실력을 성장시킬 수 있는 밑거름이 됩니다. 귀찮다는 생각은 잠시 접어두고 어떤 문제 상황인지, 이 문제를 어떻게 해결해 나갔는지 분석하면서 배우고 의견을 공유하는 시간으로 생각하면 좋겠습니다.

Long running pull requests

오랜시간 동안 PR이 남아있는 경우 해당 PR은 항상 문제가 있음을 의미합니다. 리뷰어들의 시간이 없어서, 첫 pr에 대해 의견이 있거나 개선이 필요할 경우 PR은 계속해서 쌓이기 시작합니다.

이러한 쌓임은 결국 develop 브랜치에 pr 통합되는 일련의 과정을 점점 더 어렵게 만듭니다.

최대한 PR이 올라올 경우 해당 PR을 빠르게 처리할 수 있도록 모두가 노력해야 됩니다.

소프트웨어 아키텍쳐의 Anti Pattern

Inner platform effect

사용자 정의가 가능한 시스템을 만드는 경향이 있어 사용되고 있는 소프트웨어 개발 플랫폼의 복제본이 되는 경우가 존재하는데, 대부분 별로입니다.

한가지 예시로는 맨 처음부터 공통으로 사용할 수 있는 소프트웨어를 생각하며 개발을 진행하는 것입니다.
이러한 시스템은 종종 성능 문제가 발생해 나중에 가서야 문제를 인지할 수 있습니다. 다음과 같은 경우, 일반적인 솔루션을 도입하는 방향 고려해봐야 합니다.

Spaghetti code

스파게티 코드는 어디에서 시작해서 어디에서 끝나는지 모르는 복잡한 구조로 서비스가 얽히고 얽혔을 때 발생합니다. 하지만 이 서비스는 정상적으로 동작하고 있는 시스템입니다.

단지 "기능 동작"만을 위해 구현이 되었을 경우 다음과 같은 시스템을 만들 수 있는데 이럴 경우 유지 보수 및 테스트에 큰 어려움을 겪을 것입니다.

시작부터 명확한 디자인 패턴과 리팩토링된 구조화 된 소스 코드를 만들 수 있도록 노력해야 합니다.

소프트웨어 조직의 Anti Pattern

Warm body

Single head of knowledge

운영하고 있는 제품(서비스)에 대해 유일하게 아는 사람을 Single head of knowledge이라고 부릅니다. 팀에 이런 사람들이 존재할 경우, 그 사람이 회사를 떠날 때 큰 문제가 발생할 수 있습니다.(부사수 죽어난다...)

떠나시기 전에 최대한 페어 프로그래밍, 협업 등을 통해 Single head of knowledge한 사람의 지식을 빠르게 전수받아 단일 책임을 방지해야 합니다.

Yet another meeting will solve it

무언가 지연됐을 경우, 해당 문제를 해결하기 위해 회의를 잡습니다. 다른 회의를 잡을 시간에 함께 해결하도록 노력해야 합니다.

Management by numbers

창의적이고 예술적인 소프트웨어 개발의 큰 부분을 무시한채로, 숫자에 의해 관리를 하는 것을 의미합니다.
이는 결국 팀 뿐만 아니라 회사 자체를 소프트웨어 공장으로 만들 가능성이 있습니다.

Programmer interrupt

이메일, 슬랙, 질문, 회의 등등... 수많은 인터럽트들이 무언가에 집중 하려고만 하면 꼭 발생합니다. 엔지니어의 정신 집중을 높일 수 있도록 최대한 많은 인터럽트 요소들을 제거하고 개발에 집중해야 됩니다.

결론

포스팅 된 글을 읽다보니 제가 생각보다 많은 안티 패턴을 직접 하고 있었구나라는 생각이 들게 되었습니다.

내가 하는 안티 패턴들

• Wave through(PR 제대로)
• Byte nudging(나무가 아닌 숲을)
• Cut-and-Paste-Programming(복붙 X)

최대한 빨리 개선하는 개발자가 되겠습니다..

여러분도 다음 글을 읽어보시고 어떤 코딩 습관을 가지고 있고 버려야 하는지를 생각해보는 시간을 가지셨으면 좋을 것 같습니다.

Reference

Software development anti patterns. How to ruin your product.
Anti patterns in software development processes
Anti patterns in software architecture
Anti patterns in software organisations