개발자

“몰래 하는 맛” 비밀스럽게 즐기는 10가지 나쁜 프로그래밍 습관

Peter Wayner | InfoWorld 2019.12.09


물론 변환을 최소화하도록 모든 코드를 다시 쓸 수도 있지만 그렇게 하려면 많은 시간이 걸리게 된다. 코드의 실행 시간이 1분, 1시간, 하루, 심지어 일주일 더 늘어난다 해도, 코드를 다시 쓰는 데 그보다 더 오래 걸린다면 상관없다. 가끔은 기술 부채를 늘리는 편이 처음부터 제대로 만드는 것보다 돈이 덜 든다.

라이브러리가 폐쇄 코드가 아니라 자기 자신이 오래 전에 쓴 코드인 경우도 있다. 이 경우 라이브러리의 모든 것을 다시 쓰는 것보다 데이터를 한번 더 변환하는 편이 더 빠를 수 있다. 그러니까 그냥 요요 코드를 쓰자. 괜찮다. 누구나 겪는 일이다.

나쁜 프로그래밍 습관 7 : 독자적인 데이터 구조 쓰기

프로그래머가 지켜야 할 표준 규칙 중 하나는 대학 2학년때 데이터 구조 과목을 이수한 이후에는 데이터 저장을 위한 코드를 절대 쓰면 안 된다는 것이다. 앞으로 우리에게 필요한 모든 데이터 구조는 다른 누군가가 이미 다 만들어 놨고, 이들의 코드는 오랜 시간 검증되고 또 검증됐다. 언어에 함께 제공되며 대부분은 무료다. 직접 코드를 써봐야 버그만 생길 뿐이다.

그러나 가끔은 데이터 구조 라이브러리의 속도가 느리거나, 표준이긴 하지만 내 코드와는 맞지 않는 구조를 강제하거나, 구조를 사용하려면 먼저 데이터를 재구성할 수밖에 없는 경우가 있다. 때로는 라이브러리에 쓰레드 잠금과 같은 이중 보호 기능이 포함되지만 코드에 그러한 기능이 필요 없을 수도 있다.

그런 경우에 해당된다면 자기만의 데이터 구조를 써야 할 때다. 그 편이 훨씬 더 빠른 경우도 있다. 또한 데이터를 다시 포맷하기 위한 온갖 부가적인 코드를 포함하지 않아도 되므로 코드가 훨씬 더 깔끔해지기도 한다.
 

나쁜 프로그래밍 습관 8 : 구식 루프

오래전, C 언어를 만든 사람은 모든 추상화 가능성을 하나의 간단한 구조체로 캡슐화하고자 했다. 시작 시 수행되는 작업이 있고, 매번 루프를 통해 수행하는 작업이 있고, 모두 완료될 때 알려주는 방법이 있다. 당시에는 이 방법이 무한한 가능성을 포착하기 위한 완벽한 구문으로 간주됐다.

그땐 그랬다. 지금은 일부 현대의 잔소리꾼 눈에는 문제투성이다. 너무 많은 일이 진행된다. 이익을 위한 모든 가능성에는 해악의 가능성도 동등하게 존재한다. 읽고 알아보기가 훨씬 더 어렵다. 이들은 루프 없이 함수가 목록에 적용되고 연산 템플릿이 데이터에 매핑되는 함수형 패러다임을 좋아한다.

루프 없는 방법이 더 깔끔할 때가 있다. 특히 함수 하나와 배열 하나만 있는 경우가 그렇다. 그러나 구식 루프가 훨씬 더 많은 일을 할 수 있고, 따라서 훨씬 더 간편한 경우도 있다. 예를 들어 첫 일치 검색은 일치 항목을 찾는 즉시 멈출 수 있다면 더 간단해진다.

게다가 데이터를 대상으로 여러 가지 작업을 해야 하는 경우 함수 매핑은 부실한 코딩으로 이어지기 쉽다. 예를 들어 절대값을 받은 다음 각 수의 제곱근을 받으려는 경우를 생각해 보자. 가장 빠른 방법은 데이터를 두 번 순환하면서 첫 번째 함수를 매핑한 다음 두 번째를 매핑하는 것이다.
 

나쁜 프로그래밍 습관 9 : 중간에 루프에서 나오기

어느 날, 규칙을 만드는 집단은 모든 루프에는 “불변성”이 있어야 한다고 선언했다. 불변성이란 루프 전체에서 참인 논리 문이다. 불변성이 더 이상 참이 아니면 루프가 종료된다. 복잡한 루프에 대해 생각하기에는 좋은 방법이지만, 결과적으로는 터무니없는 금지로 이어진다. 예를 들어 루프 중간에 return이나 break 사용이 금지된다. goto 문 사용을 금지하는 규칙의 하위 집합이다.

이론은 좋지만 일반적으로 코드는 더 복잡해진다. 배열에서 테스트를 통과하는 하나의 항목을 스캔하는 다음과 같은 간단한 경우를 생각해 보자.

while (i<a.length){
   ...
   if (test(a[i]) then return a[i];
   ...
}


루프 불변성 지지자들은 또 다른 부울 변수를 추가해 이름을 notFound라고 붙인 다음 다음과 같이 사용하는 편을 선호할 것이다.

while ((notFound) && (i<a.length){
   ...
   if (test(a[i])) then notFound=false;
   ...
}


이 부울의 이름을 적절히 지정한다면 그 자체로 문서화된 코드로서 훌륭하다. 모든 사람이 더 쉽게 이해할 수 있게 해준다. 그러나 복잡성도 추가된다. 또 다른 로컬 변수를 할당하고 레지스터를 막히게 한다. 컴파일러가 똑똑하다면 알아서 수정할 수 있지만 그렇지 않을 수도 있다.

goto 또는 점프가 더 깔끔할 때도 있다.
 

나쁜 프로그래밍 습관 10 : 연산자와 함수 재정의

일부 재미있는 언어에서는 당연히 상수여야 할 것 같은 요소의 값을 재정의하는 등 정도를 벗어난 작업을 허용한다. 예를 들어 파이썬의 경우 적어도 버전 2.7 이하에서는 TRUE=FALSE라고 입력할 수 있다. 이렇게 해도 논리가 붕괴되거나 우주가 끝나지는 않는다. 단순히 TRUE와 FALSE의 의미만 바뀔 뿐이다. C 전처리기와 일부 다른 언어에서도 이와 같은 위험한 놀이를 할 수 있다. 또한 더하기 기호와 같은 연산자를 재정의할 수 있는 언어도 있다.

다소 비약이지만, 큰 코드 블록 내에서 이러한 상수 하나 이상을 재정의하는 편이 더 빠를 때가 있다. 상사가 갑자기 코드에 전혀 다른 기능을 원할 때도 있다. 물론 코드를 살펴보면서 연산자를 하나씩 찾아 모두 변경할 수 있지만, 그보다 간단히 현실을 재정의하는 방법도 있다. 아마 천재처럼 보일 것이다. 방대한 라이브러리를 다시 쓰는 대신 비트 하나만 뒤바꿔 반대로 움직이게 한다.

이쯤에서 선을 긋는 것이 좋을 것 같다. 아무리 기발하고 재미있더라도 집에서 따라하면 안 된다. 솔직히 말해 너무 위험하다. editor@itworld.co.kr
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.