2015.09.25

좋은 소프트웨어 코드의 6가지 공통점

Phil Johnson | ITWorld
구글만 해도 20억 줄의 코드를 보유하고 있다. 그러나 소스 코드라고 모두 같은 것은 아니다. 소프트웨어 개발자들은 통상 '좋은' 원본(Raw) 코드의 구성 요소에 있어 확실한 선호도를 갖고 있다.

우수한 소프트웨어 코드의 특징이 무엇인지 파악하기 위해 경력이 많은 소프트웨어 개발자들에게 자문했다. 다른 개발자가 쓰고 싶은, 또는 다루고 싶은 코드의 특징이 무엇인지 알아보기 위해 온라인 토론 포럼을 조사했다.

그 결과, '좋은' 소프트웨어 소스 코드의 6가지 공통점을 찾을 수 있었다.

쉽게 읽을 수 있다
개발자들은 코드 품질을 결정하는 가장 중요한 요소 중 하나로 '가독성(Readability)'을 꼽고 있다. 다른 개발자도 최소한의 시간과 노력만 투자해 쉽게 판독할 수 있는 코드가 최상의 코드다.

라이온브릿지(Lionbridge)의 선임 소프트웨어 엔지니어인 루크 번햄은 "5분 이내에 개발자의 의도를 이해할 수 없는 코드는 좋은 코드가 아니다. 컴퓨터와 달리 사람은 변수의 이름이나 줄 간격을 고려한다. 한 번 개발된 코드는 수명주기 동안 수백 차례 읽힌다. 코드의 가독성을 높이기 위해 유의미한 변수 이름을 사용하고, 간격을 삽입해야 한다. 그래야만 좋은 코드가 될 수 있다"고 말했다.

십여 년의 경력을 가진 웹 애플리케이션 개발자 한 명은 "(적절한 간격, 들여쓰기, 흐름 등)일관된 스타일로 코드를 써야 좋은 코드가 될 수 있다"고 말했다. 그는 또 변수에 쉽게 이해할 수 있는 이름을 선택해 붙이는 것이 중요하다고 강조했다.

고우고우(Gogo)의 선임 애플리케이션 개발자인 닐 베스트는 "빨리, 그리고 자주 행갈이(Wrap)를 하는 것을 원칙으로 삼고 있다. 개인적으로 선호하는 스타일이다. 행보다는 열이 긴 것을 선호한다. 줄을 늘이려는 의도가 아니라, 가독성을 높이기 위해서이다. 함수의 Arguments가 두 개라면 두 줄로 작성한다. 산술식의 변수가 여럿이라면 각각 별개의 줄로 작성한다. 판독자가 RTFM을 이용해야 할 필요가 있을지 모르지만, 그만한 가치가 있다"고 말했다.

간단히 말해, 가독성이 높아야 더 쉽게 이해할 수 있다. 그래야 모든 이에게 도움이 된다.

스택 오버플로우(Stack Overflow)의 Glennular라는 사용자는 댓글을 통해 "더 빨리 보고 이해할 수 있어야 한다. 그래야 더 빠르게 애플리케이션을 개발하고 (기능과 매출)을 업데이트할 수 있다"고 말했다. 스택 익스체인지의 사용자인 mojuba는 "코드를 빨리 이해할 수 있는 것이 가장 중요하다"고 말했다.

주석이 잘 정리되어 있다
코드를 더 쉽게 이해할 수 있도록 만드는 요소로는 형식과 이름 외에 주석이 있다. 그러나 주석이라고 다 코드를 쉽게 이해하도록 돕는 것은 아니다. 번햄은 "루프가 뭔지 말해주는 주석은 필요 없다. 코드의 기능, 그 이유를 말해주는 주석이 필요하다. 좋은 코드에는 개발자가 코드를 개발한 목적을 설명하는 주석이 있다"고 말했다.

가장 좋은 주석은 코드를 읽는 다른 개발자는 물론 코드를 개발한 당사자에게도 도움을 준다고 강조했다. 그는 "미래에 코드를 개발할 당시 어떤 생각을 했는지 ‘깜박’하는 경우를 대비해야 한다. 가까운 미래에 해당 코드를 살펴보고 수정하는 사람이 단 한 명이라도, 유의미한 이름과 정보가 든 주석을 선택적으로 이용하면 작업이 훨씬 간결해진다. 나의 경우에는 코드에 무슨 일이 벌어지고 있는지 적기 위해 인터리빙 산문에 대한 간결한 주석을 넘어 문학적인 프로그램 패러다임을 적극적으로 활용하고 있다”고 말했다.

지뉴인 인터랙티브(Genuine Interactive)의 선임 소프트웨어 엔지니어인 케빈 모일란은 "주석은 아주 중요하다"고 짧지만 강하게 강조했다.

간결하다
짧은 소스 코드가 아주 복잡한 일을 할 수 있다. 그러나 많은 개발자들은 아주 간결한(단순한) 코드가 가장 좋은 코드라고 강조한다. 능력 있는 프로그래머는 코드를 지나치게 복잡하게 만들지 않으면서 좋은 코드를 개발하는 방법을 안다.

모일란은 이메일 인터뷰에서 "각 코드가 각자의 기능을 훌륭히 수행하고, 다음 코드가 다른 기능을 수행하도록 만들어야 한다. 가장 간단한 솔루션이 최상의 솔루션이다"고 말했다.

익명의 웹 개발자는 코드를 지나치게 많이 중복해 사용하는 것을 경계해야 한다고 강조했다. 그는 1,000줄의 함수를 관리하는 것이 '악몽' 같았다면서 "짧지만 확실하게 한 가지 기능을 수행하도록 만들어야 한다"고 말했다.

Otávio Décio라는 스택 오버플로우 사용자는 "각 함수가 정확히 한 가지 기능을 수행해야 한다고 말했으며, mhomde라는 사용자는 해커 뉴스(hacker News)에서 "무한대의 목적을 가질 수는 없다. 각 추상 계층을 간결하게 만든다는 점을 유념해야 한다"고 말했다.

번햄은 "코드를 쓸 때 소로(Thoreau)의 ‘가능한 한 간결함을 유지하는 것이 중요하다'는 경구를 원칙으로 삼는다"면서 간결함의 중요성을 강조했다. 그는 또 좋은 코드는 간결한 것에 더해 '게으르다'고 말했다. 최소한의 작업만 요구해야 좋은 코드라는 의미이다. 번햄은 "온갖 종류의 기능을 발휘하다가 작동이 중단되는 코드가 많다. 처음에 간단한 테스트를 하지 않았기 때문이다"고 말했다.

개발자 상당수가 간단한 코드가 좋은 소프트웨어를 만든다는 점에 동의했다. 쿼라(Quora)의 사용자인 네빌 쿠이트(Neville Kuyt)은 "코드의 복잡성과 버그의 수에는 통계적인 상관관계가 있음이 입증됐다"고 말했다.

탄력적이다
미래에 기존에 개발한 코드의 기능을 수정, 확대, 재활용해야 하는 상황이 종종 발생한다. 번햄은 "현재 필요한 사항과 미래에 필요할 수 있는 사항 모두를 염두에 둔 소프트웨어가 좋은 소프트웨어이다"고 강조했다. 물론 미래를 예측하기란 불가능하다. 그러나 그는 "최소한의 수정으로 미래에 필요한 사항을 수용할 수 있게끔 탄력적인 소프트웨어를 개발할 수 있다"고 덧붙였다.

익명의 웹 개발자는 "미래에 코드의 다른 부분은 망가뜨리지 않으면서 일부만 변경 또는 추가할 수 있는 코드가 좋은 코드"라고 말했다.

크리스토퍼 존슨은 스택 오버플로우에 "코드를 수정해보면, 그 코드가 좋은 코드인지 알 수 있다"는 글을 남겼다.
스택 익스체인지의 사용자인 마이클 라는 "신입 직원이 6개월 전 당신이 개발한 코드를 질문 없이 수정할 수 있어야 좋은 코드"라고 말했다.

관리할 수 있어야 한다
제아무리 좋은 코드라도 버그가 있기 마련이다. 모일란은 "누군가 버그를 수정해야 할 수 있어야 한다. 당신이 버그를 수정하는 장본인이 될 수 있으므로 쉽게 수정할 수 있도록 만들어야 한다"고 말했다.

'관리성'은 좋은 코드의 중요 속성 중 하나이다. 스택 익스체인지의 사용자인 gbn은 "어떤 코드이든 관리를 해야 한다. 따라서 필요 이상 관리가 어려워서는 안 된다"고 강조했다.

익명의 개발자는 (URL, 액세스 키, 데이터베이스 비밀번호 등)을 변경시키는 하드 코딩 값 등을 피해야 미래에 관리가 쉬워진다고 충고했다.

데이빗 래치밈(David Rachamim)은 쿼라에 "그냥 기능하는 코드와 좋은 코드의 차이점은 '관리성'"이라는 글을 남겼다.

제 기능을 해야 한다
마지막으로 좋은 소프트웨어 코드가 갖춰야 할 '명백한' 특징 하나가 있다. 익명의 웹 개발자는 "코드가 제 기능을 해야 한다"고 강조했다. 모일란은 "코드가 원래 목적한 기능을 하는 것이 가장 중요하다"고 말했다.

번햄은 "아무리 좋게 보이는 코드라도 제 기능을 못 하면 좋은 코드가 아니다"고 강조했다. editor@itworld.co.kr 


2015.09.25

좋은 소프트웨어 코드의 6가지 공통점

Phil Johnson | ITWorld
구글만 해도 20억 줄의 코드를 보유하고 있다. 그러나 소스 코드라고 모두 같은 것은 아니다. 소프트웨어 개발자들은 통상 '좋은' 원본(Raw) 코드의 구성 요소에 있어 확실한 선호도를 갖고 있다.

우수한 소프트웨어 코드의 특징이 무엇인지 파악하기 위해 경력이 많은 소프트웨어 개발자들에게 자문했다. 다른 개발자가 쓰고 싶은, 또는 다루고 싶은 코드의 특징이 무엇인지 알아보기 위해 온라인 토론 포럼을 조사했다.

그 결과, '좋은' 소프트웨어 소스 코드의 6가지 공통점을 찾을 수 있었다.

쉽게 읽을 수 있다
개발자들은 코드 품질을 결정하는 가장 중요한 요소 중 하나로 '가독성(Readability)'을 꼽고 있다. 다른 개발자도 최소한의 시간과 노력만 투자해 쉽게 판독할 수 있는 코드가 최상의 코드다.

라이온브릿지(Lionbridge)의 선임 소프트웨어 엔지니어인 루크 번햄은 "5분 이내에 개발자의 의도를 이해할 수 없는 코드는 좋은 코드가 아니다. 컴퓨터와 달리 사람은 변수의 이름이나 줄 간격을 고려한다. 한 번 개발된 코드는 수명주기 동안 수백 차례 읽힌다. 코드의 가독성을 높이기 위해 유의미한 변수 이름을 사용하고, 간격을 삽입해야 한다. 그래야만 좋은 코드가 될 수 있다"고 말했다.

십여 년의 경력을 가진 웹 애플리케이션 개발자 한 명은 "(적절한 간격, 들여쓰기, 흐름 등)일관된 스타일로 코드를 써야 좋은 코드가 될 수 있다"고 말했다. 그는 또 변수에 쉽게 이해할 수 있는 이름을 선택해 붙이는 것이 중요하다고 강조했다.

고우고우(Gogo)의 선임 애플리케이션 개발자인 닐 베스트는 "빨리, 그리고 자주 행갈이(Wrap)를 하는 것을 원칙으로 삼고 있다. 개인적으로 선호하는 스타일이다. 행보다는 열이 긴 것을 선호한다. 줄을 늘이려는 의도가 아니라, 가독성을 높이기 위해서이다. 함수의 Arguments가 두 개라면 두 줄로 작성한다. 산술식의 변수가 여럿이라면 각각 별개의 줄로 작성한다. 판독자가 RTFM을 이용해야 할 필요가 있을지 모르지만, 그만한 가치가 있다"고 말했다.

간단히 말해, 가독성이 높아야 더 쉽게 이해할 수 있다. 그래야 모든 이에게 도움이 된다.

스택 오버플로우(Stack Overflow)의 Glennular라는 사용자는 댓글을 통해 "더 빨리 보고 이해할 수 있어야 한다. 그래야 더 빠르게 애플리케이션을 개발하고 (기능과 매출)을 업데이트할 수 있다"고 말했다. 스택 익스체인지의 사용자인 mojuba는 "코드를 빨리 이해할 수 있는 것이 가장 중요하다"고 말했다.

주석이 잘 정리되어 있다
코드를 더 쉽게 이해할 수 있도록 만드는 요소로는 형식과 이름 외에 주석이 있다. 그러나 주석이라고 다 코드를 쉽게 이해하도록 돕는 것은 아니다. 번햄은 "루프가 뭔지 말해주는 주석은 필요 없다. 코드의 기능, 그 이유를 말해주는 주석이 필요하다. 좋은 코드에는 개발자가 코드를 개발한 목적을 설명하는 주석이 있다"고 말했다.

가장 좋은 주석은 코드를 읽는 다른 개발자는 물론 코드를 개발한 당사자에게도 도움을 준다고 강조했다. 그는 "미래에 코드를 개발할 당시 어떤 생각을 했는지 ‘깜박’하는 경우를 대비해야 한다. 가까운 미래에 해당 코드를 살펴보고 수정하는 사람이 단 한 명이라도, 유의미한 이름과 정보가 든 주석을 선택적으로 이용하면 작업이 훨씬 간결해진다. 나의 경우에는 코드에 무슨 일이 벌어지고 있는지 적기 위해 인터리빙 산문에 대한 간결한 주석을 넘어 문학적인 프로그램 패러다임을 적극적으로 활용하고 있다”고 말했다.

지뉴인 인터랙티브(Genuine Interactive)의 선임 소프트웨어 엔지니어인 케빈 모일란은 "주석은 아주 중요하다"고 짧지만 강하게 강조했다.

간결하다
짧은 소스 코드가 아주 복잡한 일을 할 수 있다. 그러나 많은 개발자들은 아주 간결한(단순한) 코드가 가장 좋은 코드라고 강조한다. 능력 있는 프로그래머는 코드를 지나치게 복잡하게 만들지 않으면서 좋은 코드를 개발하는 방법을 안다.

모일란은 이메일 인터뷰에서 "각 코드가 각자의 기능을 훌륭히 수행하고, 다음 코드가 다른 기능을 수행하도록 만들어야 한다. 가장 간단한 솔루션이 최상의 솔루션이다"고 말했다.

익명의 웹 개발자는 코드를 지나치게 많이 중복해 사용하는 것을 경계해야 한다고 강조했다. 그는 1,000줄의 함수를 관리하는 것이 '악몽' 같았다면서 "짧지만 확실하게 한 가지 기능을 수행하도록 만들어야 한다"고 말했다.

Otávio Décio라는 스택 오버플로우 사용자는 "각 함수가 정확히 한 가지 기능을 수행해야 한다고 말했으며, mhomde라는 사용자는 해커 뉴스(hacker News)에서 "무한대의 목적을 가질 수는 없다. 각 추상 계층을 간결하게 만든다는 점을 유념해야 한다"고 말했다.

번햄은 "코드를 쓸 때 소로(Thoreau)의 ‘가능한 한 간결함을 유지하는 것이 중요하다'는 경구를 원칙으로 삼는다"면서 간결함의 중요성을 강조했다. 그는 또 좋은 코드는 간결한 것에 더해 '게으르다'고 말했다. 최소한의 작업만 요구해야 좋은 코드라는 의미이다. 번햄은 "온갖 종류의 기능을 발휘하다가 작동이 중단되는 코드가 많다. 처음에 간단한 테스트를 하지 않았기 때문이다"고 말했다.

개발자 상당수가 간단한 코드가 좋은 소프트웨어를 만든다는 점에 동의했다. 쿼라(Quora)의 사용자인 네빌 쿠이트(Neville Kuyt)은 "코드의 복잡성과 버그의 수에는 통계적인 상관관계가 있음이 입증됐다"고 말했다.

탄력적이다
미래에 기존에 개발한 코드의 기능을 수정, 확대, 재활용해야 하는 상황이 종종 발생한다. 번햄은 "현재 필요한 사항과 미래에 필요할 수 있는 사항 모두를 염두에 둔 소프트웨어가 좋은 소프트웨어이다"고 강조했다. 물론 미래를 예측하기란 불가능하다. 그러나 그는 "최소한의 수정으로 미래에 필요한 사항을 수용할 수 있게끔 탄력적인 소프트웨어를 개발할 수 있다"고 덧붙였다.

익명의 웹 개발자는 "미래에 코드의 다른 부분은 망가뜨리지 않으면서 일부만 변경 또는 추가할 수 있는 코드가 좋은 코드"라고 말했다.

크리스토퍼 존슨은 스택 오버플로우에 "코드를 수정해보면, 그 코드가 좋은 코드인지 알 수 있다"는 글을 남겼다.
스택 익스체인지의 사용자인 마이클 라는 "신입 직원이 6개월 전 당신이 개발한 코드를 질문 없이 수정할 수 있어야 좋은 코드"라고 말했다.

관리할 수 있어야 한다
제아무리 좋은 코드라도 버그가 있기 마련이다. 모일란은 "누군가 버그를 수정해야 할 수 있어야 한다. 당신이 버그를 수정하는 장본인이 될 수 있으므로 쉽게 수정할 수 있도록 만들어야 한다"고 말했다.

'관리성'은 좋은 코드의 중요 속성 중 하나이다. 스택 익스체인지의 사용자인 gbn은 "어떤 코드이든 관리를 해야 한다. 따라서 필요 이상 관리가 어려워서는 안 된다"고 강조했다.

익명의 개발자는 (URL, 액세스 키, 데이터베이스 비밀번호 등)을 변경시키는 하드 코딩 값 등을 피해야 미래에 관리가 쉬워진다고 충고했다.

데이빗 래치밈(David Rachamim)은 쿼라에 "그냥 기능하는 코드와 좋은 코드의 차이점은 '관리성'"이라는 글을 남겼다.

제 기능을 해야 한다
마지막으로 좋은 소프트웨어 코드가 갖춰야 할 '명백한' 특징 하나가 있다. 익명의 웹 개발자는 "코드가 제 기능을 해야 한다"고 강조했다. 모일란은 "코드가 원래 목적한 기능을 하는 것이 가장 중요하다"고 말했다.

번햄은 "아무리 좋게 보이는 코드라도 제 기능을 못 하면 좋은 코드가 아니다"고 강조했다. editor@itworld.co.kr 


X