2019.12.09

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

Peter Wayner | InfoWorld
엄마 몰래 쿠키를 먹고, 저녁에 와인을 다소 과하게 마시고, 요금 미터기 시간이 지난 다음에도 주차장에 차를 세워 두고, 급커브 구간을 너무 빠르게 돌아 나간 경험은 모두가 있을 것이다. 물론 프로그래밍의 기본적인 이런저런 규칙도 위반한다. 나쁜 행동이라는 사실은 모두가 알고 수긍한다. 그러나 비밀스럽게 그 나쁜 행동을 즐긴다.

우리는 좋은 프로그래밍 규칙을 조롱하는 나쁜 코드를 쓰고도 아무렇지도 않게 잘 살고 있다. 프로그래밍의 신이 내리는 벼락을 맞지도 않았고 책상이 폭발하지도 않았다. 사실 코드는 컴파일되어 이미 전달됐고 고객도 만족한 것 같다. 
 
ⓒ MatDesign24

나쁜 프로그래밍은 예를 들어 전기 철조망을 혀로 핥거나 호랑이의 꼬리를 잡아당기는 수준의 행동은 아니기 때문이다. 대부분의 경우에는 아무 탈없이 넘어간다. 규칙이라 해도 위반 시 코드가 사망하는 엄중한 명령이 아니라 가이드라인 또는 스타일 제안에 가깝다. 물론 코드가 비웃음의 대상이 될 수도 있고 경우에 따라서는 공개적인 망신을 당하기도 한다. 그러나 규약에 저항한다는 사실은 이른바 사회적인 좋은 코드의 관습을 어기는 데서 오는 스릴을 느끼게 해준다.

게다가 때로는 규칙을 어기는 편이 더 좋을 때도 있다. (쉿!) 그렇게 나온 코드가 더 깔끔하고 더 빠르거나 간소할 수 있다. 규칙은 일반적으로 지나치게 광범위한데, 재주가 있는 프로그래머는 그 규칙을 어김으로써 코드를 더 개선할 수 있다. 상사에게 말하면 안 되지만 가끔은 자기만의 방법으로 코딩하는 편이 더 좋다.

무조건 지켜야 하는 확고한 규칙이라고 생각하는 사람들도 있지만, 실제로는 많은 프로그래머들이 자주 어기고 그 결과로 성공과 즐거움을 얻는 10가지 규칙을 살펴보자.
 

나쁜 프로그래밍 습관 1 : 베끼기

학교에서는 분명 잘못된 행동이다. 그러나 직장의 경우 명확하지 않다. 물론 훔치면 안 되는 코드 블록도 있다. 출처가 독점 코드인 경우, 특히 저작권 메시지까지 붙어 있다면 가져와서는 안 된다. 자기만의 코드를 고안하라. 그게 회사에서 월급을 주는 이유다.

조금 다른 경우는 원작자가 공유를 원할 때다. 온라인 프로그래밍 포럼에서 공유되는 코드, 함수 2~3개 정도의 복사를 허용하는 라이선스(BSD, MIT) 하에 배포되는 오픈소스 코드 등이다. 법적으로 베끼지 못할 이유는 없다. 회사는 여러분에게 문제를 해결하라고 월급을 주는 것이지, 불필요하게 시간을 낭비하라고 월급을 주는 것이 아니다.

대부분의 경우 조금 주의하면 베껴서 얻는 이점은 많고 단점은 별로 없다. 평판이 좋은 출처에서 구한 코드는 이미 한번 이상 심사숙고를 거친 코드다. 원작자가 문제의 해결책을 찾다가 떠올린 방법이며 루프의 불변성과 데이터 흐름도 검증됐다.

다만 아직 발견되지 않은 버그가 있는지 여부, 또는 역할이나 기반 데이터에 대해 자신의 상황과는 다른 전제가 있는지 여부는 쉽게 판단할 수 없는 부분이다. 자신의 코드에는 널 포인터가 있지만 가져온 코드는 널 포인터를 확인하지 않을 수 있다. 이와 같은 문제만 해결할 수 있다면 회사 입장에서는 두 프로그래머의 아이디어를 모두 활용하는 셈이다. 혼자서 하는 듀엣 프로그래밍이다.
 

나쁜 프로그래밍 습관 2 : 비함수형 코드

지난 10년은 함수형 패러다임이 부상한 시기다. 추종자들은 중첩된 함수로 이뤄진 프로그램을 만들면서 과거 프로그래머들이 제각각 멋대로 구성했던 변수 및 루프 스타일에 비해 코드가 더 안전하고 버그도 적다는 것을 보여주는 연구 자료를 즐겨 인용한다. 이들은 진정한 믿음에서 우러나오는 열정을 갖고 이야기하며, 코드 리뷰와 풀 요청에서 비함수적 접근 방법이 보이면 힐난한다. 함수형의 장점에 관한 이들의 믿음에는 옳은 면이 있다.

그러나 가끔은 임기응변이 필요하다. 잘 설계되고 매끄럽게 계획된 코드는 구상하는 데도, 설계하고 이후 탐색하는 데도 많은 시간이 걸린다. 모든 계층은 복잡성을 더하며 복잡성은 높은 비용으로 이어진다. 멋들어진 함수형 코드의 개발자는 미리 계획하면서 모든 데이터가 적절한 경로로 전달되도록 해야 한다. 때로는 그냥 변수 하나를 바꾸고, 설명하는 주석 한 줄을 넣는 편이 더 쉬울 수 있다. 주석에 미래 세대를 향한 구구절절한 사과문을 추가한다 해도 그게 올바른 방식으로 동작하게끔 시스템 전체를 재설계하는 것보다는 더 빠르다.
 

나쁜 프로그래밍 습관 3 : 비표준 공백

소프트웨어에서 공백은 대부분 프로그램의 작동과 무관하다. 파이썬과 같이 간격을 통해 코드 블록을 나타내는 소수 언어를 제외하면 대부분의 공백은 프로그램의 동작에 아무런 영향을 미치지 않는다. 그러나 공백에 강박적으로 집착하고 공백의 중요함을 역설하는 프로그래머들이 있다. 한번은 그런 프로그래머 중 한 명이 필자의 상사에게 세상 심각한 말투로 필자가 쓴 코드가 “비표준 코드”이며 코드를 보자마자 그 사실을 알아차렸다고 말한 적이 있다. 필자가 저지른 죄는 등호의 양쪽 모두에 공백을 넣어야 하는 ESLint 공백 인픽스 연산자 규칙을 위반한 것이다.



2019.12.09

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

Peter Wayner | InfoWorld
엄마 몰래 쿠키를 먹고, 저녁에 와인을 다소 과하게 마시고, 요금 미터기 시간이 지난 다음에도 주차장에 차를 세워 두고, 급커브 구간을 너무 빠르게 돌아 나간 경험은 모두가 있을 것이다. 물론 프로그래밍의 기본적인 이런저런 규칙도 위반한다. 나쁜 행동이라는 사실은 모두가 알고 수긍한다. 그러나 비밀스럽게 그 나쁜 행동을 즐긴다.

우리는 좋은 프로그래밍 규칙을 조롱하는 나쁜 코드를 쓰고도 아무렇지도 않게 잘 살고 있다. 프로그래밍의 신이 내리는 벼락을 맞지도 않았고 책상이 폭발하지도 않았다. 사실 코드는 컴파일되어 이미 전달됐고 고객도 만족한 것 같다. 
 
ⓒ MatDesign24

나쁜 프로그래밍은 예를 들어 전기 철조망을 혀로 핥거나 호랑이의 꼬리를 잡아당기는 수준의 행동은 아니기 때문이다. 대부분의 경우에는 아무 탈없이 넘어간다. 규칙이라 해도 위반 시 코드가 사망하는 엄중한 명령이 아니라 가이드라인 또는 스타일 제안에 가깝다. 물론 코드가 비웃음의 대상이 될 수도 있고 경우에 따라서는 공개적인 망신을 당하기도 한다. 그러나 규약에 저항한다는 사실은 이른바 사회적인 좋은 코드의 관습을 어기는 데서 오는 스릴을 느끼게 해준다.

게다가 때로는 규칙을 어기는 편이 더 좋을 때도 있다. (쉿!) 그렇게 나온 코드가 더 깔끔하고 더 빠르거나 간소할 수 있다. 규칙은 일반적으로 지나치게 광범위한데, 재주가 있는 프로그래머는 그 규칙을 어김으로써 코드를 더 개선할 수 있다. 상사에게 말하면 안 되지만 가끔은 자기만의 방법으로 코딩하는 편이 더 좋다.

무조건 지켜야 하는 확고한 규칙이라고 생각하는 사람들도 있지만, 실제로는 많은 프로그래머들이 자주 어기고 그 결과로 성공과 즐거움을 얻는 10가지 규칙을 살펴보자.
 

나쁜 프로그래밍 습관 1 : 베끼기

학교에서는 분명 잘못된 행동이다. 그러나 직장의 경우 명확하지 않다. 물론 훔치면 안 되는 코드 블록도 있다. 출처가 독점 코드인 경우, 특히 저작권 메시지까지 붙어 있다면 가져와서는 안 된다. 자기만의 코드를 고안하라. 그게 회사에서 월급을 주는 이유다.

조금 다른 경우는 원작자가 공유를 원할 때다. 온라인 프로그래밍 포럼에서 공유되는 코드, 함수 2~3개 정도의 복사를 허용하는 라이선스(BSD, MIT) 하에 배포되는 오픈소스 코드 등이다. 법적으로 베끼지 못할 이유는 없다. 회사는 여러분에게 문제를 해결하라고 월급을 주는 것이지, 불필요하게 시간을 낭비하라고 월급을 주는 것이 아니다.

대부분의 경우 조금 주의하면 베껴서 얻는 이점은 많고 단점은 별로 없다. 평판이 좋은 출처에서 구한 코드는 이미 한번 이상 심사숙고를 거친 코드다. 원작자가 문제의 해결책을 찾다가 떠올린 방법이며 루프의 불변성과 데이터 흐름도 검증됐다.

다만 아직 발견되지 않은 버그가 있는지 여부, 또는 역할이나 기반 데이터에 대해 자신의 상황과는 다른 전제가 있는지 여부는 쉽게 판단할 수 없는 부분이다. 자신의 코드에는 널 포인터가 있지만 가져온 코드는 널 포인터를 확인하지 않을 수 있다. 이와 같은 문제만 해결할 수 있다면 회사 입장에서는 두 프로그래머의 아이디어를 모두 활용하는 셈이다. 혼자서 하는 듀엣 프로그래밍이다.
 

나쁜 프로그래밍 습관 2 : 비함수형 코드

지난 10년은 함수형 패러다임이 부상한 시기다. 추종자들은 중첩된 함수로 이뤄진 프로그램을 만들면서 과거 프로그래머들이 제각각 멋대로 구성했던 변수 및 루프 스타일에 비해 코드가 더 안전하고 버그도 적다는 것을 보여주는 연구 자료를 즐겨 인용한다. 이들은 진정한 믿음에서 우러나오는 열정을 갖고 이야기하며, 코드 리뷰와 풀 요청에서 비함수적 접근 방법이 보이면 힐난한다. 함수형의 장점에 관한 이들의 믿음에는 옳은 면이 있다.

그러나 가끔은 임기응변이 필요하다. 잘 설계되고 매끄럽게 계획된 코드는 구상하는 데도, 설계하고 이후 탐색하는 데도 많은 시간이 걸린다. 모든 계층은 복잡성을 더하며 복잡성은 높은 비용으로 이어진다. 멋들어진 함수형 코드의 개발자는 미리 계획하면서 모든 데이터가 적절한 경로로 전달되도록 해야 한다. 때로는 그냥 변수 하나를 바꾸고, 설명하는 주석 한 줄을 넣는 편이 더 쉬울 수 있다. 주석에 미래 세대를 향한 구구절절한 사과문을 추가한다 해도 그게 올바른 방식으로 동작하게끔 시스템 전체를 재설계하는 것보다는 더 빠르다.
 

나쁜 프로그래밍 습관 3 : 비표준 공백

소프트웨어에서 공백은 대부분 프로그램의 작동과 무관하다. 파이썬과 같이 간격을 통해 코드 블록을 나타내는 소수 언어를 제외하면 대부분의 공백은 프로그램의 동작에 아무런 영향을 미치지 않는다. 그러나 공백에 강박적으로 집착하고 공백의 중요함을 역설하는 프로그래머들이 있다. 한번은 그런 프로그래머 중 한 명이 필자의 상사에게 세상 심각한 말투로 필자가 쓴 코드가 “비표준 코드”이며 코드를 보자마자 그 사실을 알아차렸다고 말한 적이 있다. 필자가 저지른 죄는 등호의 양쪽 모두에 공백을 넣어야 하는 ESLint 공백 인픽스 연산자 규칙을 위반한 것이다.



X