IT/모바일
저자: 임백준 / 루슨트 테크놀로지스
필자가 근무하고 있는 회사의 직원들에게 지난 3년은 견디기 힘든 시간이었다. 많은 사람들이 "정리해고"의 폭풍 속에서 하나 둘 씩 짐을 꾸려서 떠날 수밖에 없었기 때문이다. 13만명에 달하던 직원이 (분사를 포함해서) 3만 5000명으로 줄어드는 과정을 견디는 일은 고통스러운 일이었다. 정리해고의 규모가 방대했기 때문에 떠나는 이의 쓸쓸한 모습에 자기 자신의 모습이 겹치는 것은 이상한 일이 아니었다.
하지만 그러한 풍경이 루슨트에 국한된 일은 아니었다. 인터넷 거품의 붕괴라고 불리는 극단적인 상황은 당시 어디에나 편재하는 보편적인 현상이었다. 90년대 말의 IT 호황을 경험한 사람들 입장에서는 좀처럼 믿기 어려운 일이었지만 사람들이 새로운 현실에 적응하는데 까지는 그렇게 오랜 시간이 필요치 않았다. 불과 얼마 전까지만 해도 "스톡옵션"과 "승진"을 말하며 화려한 비상을 꿈꾸던 사람들이 정리해고의 흉흉한 소식에 조바심을 느끼며 촉각을 곤두세우기 시작했다. "더 나은" 조건을 찾아서 직장을 수시로 옮기던 사람들은 이제 "더 나쁘지" 않은 조건을 유지하는 일에 힘을 기울이기 시작했다.
최악의 순간을 벗어난 것으로 보이는 상황에서도 사람들은 여전히 몸을 낮춘 채 해고의 칼날을 피하기 위한 노력을 멈추지 않았다. 그것을 이상하게 여기는 사람은 아무도 없었다. 마치 "동그란 네모"라는 말과 다름없는 "고용 없는 성장(jobless recovery)"이라는 형용 모순이 (적어도 미국에서는) 신문의 경제면을 채웠고, 당분간 "고용자 시장(employer"s market)"이 계속될 것이라는 전망은 수시로 언급되었다.
특히 미국의 IT 시장에서는 인도나 중국의 값싼 프로그래머에게 일을 맡기는 개념을 지칭하는 "해외 아웃소싱" 바람이 불어서 현지에 존재하는 프로그래머들의 목을 조였다. 이와 같은 현상은 어제의 일이 아니라 "최악의 상황"이 이미 종료되었다는 2004년 오늘의 풍경이 되어가고 있다.
프로그램의 "관리"
이러한 풍경 속에서 피고용자들의 노동 강도가 강화되는 것은 (바람직하지는 않지만) 당연한 결과이다. 이와 같은 노동 강도의 강화가 프로그래머들에게 있어서는 단순히 새로 개발해야 하는 소프트웨어의 분량이 늘어나는 것을 뜻하는데 머무르지 않는다. 그것은 동시에 다른 사람이 개발한 소프트웨어를 맡아서 관리해야 하는 일이 늘어나는 것을 의미하기도 하기 때문이다. 소프트웨어를 관리하는 일은 흔히 "유지 보수"라고 불리기도 하는데 의욕이 넘치는 프로그래머들은 "개발"에 비해서 창조적 긴장감이 떨어지는 "관리"를 따분한 일로 여기기도 한다.
다른 사람이 작성한 프로그램을 관리하는 일은 다른 사람이 키우던 강아지를 대신 키우는 일과 비슷하다. 강아지를 새로 맡은 사람은 그 강아지의 습관이나 성격을 알지 못한 채 정기적으로 밥을 주고, 건강 검진을 하고, 산책을 하고, 배설물을 치워주고, 잠자리를 갈아주어야 한다. 새 주인은 강아지가 언제 아플지, 무엇을 좋아하고 무엇을 싫어하는지, 어떤 버릇이 있는지 등을 알지 못하기 때문에 아무 일을 하지 않을 때조차 신경이 쓰이고 정력이 소모된다. 강아지가 겁에 질려서 마구 짖을 때 무엇이 잘못되었는지 알 수 없기 때문에 애를 태우며 헛손질을 하게 된다.
다른 사람이 작성한 프로그램을 관리하는 일도 그렇다. 사용자 필드에서 치명적인 버그가 보고되었을 때 도대체 무엇이 잘못되었는지 금방 알 수 없기 때문에 애를 태우며 헛손질을 하게 되는 것이다.
필자가 프로그래밍을 하면서 상상하는 것은 바로 그러한 상황이다. 내가 작성한 코드를 다른 누군가가 유지보수하게 됐을 때 그는 강아지의 습관과 성격을 쉽게 파악할 수 있을 것인가. 강아지가 겁에 질려서 마구 짖어댈 때 그 이유를 쉽게 알 수 있을까. 그가 나의 코드를 읽을 때 편안한 자세로 쉽게 읽어나갈 수 있을까. 그는 전 주인이었던 나를 쉴 새 없이 원망할까 아니면 강아지를 반듯하게 잘 길러낸 나를 칭찬해 줄까. 그가 물론 필자의 코드를 편안한 자세로 쉽게 읽을 수 있기를 희망하고, 강아지를 바르게 키운 필자를 칭찬해 주기를 희망한다. 그와 같은 희망을 이루기 위해서 강조하는 방법론이 바로 "소설처럼 읽히는 프로그램 작성하기"이다.
코딩 관습과 가독성
프로그래밍 세계에는 흔히 "코딩 관습(coding convention)"이라는 것이 있다. 이 관습은 프로그램에서 변수의 이름을 정할 때는 이렇게, 줄을 바꿀 때는 저렇게, 한 줄에 80개 이상의 문자를 담지 말 것, 설명문을 반드시 달아 놓을 것 등의 관습적 "규칙"을 정한 일종의 약속이다. 그것이 관습적인 이유는 그러한 규칙을 따르지 않는다고 해서 프로그램이 컴파일되지 않는 것은 아니기 때문이다. 즉, 코딩 관습은 지키면 좋고 지키지 않으면 어쩔 수 없다.
그렇지만 일정한 규칙을 규정한 코딩 관습을 강제로 관철시키기 위해서 프로그램 소스를 일정한 모습으로 변환시키는 툴마저 존재한다는 사실을 생각해 보면 코드의 겉모습을 동일하게 유지하는 것은 대개 어려운 일이 아니다.
한 가지 흥미로운 것은 많은 사람들이, 심지어 경험이 풍부한 고급 프로그래머 중에서조차 코드의 "가독성"을 이러한 코딩 관습을 통해서 통일시킬 수 있는 코드의 겉모습으로 착각한다는 사실이다. 그렇지만 코딩 관습이 보장해 줄 수 있는 것은 가독성이라는 복합적인 목표에서 단지 한 가지 측면에 불과하다. 실제 소설을 생각해 보면 쉽다.
소설의 가독성은 결코 인쇄 상태의 수준과 레이아웃 편집의 유려함만으로 결정되지 않는다. 인쇄 상태가 양호하고 레이아웃이 깔끔하면 읽기에 편한 것은 사실이지만 그것은 가독성을 결정짓는 "충분조건"이 될 수 없기 때문이다.
소설이 소설로서 읽히기 좋은 것은 무엇보다도 글의 내용이 나름의 무게를 잃지 않으면서 독자의 상상력을 끊임없이 자극할 때이다. 내용이 튼튼한 소설은 30년 전에 누런 갱지에 인쇄된 글이라 해도 눈을 즐겁게 하지만, 그렇지 않은 소설은 아무리 포장을 하고 덧칠을 해도 "눈으로 마시는" 수면제 역할을 할 뿐이다.
"소설처럼 읽히는 프로그램"이 갖추어야 하는 가장 큰 덕목은 그래서 프로그램의 "구조"가 잘 짜여 있는 것이다. 절차적(procedural) 언어든 객체지향(object-oriented) 언어든 상관이 없다. 프로그램이 쉽게 읽히기 위해서는 함수, 객체, 혹은 알고리즘을 정의하고 있는 논리의 구조가 명쾌하고 간결해야 한다.
구조가 잘 짜여진 프로그래밍
예를 들어서 몇 개의 독립적인 클래스를 정의함으로써 알고리즘이 수행하는 업무의 흐름을 명쾌하게 정의할 수 있는 곳에서 하나의 거대한 함수를 이용한다고 생각해보자. 거대한 함수는 여러 가지 상황을 처리하기 위해서 복잡한 인수(parameter)를 받아들일 뿐만이 아니라 수많은 if else 혹은 switch 구문을 가지고 있어야 할 것이다.
『리팩토링(Refactoring), Addison-Wesley, 1999』이라는 책으로 잘 알려진 마틴 파울러는 지나치게 복잡하거나 긴 함수를 보면 일단 의심을 해볼 필요가 있다고 지적했다. 이 책에서 그가 지적하고 있는 것은 주로 "성능"이나 "유지 보수"의 측면이지만 일단 지나치게 긴 함수는 가독성도 떨어질 수밖에 없다.
사람들이 흔히 강조하는 코딩 관습이란 이러한 프로그램의 "구조"가 올바르게 구성된 다음의 이야기일 뿐이다. 구조가 바로 서지 않으면 코딩 관습은 실제로 별 의미가 없다. 그렇긴 하더라도 변수의 이름을 성의 없이 정하거나, 들여쓰기가 엉망으로 되어 있거나, 불필요하게 복잡한 알고리즘을 구사하거나 하면 코드를 읽기가 힘들기 때문에 바람직하지 않다(힘이 든다기보다는 짜증이 난다). 일례로 필자는 회사에서 동료들과 "코드 리뷰"를 하다가 다음과 같은 구문에 대해서 가독성이 떨어진다고 지적하여 몇몇 동료들의 반발을 사기도 했다.
프로그래밍 언어의 문법을 알면 이 코드가 의미하는 바를 이해하는 것이 어렵지는 않다. 하지만 필자의 의견으로는 이 문장보다 다음과 같은 코드가 훨씬 쉽게 읽힌다.
이것은 "구조"의 문제가 아니라 순전히 "문체"의 차이, 즉 "코딩 관습"의 문제일 뿐이지만 이렇게 사소한 차이가 프로그램의 곳곳에 쌓이다 보면 전체적인 가독성에 눈에 뜨일 만한 차이를 불러일으킨다. 프로그래밍 실력이 뛰어난 사람일수록 압축적이고 은밀한 코드를 작성하고픈 충동을 자주 느끼게 되는데, 그러한 욕구를 억제하여 의미를 쉽게 전달하는 절제된 코드를 작성하는데 초점을 맞추는 것이 "소설처럼 읽히는 프로그램" 만들기의 두 번째 요체에 해당한다.
작가 같은 프로그래머
끝으로 중요한 것은 "설명문달기"이다. 코드의 곳곳에 설명문을 달아야 한다는 말은 프로그래머가 프로그래밍 세계에 입문하는 첫 날부터 하루도 빠지지 않고 듣는 이야기일 것이다. 그것은 코딩 관습에서도 중요한 주제에 해당하고, 프로그래밍 경험이 없는 관리자조차 프로그래밍을 하는 부하 직원들을 향해서 자신 있게 말 할 수 있는 몇 개 되지 않는 "프로그래밍 기법"에 해당한다.
하지만 "설명문 달기"처럼 자주 강조되면서도 전혀 지켜지지 않는 일도 흔하지 않을 것이다. 설명문을 달아놓았다고 해도 그나마 하나마나 한 이야기를 형식적으로 적어놓는 경우도 드물지 않다. 그런 설명문은 차라리 없는 편이 낫다고 볼 수 있다.
"소설처럼 읽히는 프로그램" 만들기에서 설명문은 자기가 기르던 강아지를 남에게 맡기게 되었을 때 절실한 심정으로 건네는 당부의 말처럼 적혀 있어야 한다. 프로그램을 구성하는 가장 핵심적인 알고리즘, 개략적인 구조, 남겨진 부분, 주목할 필요가 있는 부분, 개선의 여지 등을 자상하게 적어 놓되 읽는 사람의 집중력이 흩어지지 않도록 지나치게 지엽적인 부분에 대한 설명은 피하는 것이 좋다(말은 쉽게 하지만 이렇게 하는 것이 결코 쉬운 일은 아니다. 그렇기 때문에 설명문을 잘 작성하는 사람이야말로 진정한 프로그래밍 고수에 해당한다. 프로그래밍 실력은 형편없는데 설명문만 잘 달아놓을 수 있는 사람은 결코 존재하지 않는다).
다시 강조하자면, "소설처럼 읽히는 프로그램"을 구성하는 세 가지 요체는 프로그램의 "구조", "코딩 관습", 그리고 "설명문"이다. 이 세 가지가 조화를 이루고 있는 코드는 소설보다 재미있다. 필자는 가끔 그런 코드를 작성하는 프로그래머를 만나면 그를 프로그래머라기보다는 "작가"라고 불러야 하는 것은 아닐지 고민하곤 한다. "실력"을 뽐내기보다는 "따뜻한 마음"이 돋보이는 컴퓨터 언어의 소설가라고 부르고 싶은 것이다.
출처 : 마이크로소프트웨어 2004년 3월호
필자가 근무하고 있는 회사의 직원들에게 지난 3년은 견디기 힘든 시간이었다. 많은 사람들이 "정리해고"의 폭풍 속에서 하나 둘 씩 짐을 꾸려서 떠날 수밖에 없었기 때문이다. 13만명에 달하던 직원이 (분사를 포함해서) 3만 5000명으로 줄어드는 과정을 견디는 일은 고통스러운 일이었다. 정리해고의 규모가 방대했기 때문에 떠나는 이의 쓸쓸한 모습에 자기 자신의 모습이 겹치는 것은 이상한 일이 아니었다.
하지만 그러한 풍경이 루슨트에 국한된 일은 아니었다. 인터넷 거품의 붕괴라고 불리는 극단적인 상황은 당시 어디에나 편재하는 보편적인 현상이었다. 90년대 말의 IT 호황을 경험한 사람들 입장에서는 좀처럼 믿기 어려운 일이었지만 사람들이 새로운 현실에 적응하는데 까지는 그렇게 오랜 시간이 필요치 않았다. 불과 얼마 전까지만 해도 "스톡옵션"과 "승진"을 말하며 화려한 비상을 꿈꾸던 사람들이 정리해고의 흉흉한 소식에 조바심을 느끼며 촉각을 곤두세우기 시작했다. "더 나은" 조건을 찾아서 직장을 수시로 옮기던 사람들은 이제 "더 나쁘지" 않은 조건을 유지하는 일에 힘을 기울이기 시작했다.
최악의 순간을 벗어난 것으로 보이는 상황에서도 사람들은 여전히 몸을 낮춘 채 해고의 칼날을 피하기 위한 노력을 멈추지 않았다. 그것을 이상하게 여기는 사람은 아무도 없었다. 마치 "동그란 네모"라는 말과 다름없는 "고용 없는 성장(jobless recovery)"이라는 형용 모순이 (적어도 미국에서는) 신문의 경제면을 채웠고, 당분간 "고용자 시장(employer"s market)"이 계속될 것이라는 전망은 수시로 언급되었다.
특히 미국의 IT 시장에서는 인도나 중국의 값싼 프로그래머에게 일을 맡기는 개념을 지칭하는 "해외 아웃소싱" 바람이 불어서 현지에 존재하는 프로그래머들의 목을 조였다. 이와 같은 현상은 어제의 일이 아니라 "최악의 상황"이 이미 종료되었다는 2004년 오늘의 풍경이 되어가고 있다.
프로그램의 "관리"
이러한 풍경 속에서 피고용자들의 노동 강도가 강화되는 것은 (바람직하지는 않지만) 당연한 결과이다. 이와 같은 노동 강도의 강화가 프로그래머들에게 있어서는 단순히 새로 개발해야 하는 소프트웨어의 분량이 늘어나는 것을 뜻하는데 머무르지 않는다. 그것은 동시에 다른 사람이 개발한 소프트웨어를 맡아서 관리해야 하는 일이 늘어나는 것을 의미하기도 하기 때문이다. 소프트웨어를 관리하는 일은 흔히 "유지 보수"라고 불리기도 하는데 의욕이 넘치는 프로그래머들은 "개발"에 비해서 창조적 긴장감이 떨어지는 "관리"를 따분한 일로 여기기도 한다.
다른 사람이 작성한 프로그램을 관리하는 일은 다른 사람이 키우던 강아지를 대신 키우는 일과 비슷하다. 강아지를 새로 맡은 사람은 그 강아지의 습관이나 성격을 알지 못한 채 정기적으로 밥을 주고, 건강 검진을 하고, 산책을 하고, 배설물을 치워주고, 잠자리를 갈아주어야 한다. 새 주인은 강아지가 언제 아플지, 무엇을 좋아하고 무엇을 싫어하는지, 어떤 버릇이 있는지 등을 알지 못하기 때문에 아무 일을 하지 않을 때조차 신경이 쓰이고 정력이 소모된다. 강아지가 겁에 질려서 마구 짖을 때 무엇이 잘못되었는지 알 수 없기 때문에 애를 태우며 헛손질을 하게 된다.
다른 사람이 작성한 프로그램을 관리하는 일도 그렇다. 사용자 필드에서 치명적인 버그가 보고되었을 때 도대체 무엇이 잘못되었는지 금방 알 수 없기 때문에 애를 태우며 헛손질을 하게 되는 것이다.
필자가 프로그래밍을 하면서 상상하는 것은 바로 그러한 상황이다. 내가 작성한 코드를 다른 누군가가 유지보수하게 됐을 때 그는 강아지의 습관과 성격을 쉽게 파악할 수 있을 것인가. 강아지가 겁에 질려서 마구 짖어댈 때 그 이유를 쉽게 알 수 있을까. 그가 나의 코드를 읽을 때 편안한 자세로 쉽게 읽어나갈 수 있을까. 그는 전 주인이었던 나를 쉴 새 없이 원망할까 아니면 강아지를 반듯하게 잘 길러낸 나를 칭찬해 줄까. 그가 물론 필자의 코드를 편안한 자세로 쉽게 읽을 수 있기를 희망하고, 강아지를 바르게 키운 필자를 칭찬해 주기를 희망한다. 그와 같은 희망을 이루기 위해서 강조하는 방법론이 바로 "소설처럼 읽히는 프로그램 작성하기"이다.
코딩 관습과 가독성
프로그래밍 세계에는 흔히 "코딩 관습(coding convention)"이라는 것이 있다. 이 관습은 프로그램에서 변수의 이름을 정할 때는 이렇게, 줄을 바꿀 때는 저렇게, 한 줄에 80개 이상의 문자를 담지 말 것, 설명문을 반드시 달아 놓을 것 등의 관습적 "규칙"을 정한 일종의 약속이다. 그것이 관습적인 이유는 그러한 규칙을 따르지 않는다고 해서 프로그램이 컴파일되지 않는 것은 아니기 때문이다. 즉, 코딩 관습은 지키면 좋고 지키지 않으면 어쩔 수 없다.
그렇지만 일정한 규칙을 규정한 코딩 관습을 강제로 관철시키기 위해서 프로그램 소스를 일정한 모습으로 변환시키는 툴마저 존재한다는 사실을 생각해 보면 코드의 겉모습을 동일하게 유지하는 것은 대개 어려운 일이 아니다.
한 가지 흥미로운 것은 많은 사람들이, 심지어 경험이 풍부한 고급 프로그래머 중에서조차 코드의 "가독성"을 이러한 코딩 관습을 통해서 통일시킬 수 있는 코드의 겉모습으로 착각한다는 사실이다. 그렇지만 코딩 관습이 보장해 줄 수 있는 것은 가독성이라는 복합적인 목표에서 단지 한 가지 측면에 불과하다. 실제 소설을 생각해 보면 쉽다.
소설의 가독성은 결코 인쇄 상태의 수준과 레이아웃 편집의 유려함만으로 결정되지 않는다. 인쇄 상태가 양호하고 레이아웃이 깔끔하면 읽기에 편한 것은 사실이지만 그것은 가독성을 결정짓는 "충분조건"이 될 수 없기 때문이다.
소설이 소설로서 읽히기 좋은 것은 무엇보다도 글의 내용이 나름의 무게를 잃지 않으면서 독자의 상상력을 끊임없이 자극할 때이다. 내용이 튼튼한 소설은 30년 전에 누런 갱지에 인쇄된 글이라 해도 눈을 즐겁게 하지만, 그렇지 않은 소설은 아무리 포장을 하고 덧칠을 해도 "눈으로 마시는" 수면제 역할을 할 뿐이다.
"소설처럼 읽히는 프로그램"이 갖추어야 하는 가장 큰 덕목은 그래서 프로그램의 "구조"가 잘 짜여 있는 것이다. 절차적(procedural) 언어든 객체지향(object-oriented) 언어든 상관이 없다. 프로그램이 쉽게 읽히기 위해서는 함수, 객체, 혹은 알고리즘을 정의하고 있는 논리의 구조가 명쾌하고 간결해야 한다.
구조가 잘 짜여진 프로그래밍
예를 들어서 몇 개의 독립적인 클래스를 정의함으로써 알고리즘이 수행하는 업무의 흐름을 명쾌하게 정의할 수 있는 곳에서 하나의 거대한 함수를 이용한다고 생각해보자. 거대한 함수는 여러 가지 상황을 처리하기 위해서 복잡한 인수(parameter)를 받아들일 뿐만이 아니라 수많은 if else 혹은 switch 구문을 가지고 있어야 할 것이다.
『리팩토링(Refactoring), Addison-Wesley, 1999』이라는 책으로 잘 알려진 마틴 파울러는 지나치게 복잡하거나 긴 함수를 보면 일단 의심을 해볼 필요가 있다고 지적했다. 이 책에서 그가 지적하고 있는 것은 주로 "성능"이나 "유지 보수"의 측면이지만 일단 지나치게 긴 함수는 가독성도 떨어질 수밖에 없다.
사람들이 흔히 강조하는 코딩 관습이란 이러한 프로그램의 "구조"가 올바르게 구성된 다음의 이야기일 뿐이다. 구조가 바로 서지 않으면 코딩 관습은 실제로 별 의미가 없다. 그렇긴 하더라도 변수의 이름을 성의 없이 정하거나, 들여쓰기가 엉망으로 되어 있거나, 불필요하게 복잡한 알고리즘을 구사하거나 하면 코드를 읽기가 힘들기 때문에 바람직하지 않다(힘이 든다기보다는 짜증이 난다). 일례로 필자는 회사에서 동료들과 "코드 리뷰"를 하다가 다음과 같은 구문에 대해서 가독성이 떨어진다고 지적하여 몇몇 동료들의 반발을 사기도 했다.
x = (a > b) ? a : b프로그래밍 언어의 문법을 알면 이 코드가 의미하는 바를 이해하는 것이 어렵지는 않다. 하지만 필자의 의견으로는 이 문장보다 다음과 같은 코드가 훨씬 쉽게 읽힌다.
if (a > b)
{
x = a;
}
else
{
x = b;
}이것은 "구조"의 문제가 아니라 순전히 "문체"의 차이, 즉 "코딩 관습"의 문제일 뿐이지만 이렇게 사소한 차이가 프로그램의 곳곳에 쌓이다 보면 전체적인 가독성에 눈에 뜨일 만한 차이를 불러일으킨다. 프로그래밍 실력이 뛰어난 사람일수록 압축적이고 은밀한 코드를 작성하고픈 충동을 자주 느끼게 되는데, 그러한 욕구를 억제하여 의미를 쉽게 전달하는 절제된 코드를 작성하는데 초점을 맞추는 것이 "소설처럼 읽히는 프로그램" 만들기의 두 번째 요체에 해당한다.
작가 같은 프로그래머
끝으로 중요한 것은 "설명문달기"이다. 코드의 곳곳에 설명문을 달아야 한다는 말은 프로그래머가 프로그래밍 세계에 입문하는 첫 날부터 하루도 빠지지 않고 듣는 이야기일 것이다. 그것은 코딩 관습에서도 중요한 주제에 해당하고, 프로그래밍 경험이 없는 관리자조차 프로그래밍을 하는 부하 직원들을 향해서 자신 있게 말 할 수 있는 몇 개 되지 않는 "프로그래밍 기법"에 해당한다.
하지만 "설명문 달기"처럼 자주 강조되면서도 전혀 지켜지지 않는 일도 흔하지 않을 것이다. 설명문을 달아놓았다고 해도 그나마 하나마나 한 이야기를 형식적으로 적어놓는 경우도 드물지 않다. 그런 설명문은 차라리 없는 편이 낫다고 볼 수 있다.
"소설처럼 읽히는 프로그램" 만들기에서 설명문은 자기가 기르던 강아지를 남에게 맡기게 되었을 때 절실한 심정으로 건네는 당부의 말처럼 적혀 있어야 한다. 프로그램을 구성하는 가장 핵심적인 알고리즘, 개략적인 구조, 남겨진 부분, 주목할 필요가 있는 부분, 개선의 여지 등을 자상하게 적어 놓되 읽는 사람의 집중력이 흩어지지 않도록 지나치게 지엽적인 부분에 대한 설명은 피하는 것이 좋다(말은 쉽게 하지만 이렇게 하는 것이 결코 쉬운 일은 아니다. 그렇기 때문에 설명문을 잘 작성하는 사람이야말로 진정한 프로그래밍 고수에 해당한다. 프로그래밍 실력은 형편없는데 설명문만 잘 달아놓을 수 있는 사람은 결코 존재하지 않는다).
다시 강조하자면, "소설처럼 읽히는 프로그램"을 구성하는 세 가지 요체는 프로그램의 "구조", "코딩 관습", 그리고 "설명문"이다. 이 세 가지가 조화를 이루고 있는 코드는 소설보다 재미있다. 필자는 가끔 그런 코드를 작성하는 프로그래머를 만나면 그를 프로그래머라기보다는 "작가"라고 불러야 하는 것은 아닐지 고민하곤 한다. "실력"을 뽐내기보다는 "따뜻한 마음"이 돋보이는 컴퓨터 언어의 소설가라고 부르고 싶은 것이다.
출처 : 마이크로소프트웨어 2004년 3월호
TAG :
이전 글 : C# 팁 & 테크닉
최신 콘텐츠