2015.11.03

개발자가 애용하는 나쁜 프로그래밍 습관 9가지

Peter Wayner | InfoWorld

우리 모두 하지 말라는 일을 한다. 지금 먹어서는 안 되는 쿠키를 엄마 몰래 집어 먹고, 위험한 구간에서 과속을 하며, 주차 미터기의 시간이 만료됐음에도 차를 주차시킨다. 프로그래밍도 마찬가지이다. 절대 지켜야 할 프로그래밍 규칙을 다수 위반한다. 누구나 나쁜 습관이라고 지적하는 습관들이다. 그런데 이런 습관과 '밀애'에 빠진다.

프로그래밍에서 지켜야 할 좋은 규칙을 무시하고, 정말 나쁜 코드를 작성한다. 그렇지만 살아 남는다. '프로그래밍의 신'에게는 '번개'가 없기 때문이다. 데스크톱이 폭발하지도 않는다. 완성된 코드가 출하되면, 고객들은 만족해한다.

프로그래밍이 나쁘다고 전기 펜스를 건드리거나, 호랑이 꼬리를 잡아 당길 때만큼의 중대한 문제가 발생하는 경우는 없기 때문이다. 대부분은 넘어간다. 프로그래밍과 관련된 규칙은 '안내서'나 '형식에 대한 제안서'에 가까운 경우가 많다. 지키지 않으면 재앙이 초래될 규칙이 아니다. 물론, (때론 공개적으로)코드가 웃음거리가 될 수 있다. 그러나 이렇게 '관습'을 무시하는 행위는 코드의 '사회적 규범'을 파괴한다는 작은 '스릴감'을 선사한다.

또 때론 규칙을 깨는 것이 나을 때도 있다. 문제가 더 복잡해지는 이유이다. 코드는 정갈해야 한다. 빠르고 단순해야 한다. 이렇게 규칙들이 너무 광범위한 경우가 많다. 실력 있는 프로그래머라면 규칙을 깨면서 효율성을 높일 수 있다. 상사에게는 말할 수 없다. 그러나 때론 자신의 방식대로 프로그래밍을 하는 것이 합리적이다.

다음은 일부에서는 문제점으로 지적하고 있지만, 우리 상당수가 좋아하는(그리고 성과를 내기도 하는) 프로그래밍 규칙 9가지이다.

프로그래밍 습관 1 : GOTO 이용
GOTO 이용 금지는 구조화 프로그래밍 툴 상당수가 등장하기 이전 시대로 거슬러 올라간다. 프로그래머가 다른 루틴으로의 루프나 점프를 생성하고 싶다면 줄 번호 다음에 GOTO를 입력해야 했다. 그러나 몇 년 뒤, 컴파일러 팀은 프로그래머가 줄 번호 대신 스트링 라벨을 이용하도록 요구했다. 당시 '핫'한 신기능이었기 때문이다.

일부는 이렇게 해서 나온 결과를 '스파게티 코드'라고 불렀다. 다른 사람이 나중에 코드와 실행 경로를 파악할 수 없었다. 쓰레드가 뒤범벅이 된 상태였다. 에츠허르 데이크스트라(Edsger Dijkstra)는 '유해한 Goto 명령문'이라는 필사본에서 이 명령을 금기시했다.

그러나 분기(Branching)가 문제는 아니었다. 그 결과인 얽힘이 문제였다. Break나 Return으로 해당 자리에서 코드의 기능을 보여주는 아주 정갈한 명령문을 만들 수 있다. Case 명령문에 Goto를 추가시켜 'if' 블록으로 이어지는 구조화된 리스트보다 더 간단하게 이해할 수 있는 명령문을 만들 수도 있다.

물론 문제점도 있다. 애플 SSL 스택의 Goto 관련 보안 취약점이 이를 대표하는 사례이다. 그러나 Case 명령문과 루프의 문제점 일부에 주의를 기울이면, 읽는 사람이 기능을 더 쉽게 이해할 수 있는 좋은 Jump를 삽입할 수 있다. Goto를 아주 싫어하는 사람들을 제외하면 누구나 더 깔끔하고, 누구나 쉽게 판독할 수 있는 Break나 Return을 삽입할 수 있다.

프로그래밍 습관 2 : 문서화 기피
필자의 친구 중 한 명은 직접 코드를 개발한 적은 없지만, 모든 기능을 문서화에 포함시켜야 한다는 상사 밑에서 일을 했다. 주석을 집어넣지 않은 프로그래머는 '처벌'을 받았다. 그래서 필자의 친구는 자신의 코드 편집기에 Eliza 같은 인공지능을 집어 넣었다. 그 결과 모든 기능에 '문서화' 줄 몇 개가 생성됐다. 상사는 이 명령 줄에 아무런 의미가 없다는 사실을 이해하지 못했다. 친구는 이런 식으로 곤경을 회피했다. 공식으로 문서화된 코드였기 때문이다. 심지어는 승진까지 했다.

많은 기능, 일부 경우에는 클래스에도 어느 정도 자가 문서화가 생성된다. 예를 들어, insertReservation이나 cancelReservation, deleteAll에는 1~3줄의 설명이 필요 없다. 기능에 맞는 이름을 선택하는 것만으로 충분한 때가 많다. 기능의 명칭이 코드의 다른 장소에서 나타나기 때문에, 긴 문서화를 생성하는 것보다 낫다. 문서화는 한 장소로 족하다. 기능 이름의 자가 문서화로 모든 파일을 향상시킬 수 있다.

문서화를 피해야 하는 상황도 있다. 팀이 코드를 계속해서 바꾸는 경우, 문서화가 혼란을 초래할 수 있다. 코드는 한 가지를 말하고 있는데, 문서화는 변경 과정에 발생한 4~5가지를 말하는 상황이다. 누군가 코드 위에 기능을 요약한 주석을 썼을 때 자주 발생하는 문제이다. 코드를 바꾸는 팀은 이 주석을 고쳐야 한다. 그러나 이를 놓칠 가능성이 있다.

코드와 텍스트가 다르면, 주석의 가치가 사라지며, 때론 위험이 초래된다. 이 경우, 주석을 작성하지 않는 코드 자가 문서화가 낫다.




2015.11.03

개발자가 애용하는 나쁜 프로그래밍 습관 9가지

Peter Wayner | InfoWorld

우리 모두 하지 말라는 일을 한다. 지금 먹어서는 안 되는 쿠키를 엄마 몰래 집어 먹고, 위험한 구간에서 과속을 하며, 주차 미터기의 시간이 만료됐음에도 차를 주차시킨다. 프로그래밍도 마찬가지이다. 절대 지켜야 할 프로그래밍 규칙을 다수 위반한다. 누구나 나쁜 습관이라고 지적하는 습관들이다. 그런데 이런 습관과 '밀애'에 빠진다.

프로그래밍에서 지켜야 할 좋은 규칙을 무시하고, 정말 나쁜 코드를 작성한다. 그렇지만 살아 남는다. '프로그래밍의 신'에게는 '번개'가 없기 때문이다. 데스크톱이 폭발하지도 않는다. 완성된 코드가 출하되면, 고객들은 만족해한다.

프로그래밍이 나쁘다고 전기 펜스를 건드리거나, 호랑이 꼬리를 잡아 당길 때만큼의 중대한 문제가 발생하는 경우는 없기 때문이다. 대부분은 넘어간다. 프로그래밍과 관련된 규칙은 '안내서'나 '형식에 대한 제안서'에 가까운 경우가 많다. 지키지 않으면 재앙이 초래될 규칙이 아니다. 물론, (때론 공개적으로)코드가 웃음거리가 될 수 있다. 그러나 이렇게 '관습'을 무시하는 행위는 코드의 '사회적 규범'을 파괴한다는 작은 '스릴감'을 선사한다.

또 때론 규칙을 깨는 것이 나을 때도 있다. 문제가 더 복잡해지는 이유이다. 코드는 정갈해야 한다. 빠르고 단순해야 한다. 이렇게 규칙들이 너무 광범위한 경우가 많다. 실력 있는 프로그래머라면 규칙을 깨면서 효율성을 높일 수 있다. 상사에게는 말할 수 없다. 그러나 때론 자신의 방식대로 프로그래밍을 하는 것이 합리적이다.

다음은 일부에서는 문제점으로 지적하고 있지만, 우리 상당수가 좋아하는(그리고 성과를 내기도 하는) 프로그래밍 규칙 9가지이다.

프로그래밍 습관 1 : GOTO 이용
GOTO 이용 금지는 구조화 프로그래밍 툴 상당수가 등장하기 이전 시대로 거슬러 올라간다. 프로그래머가 다른 루틴으로의 루프나 점프를 생성하고 싶다면 줄 번호 다음에 GOTO를 입력해야 했다. 그러나 몇 년 뒤, 컴파일러 팀은 프로그래머가 줄 번호 대신 스트링 라벨을 이용하도록 요구했다. 당시 '핫'한 신기능이었기 때문이다.

일부는 이렇게 해서 나온 결과를 '스파게티 코드'라고 불렀다. 다른 사람이 나중에 코드와 실행 경로를 파악할 수 없었다. 쓰레드가 뒤범벅이 된 상태였다. 에츠허르 데이크스트라(Edsger Dijkstra)는 '유해한 Goto 명령문'이라는 필사본에서 이 명령을 금기시했다.

그러나 분기(Branching)가 문제는 아니었다. 그 결과인 얽힘이 문제였다. Break나 Return으로 해당 자리에서 코드의 기능을 보여주는 아주 정갈한 명령문을 만들 수 있다. Case 명령문에 Goto를 추가시켜 'if' 블록으로 이어지는 구조화된 리스트보다 더 간단하게 이해할 수 있는 명령문을 만들 수도 있다.

물론 문제점도 있다. 애플 SSL 스택의 Goto 관련 보안 취약점이 이를 대표하는 사례이다. 그러나 Case 명령문과 루프의 문제점 일부에 주의를 기울이면, 읽는 사람이 기능을 더 쉽게 이해할 수 있는 좋은 Jump를 삽입할 수 있다. Goto를 아주 싫어하는 사람들을 제외하면 누구나 더 깔끔하고, 누구나 쉽게 판독할 수 있는 Break나 Return을 삽입할 수 있다.

프로그래밍 습관 2 : 문서화 기피
필자의 친구 중 한 명은 직접 코드를 개발한 적은 없지만, 모든 기능을 문서화에 포함시켜야 한다는 상사 밑에서 일을 했다. 주석을 집어넣지 않은 프로그래머는 '처벌'을 받았다. 그래서 필자의 친구는 자신의 코드 편집기에 Eliza 같은 인공지능을 집어 넣었다. 그 결과 모든 기능에 '문서화' 줄 몇 개가 생성됐다. 상사는 이 명령 줄에 아무런 의미가 없다는 사실을 이해하지 못했다. 친구는 이런 식으로 곤경을 회피했다. 공식으로 문서화된 코드였기 때문이다. 심지어는 승진까지 했다.

많은 기능, 일부 경우에는 클래스에도 어느 정도 자가 문서화가 생성된다. 예를 들어, insertReservation이나 cancelReservation, deleteAll에는 1~3줄의 설명이 필요 없다. 기능에 맞는 이름을 선택하는 것만으로 충분한 때가 많다. 기능의 명칭이 코드의 다른 장소에서 나타나기 때문에, 긴 문서화를 생성하는 것보다 낫다. 문서화는 한 장소로 족하다. 기능 이름의 자가 문서화로 모든 파일을 향상시킬 수 있다.

문서화를 피해야 하는 상황도 있다. 팀이 코드를 계속해서 바꾸는 경우, 문서화가 혼란을 초래할 수 있다. 코드는 한 가지를 말하고 있는데, 문서화는 변경 과정에 발생한 4~5가지를 말하는 상황이다. 누군가 코드 위에 기능을 요약한 주석을 썼을 때 자주 발생하는 문제이다. 코드를 바꾸는 팀은 이 주석을 고쳐야 한다. 그러나 이를 놓칠 가능성이 있다.

코드와 텍스트가 다르면, 주석의 가치가 사라지며, 때론 위험이 초래된다. 이 경우, 주석을 작성하지 않는 코드 자가 문서화가 낫다.


X