훌륭한 프로그래머 되는 법 - O'Reilly

Chapter 27. 부진 피하기

실천 방안

자신의 기술을 유지하기 위해서는 스스로를 불편한 상황에 두어야 한다.
안전지대 밖으로 자신을 밀어내고 변화시키는 방법을 몇가지 소개한다.

• 동일한 도구만 사용하는 습관을 멈추라. 단지 배우는 것만으로도 삶이 더 편안해질 수 있는 더 좋은 도구들이 있을 것이다.
  • 소스코드 정적 분석 툴
  • 유닛 테스트 툴
  • Diff 툴
• 모든 문제에 대해 동일한 프로그래밍 언어를 적용하는 것을 그만두라. 단지 호두를 깨기 위해 쇠망치를 쓰고 있는 상황일 수도 있다.
  • 쉘 스크립트 : 자동화 등
  • 파이썬 : 각종 자동화 및 문자열 처리, 간단한 알고리즘 테스트 등
  • 하스켈, 스칼라 : 알고리즘 테스트, 함수형으로 생각하기
• 다른 OS를 사용해보라. 적절하게 사용하는 방법을 익히라. 좋아하지 않는 OS일지라도 짬을 내어 장단점을 파악해보라.
  • OS X, Linux
• 다른 텍스트 편집기를 사용해보라.
  • Visual Studio vs Mono Developer
  • Sublime Text vs Visual Studio COde
  • Vi vs Emacs
• 키보드 단축키에 대해 알아보고, 작업 흐름에 어떤 영향을 주는지 확인해보라. 마우스를 사용하지 않도록 의식적으로 노력해보라.
  • Visual Studio 에디터 단축키 학습 필요
• 새로운 주제에 대해 알아보라. 현재로서는 알아야 할 필요가 없는 주제에 대해 알아보라. 예를 들어 수학적 지식이나 정렬 알고리즘에 대해 깊게 알아보라.
  • 머신 러닝 : 텐서플로우 스터디 재개
  • 통계학
  • 컴퓨터 비전 다시 보기
• 개인적인 프로젝트를 시작하라. 그렇다. 소중한 여가 시간의 일부를 괴짜스럽게 할애하라. 오픈 소스로 게시하라.
  • MemorizeWord 작업 재개
  • HTML5 게임 엔진 리서치
• 프로젝트의 새로운 부분을 담당하라. 많이 알지는 못하는 부분을 담당하라. 당장은 생산성이 떨어질 수 있으나, 코드에 대한 더 폭넓은 지식을 얻을 수 있고 새로운 것들을 배울 수 있다.
• 새로운 언어를 배우라. 프로그래밍 언어를 말하는 것이 아니다. 작업하는 부분에 대해 일본어로 가르쳐주는 오디오북을 들어보라.
  • 영어, 일본어, 중국어
• 책상 위를 재배치하라! 새로운 조명 아래에서의 작업 방식을 살펴보라.
• 새로운 활동을 시작해보라. 그것은 자신의 학습 상황을 기록하는 블로그일 수도 있다. 취미에 더 많은 시간을 들이라.
  • 블로그 재개
• 운동을 시작하라. 헬스클럽에 가입하거나 달리기를 시작하라.
• 더 많은 사교 활동을 하라. 괴짜와도 평범한 사람과도 시간을 보내라.
  • 기찬팀 활동 재개
  • 프로그래머들의 모임을 알아보자.
• 식단 조절을 고려해보라. 혹은 더 일찍 잠자리에 들라.

Chapter 31. ‘더 열심히’보다는 ‘더 현명하게’

현명하게 재사용하라

이미 라이브러리가 있거나 어딘가의 코드를 재활용할 수 있는 상황에서 직접 코드를 작성하지 말라.
만약 자신의 시스템에 통합해야 한다면 퍼사드 패턴을 사용하라.

다른 사람의 일로 만들라

어떤 작업을 진행하는 방법에 대해 이미 다른 사람이 알고 있다면, 그 일을 직접 해결하려 들지 말라.

해야 하는 것만 하라

리팩토링이나 유닛 테스트를 모든 메서드에 대해 항상 적용해야할 필요는 없다.
전장을 잘 선택해야 한다.

거칠더라도 빠르게 해결하라

여러 설계 방안 가운데 어떤 것을 선택해야 할지 결정할 수 없을때는, 최선택을 골라내기 위해 심사숙고하느라 많은 시간을 소모하지 말라.
스파이크 솔루션으로 불과 몇 분 만에 더 적절한 해답을 얻어낼 수 있다.
스파이크 솔루션들을 작성할 때에는 적절한 시간 내에서 설계 및 작성이 가능한지 테스트하라.
코드에 대한 수정과 생성을 빠르게 되돌릴 수 있도록 버전 관리 도구를 사용하라.

우선순위를 설정하라

작업 목록의 우선순위를 설정하라. 가장 중요한 일을 먼저 하라.

정말 필요한 것은 무엇인가

새로운 업무가 할당될 때는 지금 당장 필요한 일인지부터 확인하라.
굳이 필요하지 않은 상황에서 롤스로이스 수준으로 고급스러운 것을 만들지 말라. 업무 요구사항이 그런 것을 원한다 해도, 되돌아보고 실제 요구되는 것인지 확인하라.
초기부터 지나치게 많은 코드를 작성하는 행동은 위험하다. 파레토 법칙에 따르면 처음 의도한 구현 가운데 20% 정도만으로도 요구되는 결과의 80%를 얻을 수 있다.

한 번에 하나씩

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

작고 간결하게 유지하라

코드와 설계를 가능한 한 작고 간결하게 유지하라. 그렇지 않으면 이후 유지 보수해야 하는 코드가 늘어날 뿐이다.
작고 명확한 코드가 큰 코드보다 훨씬 고치기 쉽다.

문제를 미루고 쌓아두지 말라

어려운 일을 미뤄두지 말라.
현명한 방법은 더 일찍 일을 시작하고 문제가 작을 떄 그것에 직면하는 것이다. 초기에 작은 코드들을 통합하고 이후 발생하는 변경들을 자주 통합하는 것이 더 쉽다.

자동화하라

한 번 이상 반복해야 하는 일이 있다면, 그것을 수행하는 스크립트를 작성하라.

오류 방지

오류를 더 빨리 발견하라. 이를 위해서 다음과 같은 사항들을 고려하라.

• 빨리 그리고 자주 고객에게 제품을 보여주라. 그러면 잘못된 제품을 만들고 있는지 아닌지를 빠르게 알아낼 수 있다.
• 다른 사람들과 코드 설계에 관해 토론하라. 구조를 세우기 위한 더 나은 방법을 더 빨리 찾을 수 있다. 피할수만 있따면 나쁜 코드를 작성하는 일에 노력을 들이지 말라.
• 작고 이해 가능한 범위에서 코드를 리뷰하라.
• 처음부터 유닛 테스트를 작성하라. 오류에 발목 잡히기 전에 자주 유닛 테스트를 실행하라.

의사소통하라

의사소통을 더 잘할 수 있는 방법을 배우라. 모호하지 않고 확실히 이해하기 위해 적절한 질문을 하는 방법을 배우라.

지쳐 나가떨어지지 말라

몇 시간에 걸친 어리석은 업무로 자신을 불태우지 말라. 건전한 프로젝트는 연속된 야근을 요구하지 않는다.

강력한 도구

항상 업무 흐름을 가속화해줄 새로운 도구를 찾으라.

Chapter 32. 끝나야 끝나는 것

아직 다 안됐어요?

개발자가 이 간단한 질문에 대답하기 위해 필수적인 사항은 바로 완료상태란 어떤 것인지, 그리고 완료상태에 얼마나 가까운지를 현실적으로 파악하는 것이다. 이를 통해 의사소통이 가능해진다.
이와 같은 질문을 피하는 것은 게으른 작업에 대한 변명이거나, 사전 예측과 계획이 전무한 발로 하는 코딩의 반증이다. 즉 체계적이지 않다는 말이다.

• 멈출 때를 모르는 탓에 그들은 필요 이상으로 더 많은 일을 한다.
• 일이 완료된 상태가 언제인지를 모르는 탓에 끝냈다고 생각되는 일조차 완결 짓지 못한다. 그로 인해 나중에 일을 다시 끄집어내어 빠진 것을 확인하고 보강해야 한다. 이런 식으로는 코드 작성이 매우 느려질 뿐더러 어려워진다.
• 코드에서 다듬어야 할 부분을 잘못 선택하고 명확한 목표를 전혀 알지 못한다. 시간만 낭비할 뿐이다.
• 지나치게 열심히 일하는 개발자는 결국 더 많은 일을 하게 될 뿐이다. 충분히 잘 수도 없을 것이다.

거꾸로 개발하기 : 분해

완료 상태를 정의하기 위한 첫 번째 단계는 작업 내용을 정확히 파악하는 것이다. 엄청난 업무를 할당받았다면 일을 시작하기 전에 더 작고 이해할 만한 부분으로 일을 나누도록 하라.

커다란 작업을 더 작고 잘 아는 일로 나누라. 더 정확하게 진행 상황을 판단할 수 있을 것이다.

이와 같은 분해 작업은 어렵지만 그만큼 중요한 일이다. 어렵다고 미루는 일이 없도록 하라. 초기에 분해 작업을 수행하지 않으면, 작업의 막바지에 이른 상황에서 집중하지 못한 상태로 수행하게 될 것이다.

언제나 작업의 최소 단위를 파악하라. 단지 프로젝트의 거대한 목표만을 파악하고 있어서는 안된다.

완료 정의하기

어떤 일을 하고 있든 간에 그만두어야 할 시점을 파악하라.
이를 위해서는 완료 상태를 정의할 필요가 있다.

완료(done) 상태를 정의해야 한다.

그만둘 때를 결정하지 않는다면 필요 이상으로 작업하게 될 것이다.
무엇이 성공인지 파악하기 전까지는 코딩 작업을 일절 시작하지 말라. 아직 모르겠다면, 완료 상태가 무엇인지 정의하는 것에서부터 첫 번째 작업을 시작하라.
그 이후에만 작업을 시작하라. 어디로 향하는지 확실히 알아야만 집중할 수 있고 명확한 방향을 향해 작업할 수 있다.

완료 시점을 말할 수 없다면 시작하지 말아야 한다.

완료 상태의 기준은 다음과 같아야 한다.

명확성

명확하고 구체적이어야 한다. 구현해야 할 모든 기능, 추가 혹은 확장해야 할 모든 API, 수정해야 할 특정 오류를 목록화 한다.

가시성

모든 주요 관련자들이 성공 기준을 확인하도록 하라.

실현 가능성

완료 기준을 주의 깊게 정의하라. 실현 불가능한 완료 상태를 정의하는 것은 무의미하다.

그냥 실행하라

완료 상태를 정의해야만 집중적으로 작업을 수행할 수 있다. 완료 지점까지만 작업하라. 필요한 것보다 더 많은 일을 하지 말라.
코드가 충분하다면 그만 멈추라. 완벽하지 않아도 된다.

필요 이상으로 많은 작업을 수행하지 말라. 완료 상태까지만 작업하라. 그런 뒤에는 중지하라.

Chapter 33. 교훈 얻기

불모지 개발

그 어떤 개발자도 혼자가 아니다.
자신을 감시하라. 자신감으로 충만한 나머지 도움을 요청하지 않는 일이 없도록 하라.

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

산 아래 서서

소프트웨어 개발은 거대한 산을 등반하는 것과 같다.
산을 올라가기 전 우선 한 발짝 물러서서 경로를 계획해야 한다.

문제에 직면했을 때, 이를 해결하기 위한 한 가지 이상의 접근법을 고려해야 한다. 그런 다음 작업에 착수해야 한다.

Chapter 34. 사람의 힘

탁월한 프로그래머가 되고 싶다면 탁월한 프로그래머 사이에 의식적으로 매일 머물러야 한다.
이는 단순하지만 심오한 방법으로, 자신의 기술과 자세를 개선할 수 있는 확실한 방법이다.
훌륭한 프로그래머들이 있는 환경에 스스로를 담금으로써 다음과 같은 결과물을 얻을 수 있다.

• 확산되는 열정
• 영감을 주는 동기부여
• 전염되는 책임감

훌륭한 프로그래머를 찾아내고 그들 속에 자신을 담그라. 좋은 코드에 관해 고민하고 제대로 작성하려는 사람들을 의식적으로 탐색하라.
좋은 프로그래밍 습관 및 태도에 있어서 긍정적 강화를 즐길 수 있다. 이를 통해 성장을 독려받게 될 것이고, 취약한 부분을 개선하기 위한 도전을 하게 될 것이다.
그러므로 반드시 가장 훌륭한 프로그래머들을 찾아 그들과 함께 일하라. 그들과 함께 설계하라. 그들과 함께 페어 프로그래밍하라. 그들과 어울리라.

무엇을 해야 하는가

훌륭한 프로그래머들로부터 다음과 같은 점을 관찰하라

• 문제에 대해 어떻게 생각하고 해결하는가?
• 문제의 원인을 찾아가는 경롤르 어떻게 계획하는가?
• 어려운 상황에서 어떤 태도를 취하는가?
• 특정 문제에 집중할지 여부를 어떻게 파악하는가? 언제 쉬는가? 다른 접근법을 시도할 때는 언제인가?
• 자신만 모르는 그들만의 특별한 코딩 기법이나 기술은 무엇인가?

전문가에 대해 파악하라

관리자들은 종종 깨어있는 모든 시간을 프로젝트에 투자하는 직원을 프로그래밍 영웅으로 간주한다. 하지만 대부분의 경우 그것은 능력 부족을 나타내는 표식일 뿐이다.
전문가들은 일을 쉬워보이게 하고 제 시간에 일을 끝낸다.

Chapter 35. 생각이 중요하다

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

개발 절차에 코드의 품질에 대한 의무감을 부여하는 간단한 방법이 있다. 그 규칙이란 모든 코드를 두 명 이상이 검수한 후에 소스 관리 도구에 체크인하는 것이다.
다른 사람이 자신의 코드를 볼 것임을 인지하게 되면서, 적당히 코들르 짜려는 심리에 대한 저항심을 키우고 전반적인 코드의 품질을 개선할 수 있었다.
다만, 모든 개발자들이 동의해야 한다.

다른 사람이 코드를 읽고 품평하리라는 것을 알고 나면 좋은 코드를 짜고 싶은 마음이 더 커진다.

다음 단계

의무감을 높이기 위해 다음 단계들을 고려할 수 있다.

• 의무감은 좋은 것이라는 의견에 동의하라. 의무감을 갖는 데 전념하라.
• 의무감의 대상이 될 누군가를 찾으라. 상부상조한느 관계가 될 수 있는 방법을 고려하라. 개발팀 전체를 포함시키는 것도 고려하라.
• 앞에서 설명했던 것과 같은 간단한 체계를 팀 내에 구축하는 것을 고려하라. 변경하거나 추가하거나 제거한 모든 코드를 두 명 이상이 확인하도록 하라.
• 어떻게 의무감을 구축할지에 대해 합의하라. 여기에는 작은 규모의 회의, 페어 프로그래밍, 코드 리뷰 등이 포함 된다.
• 어느 수준 이상의 작업에 전념하고 그에 대한 논쟁에 대비하라. 방어적으로 대응하지 말라.
• 팀 단위로 혹은 프로젝트 단위로만 적용하고 있다면 모두가 참여하도록 해보라. 개발 품질을 보장하기 위한 일련의 팀 표준안이나 그룹 단위의 코드 작성을 고려하라.

직접 해보라. 의무감을 가질 동료를 찾아보라. 작업이 특정 수준의 품질에 도달하도록 노력하라. 본인의 코드를 확인해달라고 동료에게 요청하라. 상호적인 관계가 되도록 해보라.

Chapter 36. 말하기!

코드는 의사소통이다

코드는 컴퓨터와의 의사소통이다. 명확하고 애매모호함이 없어야만 의도대로 명령이 수행될 것이다.

코드는 (자신을 포함한) 다른 사람들과의 의사소통이다. 명백하고 애매모호함이 없어야만 다른 사람들이 코드를 유지보수할 수 있다.

더 많은 주석을 단다고 반드시 코드가 더 나아지지는 않는다. 의사소통에 충실한 코드는 추가적인 주석이 필요없다.

코드는 작성이 아닌 읽기에 최적화되어야 한다. 작성자가 작성하기 더 쉽게 하기보다는, 간결한 구조를 사용하여 다른 사람이 이해하기 더 쉽도록 해야한다.

좋은 프로그래머를 특징짓는 기술은 좋은 의사소통이다. 효과적인 의사소통은 다음과 같은 특징을 지닌다.

• 명확하게
• 자주
• 존중하면서
• 적절한 수준에서
• 적절한 매체를 통한 소통

Chapter 37. 선언문

• 코드에 신경 쓰라.
• 팀의 힘을 키우라.
• 간결함을 유지하라.
• 머리를 쓰라.
• 그 무엇도 고정된 것은 없다.
• 꾸준히 배우라.
• (주체가 자신이든, 팀이든, 코드든 간에) 나아질 방향을 꾸준히 모색하라.
• 언제나 가치를 전달하려 애쓰라. 길게 볼 수 있도록 해보라.

Chapter 39. 태도가 핵심이다

태도

좋은 프로그래머와 나쁜 프로그래머를 구분하는 요소는 바로 태도(attitude)다.
기술적으로 아무리 경쟁력 있는 프로그래머라해도, 건전한 태도를 바탕으로 하지 않는다면 좋은 결과물을 기대하기 어렵다.

시작하라. 코드를 작성하라

좋은 코드에 주의를 기울이고 더 나은 방법을 찾으라. 언제나 배우라. 설계 방법을 배우고, 코드를 작성하는 법을 배우고, 같이 일하는 방법을 배우라.
프로그래밍을 즐기라. 무엇보다 더 나아짐을 즐기라!