<훌륭한 프로그래머 되는 법> 요약

CHAPTER 4. 코드 줄여 개선하기

• 간단하고, 불필요한 것이 없으며, 끝이라고 확실하게 답할 수 있는 것을 아름답다고 여긴다.
• 특정 종류의 버그에 지독하게 당해본 뒤에 예전의 코드로 되돌아가면, 해당 코드에 숨어 있는 잠재적인 버그를 자연스럽게 발견하게 된다.
• 그것은 프로그래머의 육감이다.

 

CHAPTER 6. 경로 탐색하기

• 새로운 코드 베이스에 적응을 위해서는 다음과 같은 작업들을 재빠르게 해내야 한다.
  • 코드의 어느 부분부터 보아야 하는지 파악하기
  • 코드의 부분별 기능을 알아내고, 그 기능을 어떻게 수행하는지 살펴보기
  • 코드의 품질을 가늠하기
  • 시스템 내부를 어떻게 탐색할 것인지 계획하기
  • 코딩 관례를 이해하고, 본인의 수정 사항이 그것과 어울리도록 만들기
  • 특정 기능이 있을 법한 위치를 파악하고, 그 기능에 의해 발생하는 버그 찾아보기
  • 코드와 함께 그것의 중요한 부속 부분들인 테스트 코드 및 문서 등의 관계를 이해하기
  • 하나의 팀에서 영원히 하나의 코드베이스만 다루다가 고인 물이 되지 말아야 한다
• 하나의 팀에서 영원히 하나의 코드베이스만 다루다가 고인 물이 되지 말아야 한다

 

CHAPTER 10. 버그 사냥하기

• 버그를 찾았으면 해당 버그를 발생시키는 테스트케이스를 만든 후 수정한다.  훗날 다시 생겨날 버그를 예방하는데 도움을 줄 것이다

 

CHAPTER 11. 테스트하기

• 좋은 테스트 전략이란 피드백 절차를 간소화하는 것으로, 이를 통해 더 효율적으로 일할 수 있다
• 피드백 과정이 짧을수록 설계 변경을 더 빠르게 반복할 수 있고 코드에 대해 더 강하게 확신할 수 있다.
• 문제를 빨리 알수록 수정은 쉬워지고 비용은 낮아진다. 그 이유는 코드를 짜는 시점에 가까운 만큼 코드에 대해 더 명확하게 파악하고 있기 때문이다
• 빌드 과정에 테스트를 끼워 넣을 수 있도록 테스트를 작성하는 게 좋다
• 클래스의 행태를 변경한 탓에 테스트에 실패했다고 해서 테스트를 막아버리고 도망쳐서는 안된다. 테스트 코드도 유지 보수하라

 

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

• 잘된 프로그램: 새로운 코드를 적절한 위치에 지정하는 작업은 개인적 취향에 맞게 더 편리한 장소에 적당히 집어넣는 일보다도 더 어려졌다. 즉 구조적 설계 계획으로 인해 개발자들은 더 열심히 일해야 했다. 하지만 시스템을 유지 보수하거나 확장하는 데 어려움이 없었기에 이후의 삶은 더 나아졌다
• 시스템 구조는 내비게이션 역할을 하는 지도를 제공했다
• YAGNI(Don’t do anything if You Aren’t Going to Need It): 필요하지 않다면 아무것도 하지 말라. 이에 따라 설계 초기에 중요한 부분만 처리하고자 했고 나머지 결정은 뒤로 미뤄놓았다. 여기서 ‘뒤’란 실제 요구사항과 시스템에 어떻게 끼워넣을지에 대한 더 명확한 그림을 그릴 수 있는 시점을 가리킨다. 결정을 적절히 미루는 것은 설계에 대한 대단히 강력한 접근이었으며 상당히 자유로운 것이었다
• 발생할 수 있는 가장 나쁜 상황 중 하나는 아직 모르는 것을 설계하는 경우다
• 일정이 마무리되었을 무렵에는 시간에 맞춰 출시하기 위해 많은 부분을 적당히 마감했다. 코드 작성 과정에서 자그마한 실수나 기괴한 설계가 허용되었다. 기능의 신속한 작동을 가져오는 동시에 배포 직전의 위험한 변경을 피하기 위함이었다
• 다만, 지저분한 대도시 프로젝트와는 달리, 임시방편 처리를 기술 부채로 표시해두었다가 이후 버전에서 수정하도록 했다
• 단계별로 설계가 개선되었고, 결국 안정적인 (설계) 정체기에 이르게 되었다

 

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

• 문제에 질서 있고 신중하게 접근하는가? 아니면 구조화되지 않은 방식으로 돌진하는가?
• 지저분한 코드에 대해 책임감을 가지고 청소를 하는가
• 세 가지의 규칙
• 간결하게 하라
• 머리를 쓰라
• 변하지 않는 것은 없다

 

CHAPTER 16. 간결하게 하기

• 생각없이 접근하다 보니 간결한 코드를 넘어 지나치게 단순한 코드라는 결말에 이른다. 지나치게 단순한 코드란 곧 올바르지 않은 코드다
• 간결한 설계에 관한 확실한 징후가 하나 있다. 빠르고 명확하게 묘사할 수 있고, 쉽게 이해할 수 있다는 점이다. 간결한 문장 혹은 하나의 명확한 설계도로 요약할 수 있다
• 간결한 설계란 사용이 간편한 것을 가리킨다
• 간결한 설계는 오용하거나 악용하기 어렵다
• 간결함의 비결은 복잡한 부분을 적절한 곳에 위치시키는 것이다
• 간결한 설계의 확실한 징후는 많은 양의 코드를 고쳐 쓰지 않고도 개선하고 확장할 수 있다는 점이다
• 간결한 코드는 읽기 쉽고 이해하기 쉽다. 따라서 작업하기에도 쉽다
• 일관성이야말로 간결한 코드로 이끄는 주역이다. 일관성은 명확성으로 이어진다
• 어떤 이유로든 쓸데없이 애매한 코드를 작성하지 말라
• 오류를 발견했을 때, 코드를 재작성하여, 오류는 수정하면서도 간결함을 유지하는 것이다. API를 더 적절하게 조정할 수도 있고, 올바른 오류 수정을 위해 몇 가지 논리를 리팩토링할 수도 있다. 심지어 코드에서 논리적으로 합당하지 않은 가정을 발견하여 심각한 재작업을 할 수도 있다
• 증상 부위가 아닌 근본 원인에 대해 버그 수정을 적용하라. 반창고를 덧붙이면서 겉으로 드러나는 증상만 고치는 것은 간결한 코드로 이끌어주지 않는다

 

CHAPTER 17. 머리 쓰기

• 우리 모두는 때때로 실수를 한다. 그 누구의 코드도 언제나 완벽할 수는 없는 만큼 스스로 자책할 필요는 없다. 멍청한 코드를 작성했다는 사실을 깨닫거나 바보 같은 설계임을 인식했더라도, 무력함을 느끼거나 자신을 실패 덩어리로 여기지는 말라
• 일단 실수했음을 인정하고 코드로 되돌아가 더 나은 방향을 찾아보라. 실패를 인정하고 실수를 바로잡을 용기를 가지라. 바보 같은 코드로 인해 절뚝거리는 것보다 훨씬 용기 있는 행동이다
• 실수를 인정하고 코딩에 있어서의 잘못된 결정을 인정하라. 그로부터 배우라
• 일을 멈추고 생각하라. 바보 같은 코드를 작성하지 말라

 

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

• 본래의 개발자가 프로젝트를 떠나고 오래된 중요한 코드를 완벽하게 이해하는 사람이 남지 않았을 때, 해당 코드가 사후 경직되는 경우가 종종 있다
• 소프트웨어를 깨뜨리는 것이 두려울 수 있다. 어떻게 오류에 대한 두려움 속에서도 용기 있게 수정할 수 있을까?
• 좋은 수정을 가하는 방법을 배우라. 작업의 안정성을 높이고 오류의 가능성을 줄일 수 있는 실천 방법이 존재한다. 용기는 수정이 안전하다는 확신에서 나온다
• 매일 코드를 개선하여 더욱 수정이 용이한 상태로 만들라. 코드의 품질에 대해서는 타협을 거부하라
• 시도하는 것은 부끄러운 일이 아니며 실수로부터 항상 배울 수 있다. 다만 그 어떠한 수정에 대해서도 출시 이전에 충분한 테스트와 검증을 거쳤음을 보장하라
• “내가 작성한 게 아냐. 쓰레기 같아. 이걸로는 그 어떤 것도 하고 싶지 않아. 이 코드를 가능한 한 적게 파헤칠거야”와 같은 태도를 취해서는 안 된다.
• 오래 묵은 코드는 정체되고, 새로운 방랑자가 그 주변을 더욱 더럽힌다
• 한번에 전체 코드베이스와 싸우려 하지 말라. 위협적이고, 고치기 어려운 일이 될 것이다. 그 대신 변경해야 하는 제한된 영역을 정한 뒤 그것을 손보는 데 집중하라

 

CHAPTER 19. 코드 재사용 사례

• 웹에서 찾은 코드를 프로젝트에 복사할 때는 주의 깊게 조사해야 한다. 얼마나 테스트해보았는가. 코드가 정말로 완벽하게 들어맞는가? 모든 에러를 적절하게 다루는가? 버그는 없는가?
• 다음 사용자에 맞추기 위해 가능한 가장 작은 범위로 API를 확장하라

 

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

• 개발자의 목표는 QA의 방어를 피해 배포하는 것이 아니다. 더 뛰어난 품질 구현과 적절한 버그 수정이 목표다. 소프트웨어에 내재한 나쁜 요소들을 발견할 시간이 없기를 바라서는 안 된다

 

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

• 경력상의 침체를 느낀다면, 이런 구덩이에서 벗어나기 위한 가장 현실적인 방법 중 하나는 바로 새로운 것을 배우려고 의식적으로 노력하는 것이다
• 사람들과 함께 일하는 것을 배우라. 사회학이나 경영학 책을 공부해보라. 소프트웨어 팀의 리더가 되는 것에 대해 읽어보라
• 어떻게 배워야 할지 배우라. 마인드 맵핑이나 빨리 읽기와 같은 새로운 기술들을 연습하라
• 완전히 다른 것을 배우라. 소프트웨어와 전혀 관련없는 것에 집중해보라. 이를 통해 세계관을 넓힐 수 있고 프로그래밍 방법을 배울 수 있다
• 메모를 하게 되면, 그 메모장을 그냥 버리게 되더라도 교차 감각적 자극이 사실을 기억하는 데 도움이 된다
• 스트레스와 수면 부족은 집중력을 저하시킬 것이며, 학습 능력을 하락시킬 것이다
• 배움의 가장 효과적인 방법 중 하나는 직접 가르쳐보는 것이다
• 남을 가르치다가 대답할 수 없는 질문에 부딪혔을 때는 이 같은 반응이 적절하다. “잘 모르겠지만, 당신을 위해 한번 찾아보도록 하겠다” 그러면 서로 배우게 되는 것이다

 

CHAPTER 25. 테스트 기반 개발자

• 아무런 생각 없이 ‘성급하게 반응하는’ 식의 접근 방법은 카우보이 코더에게나 찾아볼 수 있는 증상이다

 

CHAPTER 26. 도전 즐기기

• 개인적인 도전은 종종 곁다리 프로젝트를 통해서만 얻을 수 있다. 평범하기 짝이 없는 일상 업무에 더해 별도로 진행하는 프로젝트를 통해서만 자극을 얻을 수 있다
• 온종일 지루한 업무를 수행하느라 바쁜 와중에 오히려 그 안에 흥미로운 도전을 끼워넣어 균형을 맞추는 것이야말로 더 나은 프로그래머가 되기 위한 길이다

 

CHAPTER 27. 부진 피하기

• 동일한 도구만 사용하는 습관을 멈추라. 단지 배우는 것만으로도 삶이 더 편안해질 수 있는 더 좋은 도구들이 있을 것이다
• 프로젝트의 새로운 부분을 담당하라. 많이 알지 못하는 부분을 담당하라. 당장은 생산성이 떨어질 수 있으나, 코드에 대한 더 폭넓은 지식을 얻을 수 있고 새로운 것들을 배울 수 있다

 

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

• 적당히 석고를 붙이거나 땜질하는 식의 방법으로 버그를 수정하지 말라. 윤리적인 프로그래머들은 버그를 찾아내고 이해한 뒤, 적절하고 견고하며 검증된 방법으로 수정한다
• 윤리적인 프로그래머는 남을 모욕하거나 불쾌하게 하지 않으면서 가장 생산적인 토론 결과를 이끌어낼 방향을 모색한다
• 작업의 복잡성을 불필요하게 높게 측정한 뒤, 복잡한 문제를 푸는 척하면서 태만하게 일하거나 다른 더 재미있는 일을 하려 들지 말라

 

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

• 문제를 해결할 때 하나의 도구나 한 가지 방법에 지나치게 몰입하는 건 언제나 위험하다
• 모든 경우에 대한 유닛테스트를 작성하기 보다, 취약한 것으로 예상되는 지점들에 집중하라
• 여러 설계 방안 가운데 어떤 것을 선택해야 할지 결정할 수 없을 때는, 최선책을 골라내기 위해 심사숙고하느라 많은 시간을 소모하지 말라. 매우 간단한 프로그램을 만들어봄으로써 더 적절한 해답을 얻어낼 수 있다
• 코드와 설계를 가능한 한 작고 간결하게 유지하라. 그렇지 않으면 이후 유지 보수해야 하는 코드가 늘어날 뿐이다. 물론 나중에 고쳐야 할 수도 있다. 하지만 미래의 요구사항이 무엇일지 지금 정확히 예견할 수는 없다. 지금 당장은 나중에 코드를 고치기 쉽도록 하는 정도에서 만족하는 것이 더 쉽고 똑똑한 일이다
• 작고 명확한 코드가 더 큰 코드보다 훨씬 고치기 쉽다
• 문제를 미루고 쌓아두지 말라. 더 일찍 일을 시작하고 문제가 작을 때 그것에 직면하는 것이다. 1년에 걸쳐 만들어낸 커다란 기능 세 가지를 마지막에 하나로 합치기란 쉬운 일이 아니다
• 다른 사람들과 코드 설계에 관해 토론하라. 구조를 세우기 위한 더 나은 방법을 더 빨리 찾을 수 있다. 피할수만 있다면 나쁜 코드를 작성하는 일에 노력을 들이지 말라
• 작고 이해 가능한 범위에서 코드를 리뷰하라
• 모호하지 않고 확실히 이해하기 위해 적절한 질문을 하는 방법을 배우라

 

CHAPTER 32. 끝나야 끝나는 것

• 언제 일이 끝나는 지를 모르고 코딩하는 것은 체계적이지 않다는 말이다
• 엄청난 업무를 할당받았다면 일을 시작하기 전에 더 작고 이해할만한 부분으로 일을 나누도록 하라. 그래야 더 정확하게 진행 상황을 판단할 수 있다
• 완료 상태를 정의해야한다. 그만둘 때를 정의하지 않는다면 필요 이상으로 작업하게 될 것이다
• 자신감으로 충만한 나머지 도움을 요청하는 타이밍을 놓치는 일이 없도록 하라
• 문제에 직면했을 때, 이를 해결하기 위한 한 가지 이상의 접근법을 고려해야 한다. 그런 다음 작업에 착수해야 한다

 

CHAPTER 35. 생각이 중요하다

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

 

CHAPTER 36. 말하기!

• 코드를 작성하는 행위야말로 의사소통의 한 형태이다.
• 코드는 (자신을 포함한) 다른 사람들과의 의사소통이다. 명백하고 애매모호함이 없어야만 다른 사람들이 유지보수할 수 있다.
• 코드가 명확하지 않다면 변경하기도 어려울 것이다. 좋은 코드에는 읽기 어려운 부분이 없다. 지나치게 길거나 부자연스럽지도 않고, 주석으로 가득하지도 한다.
• 더 많은 주석은 더 나은 코드를 만들기보다 오히려 코드를 늘어지게 할 뿐이다.
• 개발자들은 같은 언어로 대화해야 한다. 애플리케이션 전체를 C++로 작성했다면, 다른 언어로 된 코드를 끼워넣는 것은 그에 합당한 이유가 필요하다.
• 코드는 작성되는 것보다 훨씬 더 자주 사람들에게 읽힌다는 점을 기억하라. 따라서 작성이 아닌 읽기에 최적화해야 한다. 키보드를 덜 두들겨도 되는 것을 선택해서는 안 된다.
• 팀원 간에 자주 대화하지 않고 계획이나 설계를 공유하지도 않는다면, 필연적으로 코드와 노력 복제로 이어질 수 밖에 없다. 코드베이스에서 서로 충돌하는 설계를 보게 될 것이고 통합하는 과정에서 실패를 맛보게 될 것이다.
• 일일 회의를 통해 진행 상황을 공유하고, 문제를 공론화하며, 비난 없이 문제가 되는 부분을 확인할 수 있다. 그 과정에서 프로젝트의 현재 상태에 대한 명확한 그림을 모두가 그릴 수 있다.
• 좋은 프로그래머를 특징짓는 기술은 좋은 의사소통이다. 다음과 같은 특징을 지닌다.
• 명확하게
• 자주
• 존중하면서
• 적절한 수준에서
• 적절한 매체를 통한 소통
• 개발자는 이들 요소를 염두에 둔 채 의사소통을 연습해야 한다. 그리고 지속적인 개선을 위해 노력해야 한다.

 

CHAPTER 37. 선언문

• 납득할만한 이론들을 지지하라. 하지만 맹목적으로 따르거나 독단적으로 다루지 말라. 그것이 유일한 진리는 절대 아니다.
• 새로운 관습과 유행하는 교리에 대해 배우라. 그들의 좋은 점은 감사하며 받아들이되 무턱대고 따르지는 말라. 열린 마음으로 그들을 평가하라.
• 필자의 선언문
• 코드에 신경 쓰라.
• 팀의 힘을 키우라.
• 간결함을 유지하라.
• 머리를 쓰라.
• 그 무엇도 고정된 것은 없다.
• 꾸준히 배우라.
• (주체가 자신이든, 팀이든, 코드든 간에) 나아질 방향을 꾸준히 모색하라.
• 언제나 가치를 전달하려 애쓰라. 길게 볼 수 있도록 해보라.

 

CHAPTER 38. 코드 찬가

• 만약 프로그래머가 업무를 이해하지 못한 것처럼 보이고 상황을 더 악화시키고 있음을 이해하지 못한다면, 그에 대해 반드시 반응해주어야 한다.
• 코드에 대해 책임감을 가질 수 있는 방법을 알려주고, 가장 효율적으로 일하는 방법을 알려주라.
• 이 때 비난처럼 느껴지지 않는 방법을 택하라. 페어 프로그래밍과 멘토링을 하고 설계 및 리뷰 회의를 하라.