Medium - What Makes Code Bad?
in Trend
Trend 파악을 Medium 기고문 요약 포스팅 - 무엇이 나쁜 코드를 만들까요? 나쁜 코드를 정의하지 못하면 여러분은 아마 그것을 고칠 수 없습니다.
@yungnoma unsplash.com
한번 생각해보세요: 여러분은 지연되고 있는 프로젝트의 한 파트에서 작업하고 있습니다. 한 주가 지연된 오늘, legacy 코드를 살펴보며 어떤 것이 완료되었나 알아보려고 합니다. 생각만으로 당신을 무섭게 만들 것입니다. 당신은 이전의 팀이 이 코드를 건드린지 일 년이 넘었다는 것을 알고 있습니다. 당신은 이 코드가 5 년은 지났다는 것을 알고 있습니다. 당신은 이 코드를 개선할 수 있다는 거슬 알고 있습니다. 예산은 정해져 있으므로 전체를 바꿔버리는 것 대신에 일부를 다시 사용하기로 결정했습니다. 그리고 여러분은 외국에 있습니다. 여러분을 기다리고 있는 것이 “Good Code” 이길 바라겠지만 당연히 95%확률로 “Bad Code” 라는 것을 알고 있습니다.
여러분은 고통을 줄이기 위해 첫 날부터 엄청난 커피로 시작합니다. 몇 분 이내로 여러분은 그냥 최악이라는 코드라는 놈과 마주하게 됩니다.
Spaghetti Code — by Jun Wu
세살베기 아이가 그린 그림과 비슷할 뿐만 아니라 아이가 가장 좋아하는 음식과도 닮았습니다.
정확하게 코드가 얼마나 나쁜지 식별하는 것으로 여러분은 관리자에게 새로 작성하는 것보다 고치는 것이 두 배는 오래 걸릴 것이라고 여러분의 의견을 피력할 수 있습니다.
Unreachable Code
이 코드는 로직이 변하지 않는 이상 절대 도달할 수 없는 코드입니다.
function {} {
return x;
z=a+b;
}
해결 : 없애세요.
Dead Code Including Lazy Classes
이 코드는 쓸데 없는 코드거나 아무것도 하지 않는 코드입니다.
function() {
a+b;
}
or
function() {
c=a+b;
c=a;
c=b+c;
}
해결 : 로직을 새로 짜거나 없애세요.
Large Classes
한 클래스의 로직을 알아내는데 20분이 걸린다면 도랑으로 빠질 때 입니다. 코드가 몇 줄이ㅏ 되죠? 아마 전 챕터를 읽는 것 같을 것입니다.
해결 : 리팩토링 하세요.
Circular References That Lead to a God Object
이 코드들은 코너를 순회하다 같은 목적지로 돌아옵니다. 이런 코드들은 God Object(너무 많이 알거나 너무 많이 하는)를 만들 수 있습니다. 그것은 단순히 패턴을 파괴하는 예입니다.
Image from Wikipedia
해결 : 코드를 리팩토링하거나 디자인을 독립된 그룹으로 분리하십시오.
Speculative Generality
미래에 일어날 것이라고 추측해서 누군가가 설정한 기능이 절대 사용되지 않을 때,
해결 : 없애세요.
Hard-Coding
이것은 가장 쉬운 지점이고 예방하기도 쉽습니다. 값을 변경할 때마다 코드를 밬꿔야 할 것입니다. anti-패턴으로 간주됩니다. 일반적으로 프로젝트에 사용자가 값을 입력할 수 있는 동적 솔루션을 추가할 때까지 일시적으로 사용됩니다.
해결 : 값을 변화시킬 수 있는 동적 인터페이스를 만드세요.
Magic Number
그냥 보여지고 바로 사용되는 숫자
function(){
for(int i=0; i<10; i++) {
}
}
이 경우에 10이 매직 넘버가 됩니다. 해결 : 10을 변수로 대체하고 10으로 초기화 하세요.
Long If(Condition)
이것은 if 구문이 너무 길거나 여러줄이 단순한 로직을 수용하기 위해 사용됩니다.
if(get_data(data)=success || (reuse(data)&&cut_data(data)==success)||(reuse_again(data) && cut_data(data)==success))
해결 : 특정 프로그래밍 언어에서 긴 if 구문을 사용할 때 제시하는 가이드를 준수하십시오.
Sequential Coupling
메소드가 특정한 순서에 따라 호출되어야 할 때 입니다. 예를 들어 begin 메소드를 start 메소드 전에 호출해야 하고 그 전에 drive 메소드를 호출해야 합니다.
해결 : 템플릿 메소드 패턴을 사용하세요
Overuse of Inheritance
지나친 상속은 객체지향 프로그램에서 결합도를 증가시키고 코드를 유연하지 않게 만듭니다. 당신은 대신에 composition에 집중할 수도 있습니다.
여기에 괜찮은 예제가 있으니 확인해보세요.
Not Using Core Programming Language Features
이것은 명백한 것은 아닙니다. 그러나 특정 프로그래밍 언어를 프로젝트에 선택한 이유가 분명히 있습니다. 파이썬에서 좋은 예는 간단한 작업을 위해선 list comprehension보다 반복문을 사용하는 것입니다.
Overly Complex Comments
만약 코멘트가 큰 블록안에 들어있거나 지나치게 복잡하다면 코드가 리팩토링이 필요하다는 경고 문입니다.
해결 : 메소드나 변수를 추출하여 리팩토링 합니다.
Message Chain
메시지 체인은 선생님이 Toddler A에게 얘기하고 Toddler A는 Toddler B에게 얘기하고.. 선생님은 클라이언트 입니다. Toddler는 체인의 오브젝트 들입니다. 문제는 이런 관계의 변화가 있다면 클라이언트의 변경이 필요하다는 것입니다.
해결 : hide delegate를 이용해 리팩토링 합니다.
Data Clumps
이 것은 다른 영역의 코드가 같은 그룹의 변수들을 갖는 것입니다. 고전적인 한 예는 서비스에 여러번 연결하기 위해 매개변수를 찾는 경우 입니다.
해결 : 객체의 새로운 매개변수를 만들거나 클래스 추출을 만들어서 리팩토링 합니다.
Conclusion
나쁜 코드들을 살펴봤으니 이제 좋은 코드를 정리해봅시다.
@safesolvent unsplash.com
- 좋은 코드는 잘 구성되어 있고 테스트하기 쉬우며 간단하고 직관적입니다.
- 좋은 코드는 우아하고 쉽게 설명할 수 있고 어린이들한테도 설명하기 쉬운 로직입니다.
- 좋은 코드의 얘기는 누구에 의해서라도 얘기될 수 있습니다. 여러분의 프로그래머는 좋은 코드를 작성하기 위해 로켓 과학자가 될 필요가 없습니다.
- 가장 중요하게도 좋은 코드는 계속 살아있는 것입니다.
Summary
- 나쁜 코드의 전형적인 패턴과 좋은 코드의 사례
- 어려운 경우가 아니더라도 최소한 매직넘버나 Long If, Unreachable Code 들은 작성하지 않도록 주의하자.
