독서노트) 훌륭한 프로그래머 되는 법

part 1. you.write(code);

 

2장. 정돈된 코드 유지하기

- 두 명의 관객을 위해 코딩을 하라. 컴파일러와 동료 프로그래머.

 

3장. 코드 적게 쓰기

 

- 소프트웨어를 개선하는 최고의 방법 가운데 하나는 바로 코드를 제거하는 것이다.

- 각 줄의 코드마다 비용이 든다. 코드를 길게, 많이 쓸수록 유지 보수 비용은 높아진다.

- 코드가 많을수록 수정해야 할 부분도 많아진다. 즉 프로그램을 수정하기 어려워진다.

- 중복 코드는 특히 치명적이다. 하나의 버그를 고쳐도 다른 곳에 32개의 똑같은 작은 버그들이 남아 있을 수 있다.

 

- 불필요한 코드 중복은 사악하다. 

- 코드 일부를 복사하지 말자. 공통 함수에 모두 넣자. 다른 부분은 매개 변수를 사용하자.

- 중복을 발견하면 제거하라.

- 더 많은 줄의 코드가 더 좋은 소프트웨어를 의미하지는 않는다. 필요하지 않다면 코딩하지 말라. 적게 쓰고 그 대신 더 재미난 것을 찾으라.

 

4장. 코드 줄여 개선하기

- 코드 정리와 기능 변화는 별도의 커밋으로 이루어져야 한다.

- 가장 훌륭한 코드베이스에도 불필요한 코드는 만들어진다. 프로젝트가 클수록 더 많은 불필요한 코드가 존재한다. 이것은 실패의 징조가 아니다. 죽은 코드를 발견했음에도 아무런 조치도 취하지 않는 것이야말로 실패의 징조이다. 불필요한 코드를 찾아냈다면 즉시 제거해버리자.

 

5장. 코드베이스의 망령

- 프로그래머로서의 자질은 자신이 작성한 코드가 아닌, 그것을 대하는 태도와 작성하는 방식에 의해 결정된다.

보통의 프로그래머는 오랜 시간 동안 자신의 코드를 관리하지 않는 경향이 있다. 자신의 똥통에 뒹굴지 않고 남의 똥통에 뒬굴거나 똥을 쌀 새로운 곳을 찾는다. 참 대단하다. 심지어 애정 가득한 프로젝트도 흥미가 사라지면 방치하는 경향이 있다.

- 다른 사람들의 잘못된 코드에 대해 불평하는 것은 당연히 재미있다. 하지만 자신의 코드가 얼마나 잘못되었는지는 쉽게 잊어버린다.

 

6장. 경로 탐색하기

- 코드에 정통한 누군가와 함께 일한다면 그 점을 활용하라. 질문하기를 주저하지 말라. 할 수만 있다면 페어 프로그래밍을 하고, 자신의 작업을 검통해줄 것을 요청하라.

- 코드를 파악하는 가장 좋은 방법은 이미 코드를 파악하고 있는 사람의 도움을 얻는 것이다. 도움을 요청하길 주저하지 말라.

 

- 도움을 요청할 때는 언제나 공손하고 감사해야 한다. 합리적이고 적절한 질문을 하라. "제 숙제를 대신 해주실 수 있을까요?" 와 같은 질문을 통해서는 좋은 대답을 들을 수 없다. 상식적으로 행동하라. 질문하기에 앞서 구글을 통해 검색하라. 

 

- 자전거 타는 방법에 대한 책을 많이 읽을 수 있다. 하지만 실제 페달에 발을 올리고 자전거를 타보기 전까지는 실력이 향상되지 않는다. 균형을 잡는 방법에 대해 책을 며칠 읽기보다는 몇 번 직접 넘어져보는 과정을 통해 더 많은 것을 배울 수 있다.

코드를 읽는 것 역시 이와 같다. 코드를 올라타고, 운전해보고, 실수하며 떨어져봐야 코드베이스에 대해 알 수 있다.

 

- 코드를 배우는 가장 좋은 방법은 수정해보는 것이다. 그런 다음 실수를 통해 배우라.

 

- 코드를 작성하는 것이 읽는 것보다 쉽다. 많은 프로그래머들은 기존 코드를 읽고 이해하기 보다는 '이런 코드라니, 우습군' 하고 코웃음 치며 다시 만들어버리는 걸 선호한다. 이를 통해 더 깊이 있게 코드를 이해할 수 도 있겠지만, 수많은 불필요한 코드 변동, 시간 낭비, 새로운 버그를 초래한다.

 

7장. 똥통에서 뒹굴기

- 훌륭한 코드는 순수 예술이나 한 편의 시와 같다. 그 안에는 알아볼 수 있는 구조나 인지할 수 있는 운율, 적절히 조율된 박자, 일관성과 아름다움이 있다. 이런 코드는 읽을 때 즐겁고 함께 일할 때 행복하다. 슬프게도 언제나 그런 경우만 있는 것은 아니다.

 

- 스레드처럼 위험한 무기를 다루기 위한 자격증이 존재했으면 싶고, 그게 없다면 thread라는 글자 자체를 쓰지 못해도록 했으면.

 

- 조잡한 코드를 일부러 짜는 사람은 거의 없다는 점을 알아야 한다. 고약한 코드 중 몇몇은 그저 실력이 부족한 프로그래머가 짰을 뿐이다. 혹은 실력 있는 프로그래머에게도 컨디션이 좋지 않은 날이 있다.

- 나쁜 코드를 언제든 만날 수 있따는 마음의 준비를 하라.

 

- 외부에 노출하는 API는 깔끔하고 합리적인가?

- 자료형을 잘 고르고, 변수 명을 적절히 지었는가?

- 코드의 레이아웃을 정돈하여 일관성 있게 작성했는가?

- 객체들의 협업 구조가 보기에 간결하고 명확한가?

- 특정 기능을 구현하는 코드 부분이 어디에 있는지 쉽게 찾을 수 있는가?

 

- 시간을 지혜롭게 쓰라. 코드를 별로라고 생각할 수 있겠지만, 별다른 수정 없이도 몇 년 동안 적절히 작동했다면, 지금 수정하는 것은 적절하지 않을 수 있다. 이후에 훨씬 더 많은 부분을 수정해야 할 수도 있다.

- 전투 지역을 선택하라. 나쁜 코드를 수정하는 데 시간과 노력을 들여야 할지 주의 깊게 판단하라. 지금은 그대로 놔두는 게 실리적일 수도 있다.

- 간단한 수정이라도 좋다. 코드의 외관을 정리하라. 오해의 소지가 있는 변수 명을 적절하게 바꾸라. 복잡한 분기를 간단하게 바꾸라. 거대한 함수는 작은 함수로 나눠라.

- 코드 수정은 천천히, 주의 깊게 하라. 한 번에 하나씩 수정하라.

 

10장. 버그 사냥하기

 

- 실제로 지구상의 모든 프로그래머들이 소프트웨어를 디버깅하는 데는 연간 약 3,120억 달러에 달하는 엄청난 비용이 소요된다. (케임브리지 대학교 저지 경영 대학원의 연구 결과)

- 버그가 생긴 뒤에 고치기보다는 처음부터 버그가 생기지 않도록 적극적으로 예방하는 편이 훨씬 낫다.

- 섬세한 설계, 코드 검토, 페어 프로그래밍, 테스트 전략은 (버그 예방을 위한)가장 중요한 방법론들이다. 우리 개발자들은 모두 이런 방법들을 알고 있다고 믿는다. 하지만 이러한 전술을 채택할 만큼 부지런한가?

- 적절한 방법론을 채택해 버그 생성을 막으라. 빠르게 대충 작성한 코드의 품질이 높을 것이라는 기대는 하지 말라.

 

- 버그를 피할 수 있는 가장 좋은 충고는 믿기 힘들 정도로 '영리한(종종 복잡한 것과 동일시되는)' 코드를 만들지 말라는 것이다. Brian Kernighan은 다음과 같이 말했다. "디버깅이 코드 작성보다 두 배는 힘들다. 가능한 한도 내에서 최대로 '영리한' 코드를 작성할 경우, 정의에 따르면 디버깅하기 위해서는 2배로 영리해야 한다. 그러니 그 코드를 디버그할 만큼 똑똑할 수는 없다." 

- 마틴 파울러 역시 이렇게 말했다. "미련한 프로그래머는 컴퓨터가 이해할 수 있는 코드를 만들고, 좋은 프로그래머는 사람이 이해할 수 있는 코드를 만든다."

 

- assert와 로그(하찮은 print라 해도)는 강력한 디버깅 도구다. 종종 사용해보라.

 

- 이진 탐색 전략(디버깅 전략): 코드를 한 줄씩 단순히 따라가기 보다는 일련의 사건의 시작과 끝을 확인하라. 그런 다음에 문제 공간을 두 개로 나누고, 가운데 시점에서 코드가 괜찮은지 확인하라. 이 정보를 기초로 문제 영역을 절반으로 좁힐 수 있다. 이 과정을 반복하다 보면 곧 문제가 되는 부분에 도달할 수 있다. 이것은 O(n)보다 O(log n)하기 위한 해결책을 줄 수 있는 강력하고도 신속한 접근 방법이다.

 

- 때로는 기가 막히는 문제에 맞서 몇 시간 동안 씨름하다가 결국 아무 것도 얻지 못하기도 한다. 이럴 때는 아래 방법을 시도하라.

- 쉬어가기: 작업을 멈추고 코드에서 떨어져 있어야 할 때는 배우는 것은 매우 중요하다. 휴식을 통해 새로운 관점을 얻을 수 있고, 이를 통해 더욱 신중하게 생각할 수 있기 때문이다. 무턱대로 코드에 달려들기보다는, 문제에 대한 서술과 코드 구조를 생각해볼 수 있도록 휴식 시간을 가져보라. 산책을 하면서 자신을 키보드에서 잠시 떨어지게 만들라 (샤워를 하거나 화장실에 있을 때 '유레카'와 같은 순간을 얼마나 많이 맞이했는가? 필자에게는 끄와 같은 일이 매번 일어난다).

- 다른 사람에게 설명하기: 어떤 문제를 다른 사람에게 설명하다보면, 동시에 자신에게도 설명하게 되고, 문제를 해결하게 된다. 만약 주변에 사람이 없다면, 고무 오리 전략(rubber duck strategy)을 따를 수 있다. 책상에 놓여 있는 무생물에게 말을 걸면서 스스로에게 문제를 설명해보라.

 

11장. 테스트하기

- 소프트웨어 개발 과정을 개선하려면 빠른 피드백을 통해 문제 파악에 소모되는 시간을 줄여야 한다. 좋은 테스트 전략이란 바로 피드백 절차를 줄이는 데 있다. (중략) IDE가 타이핑할 때마다 문법 오류를 강조해줄 것이다. 이와 같은 속도로 테스트를 통해 확인한 오류를 보여준다면 좋지 않겠는가?

 

- 코드를 작성하면서 테스트를 같이 작성하라. 테스트 작성을 미루면 그만큼 테스트 효과가 줄어들 것이다. 코드가 어떻게 작동할지를 잊어버리거나, 극단적인 경우에 대한 테스트를 작성하지 못할 수도 있다. 미룰수록 피드백 절차는 더 늦어지고 덜 효과적이게 될 것이다.

- 나쁜 테스트는 부채가 될 수 있다. 

 

- 좋은 테스트의 특징

- 짧고 명확한 이름, 실패했을 때 무엇인지 쉽게 알 수 있다.

- 유지 보수가 가능하다. 작성은 물론 읽고 수정하기 쉽다.

- 수행에 오랜 시간이 걸리지 않는다.

- 최신 구현 코드에 맞춰져 있다.

- 특별한 설정이 필요 없다.

- 다른 테스트에 대한 의존성이 없다.

 

- 나쁜 테스트의 특징

- 때로는 성공, 때로는 실패

- 이상해 보이고, 읽거나 수정하기 어려움.

- 지나치게 큰 테스트

- 하나의 테스트 케이스에서 둘이 상을 수행

- 지나치게 상세하여 중구난방인 테스트

 

- "프로그램 테스트를 통해 버그의 존재를 확인할 수는 있지만, 버그가 없음을 확신할 수는 없다"

- 어떤 테스트도 완벽하지 않지만, 테스트의 존재를 통해 확신을 키울 수는 있다.

- trade-off. 확신을 얻기 위해 얼마나 많은 노력을 테스트 작성에 투자할 것인지의 문제다.

- 핵심은 간단하다. 작성해야 할 만큼 중요한 코드라면 테스트해야 할 만큼 중요한 것이다.

 

12장. 복잡도 다루기

 

13장. 두 개의 시스템에 대한 이야기

- 소프트웨어는 건강하지 못한 회사 구조와 개발 절차로 인해 잘못 설계될 수 있다.

- 좋은 설계는 상호 연결 구조나 컴포넌트 간 연결의 분량을 검토한다. 시스템의 개별 부분은 단독으로 작동할 수 있어야 한다. 밀착 결합은 테스트를 하기 어렵게 만든다.

- "개발자들은 설계에 대해 주인의식과 개인적 의무감을 지니고 있었다"

- 설계 품질을 반드시 유지해야 한다. 이는 개발자들이 의무감을 가지고 진지하게 대할 때에만 가능하다.

 

  

part 2. 연습을 통해 완벽해진다.

 

14장. 소프트웨어 개발이란

 

- 소프트웨어 개발은 예술이다.

- 뛰어난 코드를 작성하고자 하는 프로그래머는 좋은 취향과 미적 감각을 지녀야 한다.

- 소프트웨어 개발 절차 중 많은 부분이 예술 작품을 창조하는 것과 유사하다. 그 절차란 다음과 같다.

- 창조적: 상상력이 필요하다. 만들고자 하는 코드에 대한 비전, 방법에 대한 계획이 있어야 한다. 때로는 엄청난 독창성이 필요로 한다.

- 미학적: 좋은 코드의 톡징은 우아함, 아름다움, 균형에서 찾을 수 있다.

- 기계적.수동적

- 팀 기반: 예술가는 걸작을 완성할 때까지 밤낮으로 스튜디오에 노예처럼 앉아 있지만은 않는다.

(지휘자-오케스트라, 작곡가-연주가, 건축설계사-시공자)

 

- 소프트웨어 개발은 과학이다.

- 엄격함

- 체계화

- 통찰력

- 좋은 소프트웨어 개발은 머릿속에 떠오른 첫 번째 코드를 뱉어내는 카우보이식 코딩이 아니다. 신중하고, 심사숙고하며, 정확한 노력의 산물이다.

 

- 소프트웨어 개발은 스포츠다.

- 팀워크

- 훈련

- 규칙

 

- 소프트웨어 개발은 아이들 놀이다.

- 학습

- 단순함

- 즐기기

 

- 소프트웨어 개발은 집안일이다.

- 청소하기: 문제를 찾아내 해결해야 한다. 청소부로서 다른 사람에게 즐겁지 않은 작업을 넘겨버리지 말고 책임을 져야 한다.

- 보이지 않는 곳에서 작업하기

- 유지 보수

 

- 코드에 대해 집안일과 같은 단순한 작업을 할 때 행복한가? 아니면 화려만 작업만을 원하는가?

 

15장. 규칙 가지고 놀기

- 모호하게 구두로 전해지는 팀의 규칙에 의존하지 말라. 무언의 규칙을 명백하게 만들고 코딩 문화를 다스리라.

- 필자 회사의 규칙 3개

- 간결하게 하라

- 머리를 쓰라

- 변하지 않는 것은 없다.

 

 

16장. 간결하게 쓰기

- 설계가 간결하다면, 빠르고 명확하게 묘사할 수 있고, 쉽게 이해할 수 있다.

- 간결한 설계의 목적은 오용을 막는 것이다. 간결한 API를 보여주기 위해 복잡한 부분을 내부에 포함하고 있을 수 있다.

- 간결한 설계는 가능한 한 작은 크기로 이루어진다. 그보다 더 작을 수 없는 수준의 작은 크기 말이다.

- 일관성이야말로 간결한  코드로 이끄는 주역이다. 일관성은 명확성으로 이어진다.

- 평범하지만 명백한 방식으로 납들할 만한 코드를 작성하라. 유지 보수하는 프로그래머들이 고마워할 것이다.

- 증상 부위가 아닌 근본 원인에 대해 버그 수정을 적용하라. 반창고를 덧붙이면서 겉으로 드러나는 증상만 고치는 것은 간결한 코드로 이끌어주지 않는다.

- 너무 이른 최적화를 피하라. "지나치게 조급한 최적화는 프로그래밍에서 모든 악의 근원이다"

 

 

17장. 머리 쓰기

- 우연하게라도 지나치게 복잡한 설계를 하지 않도록 하라. 

- 코드를 소유하고 그에 대해 책임을 지라. 결정을 내림에 있어 능동적이 되라. 기존 코드 패턴에 의문이 든다면 그것을 변경해야 할지를 고민해 보라.

- 두뇌는 멋진 것이다: 천억 개의 신경 세포, 우리가 알고 있는 가장 강력한 컴퓨터, 놀라운 기억력, 복잡한 화학 컴퓨팅 및 스토리지 시스템

 

18장. 변하지 않는 것은 없다.

- 코딩 시 겁쟁이 같은 접근법을 취한다면 목표에 이르지 못한다. "내가 작성한 게 아냐. 쓰레기 같아. 이걸로는 그 어떤 것도 하고 싶지 않아. 이 코드를 가능한 한 적게 파헤칠거야" 와 같은 태도를 취해서는 안 된다.

- 때로는 광범위하게 코드를 수정하는 것보다는 ,자주 조금씩 검증할 수 있는 수정을 하는 편이 더 낫다.

- 자동화된 테스트는 코드 수정에 대한 확신을 심어줄 수 있는 귀중한 안전 도구다.

- 기술부채는 프로젝트 계획에 포함 되어야 한다. 부채의 상당수가 그대로 잊히고 곪아가도록 버려두기보다는 개발 일정표에 넣어 작업 대상으로 만들라.

 

19장. 코드 재사용 사례

 

20장. 효과적인 버전 관리

 

21장. 골키퍼 있다고 골 안 들어가랴

 

22장. 동결된 코드의 신기한 사례

- 파레토의 법칙을 기억하라. 종종 IT 프로젝트에서는 마지막 20%의 노력이 들어가는 부분에서 전체 시간의 약 80%가 소모된다.

- 파레토의 법칙: 전체 결과의 80%가 전체 원인의 20%로부터 일어나는 현상.

 

 

23장. 제발 저를 배포해주세요

 

part 3. 개인적인 일로 받아들이기

 

24장. 배움을 사랑하며 살기

- 배우기 위해 가르쳐라. 배움의 가장 효과적인 방법 중 하나는 가르쳐 보는 것이다.

- 아인슈타인은 말했다. "간단하게 설명할 수 없다면, 충분히 잘 이해하지 못했다는 증거이다"

- 내게 말하면, 나는 잊어버릴 것이다. 나에게 보여주면, 나는 기억할 것이다. 나를 참여시키면, 나는 이해할 것이다. -공자

 

 

25장. 테스트 기반 개발자

 

26장. 도전 즐기기

 

27장. 부진 피하기

- 이력서를 채우려는 목적으로 새롭고 자극적인 어떤 것을 배운 마지막 시점은 언제였는가? 자신의 능력 이상을 해낸 마지막 시점은 언제였는가? 자신의 일에서 불편함을 느낌 마지막 시점은 언제였는가? 즐겁게 하는 어떤 것을 발견한 마지막 시점은 언제였는가? 다른 프로그래머에 비해 자신이 초라하게 느껴져 그들로부터 배우려는 의욕이 고무된 마지막 시점은 언제였는가?

 

- 자신의 기술들을 유지하기란 어려운 일이라는 점에 주의하라. 이를 위해서는 스스로를 불편한 상황에 두어야 하고 많은 노력을 쏟아 부어야 한다.

 

- 프로젝트의 새로운 부분을 담당하라. 많이 알지 못하는 부분을 담당하라. 당장은 생산성이 떨어질 수 있으나, 코드에 대한 더 폭넓은 지식을 얻을 수 있고 새로운 것들을 배울 수 있다.

 

- 더 많은 사교 활동을 하라. 괴짜와도 평범한 사람과도 시간을 보내라.

 

 

28장. 윤리적인 프로그래머

- 코더들의 질은 기술적 기량보다는 태도에 따라 결정된다.

- 정직하고 신뢰할 수 있는 사람이 되라. 수용적인 마인드로 모든 사람들을 대하라. 다만 속으로는 틀렸다고 생각하면서 겉으로만 동의하는 척하지 말라. 이것은 정직하지 못할 뿐더러 유용하지도 않다. 건설적인 의견 충돌과 합리적인 논의는 코드 설계를 결정할 때 더 나은 방향으로 이끌어 줄 수 있다.

 

- 작업하는 과정에서 생각했던 것보다 더 오랜 시간이 걸린다면 가능한 빨리 이를 피력하라. 윤리적은 프로그래머는 체면을 차리기 위한 목적으로 가만히 있지 않는다...책임을 다하기 위해 최선을 다하라.

 

- 피곤에 절은 프로그래머는 누구에게도 쓸모가 없다. 초과 작업을 하지 말라. 자신의 한계를 인정하라.

 

29장. 언어에 대한 사랑

 

30장. 프로그래머의 자세

 

part 4. 일 끝내기

 

31장. '더 열심히'보다는 '더 현명하게'

- 이메일, 문서 작업 등 온종일 사소한 행정 업무들을 해치우느라 중요한 업무를 처리하는 흐름에 방해받지 말고, 한데 모아두었다가 하루 중 특정 시각에 한꺼번에 처리하라.

- 한 번에 하나씩 작업을 수행하라.

- 특정 작업을 자주 해야할 경우 컴퓨터가 당신을 위해 일하도록 스크립트를 짜라.

- 말도 안되는 수준의 업무를 요청받을 수 있다. 그 요청이 의무적인 수준을 넘어서고 있음을 명확히 표현하여, 사람들이 그런 상황을 자주 기대하지 않도록 하라. 거넞ㄴ한 프로젝트는 연속된 야근을 요구하지 않는다.

 

32장. 끝나야 끝나는 것

- 업무를 할당받았다면, 일을 시작하기 전에 더 작고 이해할 만한 부분으로 일을 누눠라. 많은 사람이 급하게 코드부터 작성하기 시작하거나, 한 걸음 물러서서 일을 어떻게 해결할지 파악하지도 않은 채 설계부터 하기 시작한다.

- 커다란 작업을 더 작고 잘 아는 일로 나눠라. 더 정확하게 진행 상황을 판단할 수 있을 것이다. 다만 지나치게 자잘한 단위로 일을 나누지 않도록 주의해야 한다.

-언제나 작업의 최소 단위를 파악하라.

- 완료 상태를 정의해야 한다. 완료 시점을 말할 수 없다면 시작하지 말아야 한다.

- 무엇이 성공인지 파악하기 전까지는 코딩작업을 일절 시작하지 말라. 아직 모르겠다면, '완료' 상태가 무엇인지 정의하는 것에서부터 첫 번째 작업을 시작하라. 대부분의 경우 이를 정의하는 것은 프로그래머가 아니다. PO, 시스템 설계자, 고객 혹은 최종 사용자가 결정한다.

- 필요 이상으로 많은 작업을 수행하지 말라. '완료' 상태까지만 작업하라. 그런 뒤에는 중지하라. 완벽하지 않아도 된다.

 

33장. 교훈 얻기

- 다른 프로그래머에게 의무감을 가지라. 그들과 주기적으로 작업 경과를 확인하라. 

- 문제에 대해 설명하다가 다른 누구도 아닌 자신에게 어떻게 수정할 것인지를 설명하게 되는 일이 빈번하다.

 

part 5. 사람의 일

 

34장. 사람의 힘

- 훌륭한 프로그래머들 주변에 의도적으로 머물라.

 

35장. 생각이 중요하다.

- 지금까지의 경력을 통틀어 최선을 다해 일하도록 필자의 의욕을 북독아주었던 유일하면서도 가장 중요한 요솔소는 의무감이었다. 그리고 그 의무감의 대상은 바로 위대한 프로그래머들로 구성된 필자의 팀이었다. 다른 훌륭한 프로그래머들 덕분에 필자 역시 더 나은 프로그래머가 될 수 있었다. 이는 매우 간단하지만 강력한 개념이다. 

- 작업의 품질을 보증하기 위해 다른 프로그래머들에 대한 의무감을 가지면, 코드 품질을 환상적으로 높일 수 있다.

- 다른 사람이 자신의 코드를 볼 것임을 인지하게 되면서, 적당히 코드를 짜려는 심리에 대한 저항심을 키우고 전반적인 코드의 품질을 개선할 수 있었다.

 

 

36장. 말하기!

 

37장. 선언문

 

38장. 코드 찬가

 

39장. 태도가 핵심이다.

 

부록 국내 개발자 이야기

A. 더 나은 프로그래머 되는 법 - 염재현

- 훌륭한 팀 플레이어가 되기 위한 노력을 게을리하지 마십시오.

- 다른 사람과 대화를 할 때 짓는 표정도 소통 능력에 영향을 끼칩니다. 명확한 정보 전달이 되도록 말 혹은 글로 자신의 생각을 표현할 수 있어야 합니다. 알게 된 지식을 다른 사람과 나누어 영향력을 키우는 것 또한 중요합니다.

- 코드를 리뷰 받는 일도 중요합니다. 남들이 못 보도록 코드를 숨겨두지 마시고, 코드를 보여주고 리뷰를 받으십시오. 강력한 회사 정책이 있지 않으면 코드 리뷰를 잘 해주지 않으려는 경우도 있을 것입니다. 그럴 때에는 끈질기게 그그러나 정중하게 단신의 혜안이 필요하다며 약간의 칭찬을 곁들여 여쭤보십시오. 성격상 아쉬운 소리를 하기 어렵더라도 필요할 때는 해야 합니다.

- 나와 코드를 분리하세요. 내 코드에 가해지는 비판이 나에게 하는 것이라 생각하지 마세요 (의역)

- (주니어) 팀에서 인정받는 좋은 방법 중 하나는 팀의 코드베이스를 파악하고 특히 직급 높은 엔지니어가 작성한 코드를 수정하는 것입니다. 이 과정에서 코드 작성자에게 질문을 해야 하는 경우가 많이 생깁니다. 코드를 읽다 생긴 의문을 풀고자 질문을 하다 보면, 의문에 적절한 이유가 있는 경우도 있는 반면 이유가 없는 경우도 적지 않음을 알게 됩니다. ...당시와 지금의 상황이 달라지다 보니 현 시점에서 고치고 싶어지는 경우가 많습니다. 이런 일을 맡아 해보면 많은 것을 배울 수 있고 스스로 커가는 과정을 지켜볼 수 있습니다....시니어로서는 누군가 자신이 작성했던 코드를 수정하려 질문을 하면 회피하기가 쉽지 않습니다.

 

B. 개발자의 삶에 해볼 만한 네 가지 TODO - 이철혁

 

1. 자신이 아침형 인간인지 저녁형인간인지 확인하기

 

언제나 시간이 부족하다고 생각했다. 실제로 시간이 부족하기도 했지만, 주변 개발자들이 다들그러했듯 자주 밤에 일을 했다. 밤에 일하는 것이 낮에 하는 것보다 집중이 잘 되는 것처럼 느껴지기도 했다. 밤을 새우는 경우도 적지 않았다. 밤을 새우면 다음날 몸이 많이 힘들었지만 그런 생활을 당연하게 여겼다. 하지만 저녁에 일을 하는 것은 그다지 생산성이 높지 않았다. 저녁 식사 후 일을 한다 해도 식사 시간만큼 제외하고 바로 일을 하는 것이 아니었기 때문이다.

짐 콜린스의 위대한 기업의 선택을 보면 아문센의 얘기가 나온다. 인류 최초로 남극점에 도달한 탐험가 아문센은 날씨가 좋을 때 무리하지 않고, 나쁠 때도 멈추지 않고 매일 20마일을 꾸준히 걸었다고 한다. 저자는 이것이 바로 아문센이 남극 탐험에 성공한 이유라고 말한다. Work-Life Balance 중요하지만 Work-Work Balance 즉 일들 사이의 균형도 중요하다는 말이다.

내가 시간을 쓰는 방식이 맞는지 확신을 할 수 없었기에, 시간을 효율적으로 쓰기 위한 노력을 해보기로 했다. 지금이 아니면 날아가버릴 것만 같은 영감이 떠올라 밤을 새우는 게 아니라면, 무조건 잠을 자고 일어나 일을 하기로 했다. 그러다 보니 밤을 새는 것은 극히 예외적인 일이 되었다. 그리고 당시 유행하던 아침형 인간을 적용해보기로 했다. 생활 패턴을 바꾸는 것은 개발 중인 프로젝트의 방법론을 변경하는 것 이상의 큰 고통이었다. 처음 몇 주간은 무척 힘들었지만, 앞으로의 인생에서 내게 맞는 생활 패턴을 찾는 것이 중요하다는 생각에 참고 견뎠다. 새벽에 일어나는 것에 점차 익숙해지면서 새벽이 밤보다 더 효율적으로 일할 수 있는 시간임을 알게 되었다. 일하기에 적합한 시간을 찾기 위해 나는 매달 30분씩 기상 시간을 앞당겼고, 최종적으로 3시 30분에 일어나게 되었다. 이후 나의 하루는 2시간의 자유 시간과 함께 시작되었다. 즉 2시간 동안 영어 학원 강의를 듣고도 여유로운 출근을 할 수 있었다. 그때 나는 밤에 작업 능률이 잘 오른다는 생각이 잘못된 것임을 깨달았다.

밤에 일하는 게 효율적이라 생각했는데 실제로는 그렇지 않다면? 이럴 땐 생활 패턴을 바꿔보는 것도 좋을 것 같다.

2. 자신만의 시간 찾기

최근 개발자의 환경에 대한 투자가 이루어지면서 개발자의 처우 또한 개선되고 있다. 개발자에대한 사회의 인식 또한 좋은 방향으로 나아지고 있다. 하지만 야근과 철야를 밥 먹듯이 한다는기존의 이미지에서 여전히 벗어나지 못하는 것 같다. 실제로 그런 환경에서 일하는 분들도 많을 것이다. 좋은 환경에서 일하는 분들도 프로젝트 일정에 따라 서비스의 장애로 인해 예정에없던 시간을 허비하는 경우가 있을 것이다. 외국어나 다른 것을 배우고 싶어 수강 신청을 했다가도, 회사 일로 몇 번 빠지다 보면 다니기가 어려워지기 마련이다.

아침형 인간이 되기로 마음먹은 데는 다음과 같은 이유가 가장 컸다. 개발자가 꾸준히 시간을낼 수 있는 것은 저녁이 아니라 오전이나 점심시간이라는 사실 때문이었다. 1년 넘게 아침에피트니스 트레이닝을 받는 동안, 갑작스러운 조사가 있었던 단 한 번의 경우를 제외하고는 트레이닝을 빼먹은 적이 없었다. 저녁 시간이었다면 이렇게 하지는 못했을 것이다.

나의 경우처럼 자신에게 맞는 생활 습관을 찾기 위한 시도를 해보기를 제안한다. 다른 사람에게 방해받지 않고 자신의 효율이 극대화되는 자신만의 시간을 꼭 찾았으면 좋겠다.

3. 함께 하기

개발자는 정말 많은 글을 읽는다. 개발 서적이나 문서뿐만 아니라 디버깅과 개발을 위해 많은웹문서를 읽는다. 나의 경우 개발 분야 외 다른 분야의 책들을 많이 못 읽었다는 생각에 다양한분야의 책을 골고루 읽어보려 했다. 혼자서는 잘 안 될 것 같아 약간의 강제성을 갖기 위해 함께 읽는 방법을 선택했다. 온전히 낼 수 있는 시간이 일요일 오전밖에 없어 그 시간에 진행되는모임을 찾아봤지만 적당한 모임을 찾을 수 없었다. 그래서 아예 같은 목적을 가진 사람들과 함께 책 모임을 만들었다. 여기서 격주로 2권의 책을 읽고 토론을 하였다.

1년이 지나자 100권이 넘는 책을 읽을 수 있었다. 혼자였다면 절대 하지 못했을 일이었다. 단순히 읽는 것에 그치지 않고 이야기를 나누고 리뷰를 하게 된 것 역시 중요한 성과였다.

새로운 것을 배우거나 토론을 하거나 혹은 책을 정해놓고 읽는 것과 같이 혼자 하기 힘든 일들이 있다. 그럴 땐 다른 사람과 함께 하면 된다. 내가 있는 장소와 내가 원하는 시간에 모임이 없다면? 직접 만들어서라도 시작해보기 바란다. 작은 노력이 큰 성과로 돌아올 것이다.

 

4. 사외 프로젝트를 진행하며 많은 사람을 만나기

C. 훌륭한 개발자가 되는 법 - 조대협

 

D. 일일 커밋: 프로그래밍 생활백서 - 진유림