Effective Programming

2016년 09월 01일 | Jeremy

인트로

프로그래머의 여덟 단계

죽은 프로그래머
작성한 코드가 끝까지 살아남아서 프로그래머가 죽고 난 후에도 사용된다. 예) 다익스트라, 도널드 커누스, 앨런 케이
성공적인 프로그래머
널리 알려져 있으며 자신의 코드를 이용해 하나의 비지니스를 새롭게 창조한 프로그래머다. 대부분의 프로그래머들이 꿈꾸는 단계가 바로 이 단계다. 예) 빌 게이츠, 존 카맥, DHH
유명한 프로그래머
프로그래머 집단에서 잘 알려져 있다. 잘 알려진 대형 기술 회사나 작지만 영향력 있는 회사, 아니면 작은 규모의 스타트업에서 근무하고 있을 것이다.
일하는 프로그래머
소프트웨어 개발자로서 성공적인 경력을 보유하고 있다. 주변의 동료들은 당신을 존경한다. 당신이 근무한 회사는 모두 실적이 향상되고, 당신의 존재에 의해 뭔가 분위기가 향상된다. 하지만 그런 당신이 그 다음으로 갈 수 있는 곳은 어디인가?
평균적인 프로그래머
자신이 결코 위대한 프로그래머가 아니라는 사실을 깨닫긴 하지만 충분히 좋은 실력을 갖추고 있는 프로그래머다.
아마추어 프로그래머
코딩을 좋아하는 사람들이다. 그런 경향은 겉으로 드러난다. 이들은 장래가 촉망되는 학생이나 인턴일 수도 있고, 오픈소스 프로젝트에 기여하는 사람들일 수도 있고, 아니면 그저 “재미를 위해” 여가 시간에 흥미로운 애플리케이션이나 웹사이트를 제작하는 사람일 수도 있다. 그들이 작성하는 코드는 미래의 가능성과 열정을 보여준다.
알려지지 않은 프로그래머
전형적인 프로그래머의 단계다. (보통) 유능하긴 하지만 별다른 특징이 없는 사람들이다. 대부분 큰 회사에 근무한다. 그들이 하는 일은 그저 직업일 뿐이며 개인적인 삶의 목표와 별로 상관이 없다.
나쁜 프로그래머
프로그래밍에 어울리는 기술이나 능력이 없는 상태에서 프로그래밍을 수행하는 직업을 갖게 된 사람들이다. 그들이 건드리는 것은 무엇이든 다른 동료 프로그래머들에게 고통과 통증을 안겨준다.

쓰지 않으면서 쓰기

사람들은 효과적으로 글을 쓰는 방법을 익히면서 평생을 보낸다. 이 과정에는 속임수가 없다. 글을 쓰는 능력은 돈을 주고 살 수도 없다. 스스로 열심히 익히는 방법 외에는 다른 방법이 없다.
바로 그렇기 때문에 글을 쓰는 것을 두려워하는 사람들은 블로그를 시작해야 한다.
그것은 일종의 운동과 같다. 아무리 몸매가 엉망인 사람이라도 매주 몇 번씩 운동을 열심히 하다 보면 몸매가 차츰 나이지기 마련이다. 자신의 블로그에 짧은 글이나마 일주일에 몇 차례씩 글을 올리면 글쓰기 능력도 차츰 나아진다. 글을 쓰는 것이 무서워서 글쓰기를 회피하면 엉망인 몸매로 평생을 살아가야 한다.

좋은 프로그래밍의 원리

그것은 언제나 당신의 잘못이다

세상이 온통 잘못됐다고 비난하기 전에 우리 자신을 바꾸려고 노력해야 한다.
겸손한 프로그래머가 되는 방법의 핵심은 어떤 상황에 처하더라도 결국 모든 잘못의 뿌리는 자기가 작성한 코드라는 사실을 인정하는 것이다. “이건 내 잘못이야. 반드시 원인을 파악하겠어.”라고 말하는 데 일말의 주저함이 없어야 한다.

주석 없이 코딩하기

r = n / 2;
while (abs(r - (n / r)) > t) {
    r = 0.5 * (r + (n / r));
}
System.out.println("r = " + r);

위 코드 자체를 읽기는 어렵지 않지만, 무슨 일을 하는 코드인지 알기 어렵다. 그렇다면 약간의 주석을 달아보자.

// 뉴튼 랩슨(Newton-Raphson) 방법을 이용한 n의 제곱근 근사
r = n / 2;
while (abs(r - (n / r)) > t) {
    r = 0.5 * (r + (n / r));
}
System.out.println("r = " + r);

코드에 아무런 주석도 달지 않는 극단과 한 줄의 코드마다 대형 서사시에 해당하는 주석을 삽입하는 또 다른 극단 사이에서 적절한 중심을 잡는 주석은 때론 필요하다. 하지만 굳이 주석을 다는 대신, 아래와 같이 간단한 리팩토링을 수행하는 편이 낫다.

private double SquareRootApproximation(n) {
    r = n / 2;
    while (abs(r - (n / r)) > t) {
        r = 0.5 * (r + (n / r));
    }
    return r;
}
System.out.println("r = " + SquareRootApproximation(r));

컴파일러를 위한 글쓰기에만 집중하자. 코드 자체를 최대한 명확하게 작성하고, 정말 어쩔 수 없는 경우에 한해서만 주석을 다는 것이다.

고무 오리 문제 해결법

질문을 적절하게 구성하는 것 자체가 해답을 낳는 경우가 종종 있는 이유는 뭘까?
일단 질문을 던지기 시작하는 것은 실제로 자신의 문제를 스스로 디버깅하는 데 도움을 준다.
옆에 코딩 친구가 없다면 고무오리 문제 해결법을 통해 자신의 문제를 스스로 해결할 수 있다.

당신의 팀은 엘리베이터 테스트를 통과할 수 있는가?

소프트웨어 개발자로서 우리는 너무나 많은 시간을 매우 세밀한 내용이라는 진흙 속에서 뒹굴면서 보내기 때문에 코드 자체를 위한 코드를 작성하는 함정에 빠지기 쉽다. 명확한 초점과 중심을 잡아주는 기둥이 없으면 우리는 코드를 둘러싸고 있는 문맥을 놓칠 수 밖에 없다. 바로 이런 이유로 팀원들이 시금석으로 삼을 수 있는 프로젝트의 비전을 명확하게 밝히는 것이 중요하다. 일단 그런 비전을 잘 밝혀 놓았다면 팀 내부의 직원들이 낯선 사람들과 더불어 “엘리베이터 테스트”를 수행했을 때 모두 그 테스트를 통과할 수 있을 것이다. 즉, 낯선 사람에게 자기가 무슨 일을 하고 있고, 자신이 하는 일이 어떤 사람에게 왜 중요한지 등을 60초 안에 설명할 수 있을 것이다.

자신의 팀원들이 자기 일과 연결 지을 수 있는 그럴듯한 비전 설명이 언제나 존재해야 한다.
자신의 팀원들이 엘리베이터 테스트를 무난히 통과할 수 있게 만들어야 하는 것이다.

팀이 함께 일하도록 만들기

그들이 어떤 말을 하든 그것은 결국 사람과 관련된 문제다

어떤 프로젝트를 성공하게 하거나 실패하게 하는 것은 언제나 절차와 사람에 관련된 문제다. 매일 수행하는 일의 절차 말이다. 아키텍트가 어떤 살마들이고, 관리자가 어떤 사람들이며, 프로그래밍 팀에서 어떤 사람들과 함께 일하는가를 비롯해 의사소통을 어떻게 하고, 그리고 가장 중요하게는 절차나 사람과 관련된 문제가 발생했을 때 그것을 어떻게 해결하는가가 가장 중요하다. 모든 것이 결국 기술의 문제이고 나머지 다른 것들은 어떻게 해서든 대충 해결할 수 있을 거라고 생각하는 것은 모든 문제의 원천이다.

당신의 팀이 얼마나 많은 줄의 코드를 작성할 것인가?
어떤 종류의 소프트웨어를 만드는가?
동료 프로그래머들을 좋아하는가?

당신은 동료 팀원들을 거의 개인적인 수준에서 좋아하고 있는가? 당신의 동료들을 직업적인 관점에서 존중하고 있는가? 만약 다른 회사로 자리를 옮긴다면 현재의 동료들을 그곳으로 불러들이고 싶은가? 서로의 영감이 자극되는 토의를 하는가, 아니면 서로 옥신각신하며 의사 진행을 방해하는 데만 열중하는 논쟁을 벌이는가? 할 수만 있다면 구명보트에서 떨어뜨리고 싶은 팀원이 있는가?

짝 프로그래밍 대 코드 리뷰

짝 프로그래밍의 장점은 그것이 갖는 효과가 즉각적이라는 점이다. 동료 프로그래머가 바로 옆에 앉아 있는 경우에는 그를 무시하는 것이 불가능하다. 이에 비해 코드 리뷰는 두 사람이 물리적으로 같은 공간에 있어야 하는 짝 프로그래밍보다 훨씬 도입하기가 수월하다. 당신이 작성한 코드를 또 다른 한 쌍의 눈이 어떤 식으로든 보도록 만들기만 하면 두 기법 중에서 어느 것을 선택하는가는 그다지 중요하지 않다.

회의: 일이 죽으러 가는 장소

어떤 회의라도 한 시간을 넘기면 안 된다. 넘기면 사형이다
모든 회의에는 명확하게 정의된 목표가 있어야 한다
회의에 참석하기 전에 회의에서 필요한 일을 하라
회의에 참석하는 것을 선택사항으로 만들어라
회의를 마무리할 때 해야 할 일을 정리하라

썩은 사과를 다루는 방법

스티브는 팀 안에 썩은 사과가 있음을 나타내는 징후를 몇 가지로 정리했다.

그들은 동료로부터 배우려고 노력하기보다 자신의 무지를 감추기 위해 노력한다. “내가 설계한 내용을 말로 설명할 수는 없어. 하지만 그것이 제대로 동작한다는 사실은 말할 수 있어.”
그들은 지나치게 프라이버시에 집착한다. “다른 사람이 내 코드를 검토할 필요는 없어.”
경계선을 긋기 좋아한다. “다른 사람이 내 코드에 있는 버그를 수정할 수 없어. 지금은 내가 너무 바빠서 수정할 수 없지만 다음 주 쯤에 내가 직접 버그를 수정하겠어.”
그들은 팀에서 내린 결정에 대해 투덜거리고, 오랜 시간이 지난 뒤에도 낡은 논의를 다시 꺼낸다.
팀원들이 동일한 한 사람에 대해 정기적으로 독설이나 불만을 토로한다. 소프트웨어 개발자들은 대개 직접적으로 불만을 표하는 경우가 잘 없으므로 그런 소리가 귀에 들려온다면 문제가 있는지 여부를 다른 사람들에게 물어봐야 한다.
팀의 활동에 참여하지 않는다. 내가 일하던 프로젝트의 마감일이 이틀 앞으로 다가왔을 때 어느 개발자가 하루 휴가를 쓴다고 말한 적이 있다. 이유는? 가까운 근교에 있는 도시에서 진행되는 남성복 할인행사에 가보고 싶다고 했다. 이것은 그가 팀과 제대로 섞이지 못하고 있음을 나타내는 뚜렷한 증거에 해당한다.