<코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기> - 제프 앳우드

 

📖 책 소개

 

저자 제프 앳우드(Jeff Atwood)는 개발자라면 누구나 알만한 ‘스택 오버플로우’의 공동 창업자이다. 그가 본인의 블로그 ‘Coding Horror’에 올린 글을 선별해서 묶어낸 책이다.

 

여러 글을 모은 책이라 하나의 주제로 통일된 내용은 아니다. 대신 ‘쓸데없는 일을 줄이는 방법’, ‘웹 디자인 원칙’, ‘사용자를 이해하라’ 같은 주제별로 글이 정리되어 있어 가볍게 읽기 좋았다. 블로그 글답게 직설적인 표현도 많고, 딱딱하지 않은 문체 덕분에 부담 없이 읽을 수 있다.

 

최고의 프로그래밍 서적은 시간에 구애받지 않는다. 그러한 책은 언어, IDE, 혹은 플랫폼조차 뛰어넘으며, '어떻게'에 대해 말하지 않고 '왜'에 대해 이야기한다.
- 274p

 

출간된 지 10년이 넘은 책이지만, 시대에 뒤떨어질까 걱정할 필요는 없다. 저자가 언급한 내용처럼, 좋은 개발 서적은 시간에 구애받지 않는다는 것을 이 책이 보여준다. 책에 수록된 글들은 시간이 흘러도 변하지 않을 개발의 본질에 집중하고 있다. 개발자라면 누구나 읽어볼 만하다. 책에 소개된 저자의 추천 도서도 앞으로 읽어봐야겠다.

 

✍️ 인상적인 내용 정리

 

01. 쓸데없는 일을 줄이는 법

 

• 할일 (To-Do) 목록은 필요하지 않다.
  • 할 일이 모두 의무로 느껴지게 만들기 때문에 그 안에 담긴 기쁨이 사라진다.
  • 할일 목록은 도구다. 도구는 있다가도 없고, 없다가도 있는 것. 도구 대신 평생지기인 두뇌와 본능을 믿고, 그것들을 믿을 수 있도록 훈련해라.
• 구글의 20퍼센트 시간 정책
  • 회사에서 20퍼센트의 시간은 자유롭게 → 3M 베스트셀러(포스트잇 포함) 중 많은 것이 이런 시간에 탄생
  • 20퍼센트 시간 정책이 가능한 회사 : 스케줄 여유가 있고, ‘바빠 보이지 않는’ 직원과 실패가 허용되는 회사
• 다른 사람을 어떻게 설득하는지 배워야 한다.
• 실패한 프로젝트란 그 안에서 아무것도 배우지 못한 프로젝트다.
• 전문가는 이래라저래라 하는 사람이 아닌 질문을 던지는 사람
  • 전문가가 되는 것은 다른 사람에게 자기가 아는 것을 말하는 것이 아니다.
  • 어떤 질문을 할지 아는 것, 자신의 지식을 주어진 특정한 상황에서 어떻게 적용할지 아는 것
• 반복의 속도가 반복의 질보다 우선한다. → (단위 테스트, 애자일 방법론)

 

02. 프로그래밍

 

• 더 나은 프로그래머가 되는 유일한 길은 프로그래밍을 하지 않는 것
  • 이미 충분한 능력을 가진 기술을 아무 생각 없이 반사적으로 파고드는 경우가 많다.
  • 프로그래밍 주변에 있는 다른 일(사용자, 업계, 비즈니스…)에 관심을 가지기
• 깨진 유리창(나쁜 설계, 잘못된 결정, 엉터리 코드)을 방치하지 말기
• 프로그래밍: 사랑하지 않으면 떠나라
  • 누구나 프로그래머가 돼야 하는 건 아니다.
  • 최고의 프로그래머들은 모두 자신이 하는 일에 평생을 걸 열정을 품은 사람들
• 포스(FORTH) 언어의 교훈
  • 단순함 유지 : 기능이 많을수록 프로그램 복잡성은 기하급수적으로 증가
  • 추측 금지 : ‘나중에 사용될지 모른다’는 이유로 코드 추가 X
  • 찰스 무어 曰 : 단순함은 억지로라도 적용돼야 하는 필수적인 원칙
• 더 이상 필요하지 않은 코드 → 실행되지 않게 만드는 대신 완전히 삭제하기
• 컬리의 법칙 : 하나만 해라
  • 각각의 변수, 코드 한줄, 함수, 클래스, 프로젝트는 오직 하나의 일만 수행해야 한다
  • 컬리의 법칙은 당신의 코드가 무엇을 할지가 아니라 무엇을 하지 않을 것인가를 의식적으로 선택하는 과정
• 프로그래밍 외의 자신이 잘하는 일을 떠올리고, 그 분야 전문가가 어떤 훈련을 할지 생각해 보라. 그들의 방식에서 배운 점을 프로그래밍에 어떻게 적용할 수 있을지 고민해 보자.
• 코드의 품질을 측정하는 유일한 방법 : 거지 같아, 라는 말이 나오는 분당 횟수

 

03. 웹 디자인의 원칙

 

• 사람들은 웹사이트를 30초 이내에 판단한다.
• 훌륭한 첫 페이지를 만드는 요소
  • 빠른 페이지 로드
  • 간결하고 명확한 카피 문구
  • 서비스를 사용할 때 어떤 화면을 보게 될지 알려주는 스크린샷과 구체적인 예
  • 쉽게 결정을 내리게 만드는 (구체적이고 명확한) 버튼
• 언제나 단순함을 추구해야 한다. 그것을 위해 어떤 비용을 치르더라도
• 코딩에서는 언제나 영리함보다 일관성을 택하는 것이 낫다.
• 현재 참여 중인 프로젝트의 사용성에 관심을 두는 사람이 없다면 그 프로젝트의 운명은 이미 다한 것과 마찬가지다
• 자주 사용되지 않거나 위험한 동작을 수행하는 UI 항목은 반드시 클릭하기 어렵게 만들어야 한다.
• 웹사이트, 프로그램, 이메일, 이력서, 글쓰기에서 가장 중요한 정보를 맨 앞에 놓는 것은 중요하다.
• (i'm feeling lucky 같은) 불필요한 버튼을 없애라.
• 모든 사용자를 위한 모든 기능을 더하고, 더하는 대신 그냥 '아니오'라고 말하라. (그런 기능을 모두 더하는 것은 별로 아름답지 않다.)

 

04. 테스트

 

• 단위테스트 vs 베타 테스트
  • 단위 테스트의 장점 : 잠시 손을 멈추고 테스트에 대해 생각하게 만든다는 것
  • 진짜 테스트와 베타 테스트는 소프트웨어를 베타 테스터들에게 출시한 시점부터 이뤄질 수 있다. 단위 테스트 코드가 베타 테스트 스케줄을 방해한다면 아주 심각한 실수를 저지르는 것.
• 예외 주도 개발
  • 사용자들이 실제로 경험하게 되는 문제를 해결하는 데 시간을 할애하는 개발
  • 소프트웨어를 출시하고, 최대한 많은 사용자가 이용하게 만들고, 그들이 생성하는 오류 로그를 철저하게 분석해서 개선
• 문제는 코드 안에 얼마나 많은 버그가 있느냐가 아니다. 그런 버그를 얼마나 빠르게 수정할 수 있느냐다.

 

05. 당신의 사용자를 알라

 

• 개발자의 최고의 오만함 : 스스로를 전형적인 유형의 사용자라고 생각하는 것
• 프로젝트의 전체 생명주기에 걸쳐 개발자들이 최종 사용자를 수시로 만날 수 있게 해야 한다.
• 훔칠 수 있는 것을 손수 만들지 말라. 엄청나게 성공적인 웹 UI의 요소들을 훔치는 것은 망설일 필요가 없는 일이다.
• 사용자들은 결코 매뉴얼을 읽지 않으며, 언제나 곧바로 소프트웨어를 사용하기 시작한다.
• 묻지 않고 관찰 : 사용자에게 직접 필요한 것을 묻지 말고, 그들이 실제로 하는 행동을 관찰해야 한다.
• 소프트웨어를 ‘기능들의 총합, 끝없이 먹을 수 있는 디지털 뷔페’로 판단하지 말자.
  • 새 기능을 더한다고 해서 더 나은 소프트웨어가 만들어지는 경우는 거의 없었다.
  • 새 기능이 추가될 때마다 속도는 느려지고, 덩치가 커지고, 더 복잡해진다. → 소프트웨어가 서서히 파괴된다.
• 게임화(예: StackOverflow Profile), 즉 동료를 통한 자극은 정말로 효과가 있다.

 

08. 읽어볼 만한 내용

 

• 최고의 프로그래밍 서적은 시간에 구애받지 않는다. 그러한 책은 언어, IDE, 혹은 플랫폼조차 뛰어넘으며, '어떻게'에 대해 말하지 않고 '왜'에 대해 이야기한다.
• 이 책들을 아직 읽지 않았다면 지금 당장 읽어보기 바란다.
  • 코드 컴플리트 2
  • 상식이 통하는 웹사이트가 성공한다
  • 피플웨어
  • 실용주의 프로그래머
  • 소프트웨어 공학의 사실과 오해
• 다른 사람들이 쓴 자기계발서를 읽는 것은, 그것이 아무리 좋은 의도로 쓴 것이라고 해도 당장 해야 할 일을 직접 완료하는 것을 대신할 수 없다.