숙련된 개발자도 저지르는 15가지 초보적 실수

초보적 실수 8 : 상속에 대한 무한 애정
분해(decomposition)에 관한 수업도 들었겠다, 최선은 모든 것을 완벽한 클래스 구조로 체계화하는 것이라고 생각한다. 억제해야 할 요소나 프로그램의 기능성에 대해서는 잊는다. 모두에게 자신의 뇌가 어떻게 움직이는지 보여주고 추한 병렬 클래스 구조를 각인시킨다. 이런 사람은 DMTF에서 일을 하면 딱 좋다.

즉, 모두를 괴롭히는 쓰레기 표준을 내놓을 수 있다. 그러지 말자!

초보적 실수 9 : 함수형에 대한 무한 애정
방금 함수형 프로그래밍에 대해 모든 것을 배웠다. 객체 지향 프로그래밍이 큰 착오였으며 모든 것은 무상태(stateless) 및 함수형이어야 한다고 생각한다.

코드에 한 가지를 더 추가해야 하는 경우를 제외하고, 추가를 위해 모든 함수 호출을 풀어야 한다면 그건 잘못된, 단단히 잘못된 일이다.

초보적 실수 10 : 전역에 대한 무한 애정
코딩은 어렵고 생각하기도 어렵고 무언가의 범위를 결정하기도 어렵다. 그러나 그런 고민은 접어두고, 그냥 가능한 가장 일반적인(public) 범위를 사용하기로 결심한다. 메모리는 죽고 코드는 병렬화되지 않고 쓰레드는 충돌한다. 힘들게 고민하지 않은 결과다!

초보적 실수 11 : 초대형 객체 사용하기
한 번은 신입 직원과 함께 파견을 나간 적이 있는데, 그 직원에게 이 작업이 몇 가지 양상 중 하나로 진행될 것이라고 말했다. 그중 하나는 이 회사 사람들이 “초대형 객체”를 세션에 던져 넣고는 왜 “클러스터링이 작동하지 않는지”, 왜 메모리가 동나는지 납득하지 못하는 상황이었다.

물론 우리가 도착했을 때 이미 수백 개의 상태 변수와 이를 변경하기 위한 메소드가 포함된 클래스가 있었다. 당연히 이들은 세션에 이 클래스를 던져 넣었다. 이러한 요소들 대부분은 사실 세션에 포함될 필요가 없었으며 기본적으로 수동으로, 조잡하게 작성된 2차 데이터베이스 캐시 구성을 위한 것이었다. 막대한 메모리 낭비였다. 메모리를 혹사하고 쓸데없이 많은 비용이 드는 세션 복제를 유발하고 있었다.

초보적 실수 12 : 1,000개의 객체에 의한 사망
모자라서 문제가 되듯이 많아도 문제가 된다. 1,000개의 객체에 의한 사망은 초보적 실수 8번, 상속에 대한 무한 애정과 함께 발생하는 경우가 많지만 상속 없이 단독으로 발생하는 경우도 있다. 클래스 파일이 모두 100줄 미만이고 그런 파일이 수백, 수천 개 있다면 그것 역시 뭔가 잘못하고 있다는 뜻이다.

초보적 실수 13 : 무조건적 쓰레딩
대부분의 애플리케이션 코드는 단일 쓰레드 관점으로 작성할 수 있다. 애플리케이션 서버, 데이터베이스 또는 다른 인프라를 만들기 시작하면 그 관점도 깨지지만 대부분의 비즈니스 소프트웨어는 단일 쓰레드 인프라를 사용해 작성할 수 있다. 즉, 온갖 것을 다중 쓰레드로 할 필요가 없다.

특히 지금은 쓰레드 코드를 쓰지 않고도 분산 및 쓰레드의 이점을 이용하기가 쉬우므로 더욱 할 필요가 없다. 스파크의 작동 원리를 보라. 쓸데없이 쓰레드 객체를 만들지 않는다.

초보적 실수 14 : 행 잠금 사용
SQL 서버와 DB2 사용자들의 문제다. 대부분의 플랫폼에서 기본 데이터베이스 설정은 행 잠금용이다(DB2는 다른 플랫폼에서 페이지 잠금을 하는데, 이건 더 나쁨). 오라클의 기본값은 그나마 덜 멍청하다. 한때는 행 잠금과 스냅샷 격리를 두고 논쟁도 있었다. 이론적으로 행 잠금이 더 효율적이지만 경합 가능성이 조금이라도 있는(거의 모든 현대 소프트웨어에 해당됨) 쓰레드가 하나만 더 있어도 그 이점은 사라진다.

대부분의 개발자는 “스냅샷 격리”가 무엇을 의미하는지도 모르니 그것을 켜는 방법도 당연히 모른다. 결과적으로 행 잠금을 사용하게 되므로 프로덕션 환경에서 여러가지 알 수 없는 이유로 작동을 멈춘다. 스냅샷 격리와 이를 적절히 사용하는 방법을 배우고 행 잠금을 피하라.

초보적 실수 15 : 시퀀스 사용
소리 내서 읽기 : 나는 순차 값이 정말 필요한 경우가 아닌 한 고유한 키에 대해 데이터베이스 시퀀스를 사용하지 않겠습니다.

그런 경우는 매우 드물다. 잠금과 리모팅이 “편리하게도” 하나의 패키지로 등장해 괴롭힌다.

데이터베이스 시퀀스 생성기에서 모든 것을 단일 쓰레드로 처리하는 대신 보안 난수 생성기로 지원되는 128비트 UUID를 사용할 수 있다. 중복을 걱정한다면 그건 수학을 못하거나 자신의 삶이 데이터만큼의 가치도 없다고 생각하는 사람이다. 1조 개의 ID를 생성한다 해도 중복될 가능성은 운석에 머리를 맞을 확률 정도다.

자기 자신과 자신의 직업, 그리고 누가 됐든 자신의 뒤를 이어 그 코드를 유지보수해야 할 사람을 존중하려면 이런 것은 피하라. 결국 숙련된 개발자도 가끔은 초보적 실수를 저지른다. 이제부터라도 더 이상 죄를 짓지 말자.  editor@itworld.co.kr