- 하지만 컴퓨터라는 독자만을 염두에 두고 코드를 작성하다가는 머지않아 큰 문제에 부딪히게 됩니다. 2차 독자인 사람을 염두에 두지 않았기 때문입니다.

- 자바에서 예외를 처리할 때 사용되는 throw와 catch라는 키워드 역시 일종의 은유입니다. 사실 이 은유는 다른 언어와는 다른 자바의 예외 처리 방식을 효과적으로 나타내기 위한 목적이 있습니다.

- 관심사를 분리하여 코드를 작성하면 각각의 코드 영역에서 적은 수의 관심사에만 집중할 수 있기 때문에 코드를 파악하는 것이 훨씬 수월합니다.

- 코드가 강하게 결합되어 있다면 유지 보수 비용이 크게 드는 경향이 있습니다. 일반적으로 ‘의존성 주입 (Dependency Injection)’ 등의 기법을 통해 결합도를 낮출 수 있습니다.

- 이 과정에서 인상적이었던 부분은 깃랩의 사고 수습 및 복구 과정이 상당히 투명하게 공개되었다는 것입니다. 그들은 복구 진행 프로세 스 전반을 트위터 계정을 통해 실시간으로 알렸습니다.

- 이제부터는 바야흐로 탐정이 될 시간입니다. 디버깅은 수수께끼를 푸는 것과 비슷합니다. 복잡한 수수께끼를 풀기 위해 관찰력, 지식, 직관, 추론 능력으로 중무장하고 끈기와 인내로 문제를 해결해 나가는 셜록 홈즈가 되어야 합니다.

- 버그 재현과 로그를 통해 디버깅을 수행할 때 그 과정을 꼼꼼히 기록하는 것도 큰 도움이 됩니다. 복잡하거나 난해한 버그의 경우 이를 추적하는 데 며칠에서 길게는 몇 달까지 걸릴 수 있습니다. 이 기간 동안 획득한 단서나 실험 결과를 머릿속에만 유지하기보다는 일종의 디버깅 문서를 만들어 기록하는 것이 좋습니다.

- 패턴에는 이름도 중요합니다. 만약, ‘문’이라는 이름이 없었다면 건축 사무소에 온 손님에게 도면을 설명하기 위해 여기에 문을 달겠습니다 대신 여기에 경첩이 달린 직사각형 형태의 나무를 대고 손잡이를 달아서 여닫을 수 있는 물체를 달겠습니다라고 설명해야 할 것입니다.

- 그제서야 각 개발자는 각자의 사본을 가지고 직접 브랜치를 생성하고 커밋을 만들어 나갈 수 있었습니다. 이를 통해 정말 훌륭한 기능을 추가하거나 심각한 버그를 고칠 수 있게 되었습니다.

- 혼자 가면 빨리 갈 수 있지만 함께 가면 멀리 간다라는 말이 있습니다. 본문에서 언급한 리누스 토발즈도 사실은 리눅스와 깃을 오롯이 혼자 만들지는 않았습니다. 수많은 오픈소스 기여자들과 함께 수십 년 간 훌륭한 소프트웨어를 만들어 오고 있습니다.

- 자바의 생태계에서도 이러한 문제를 인식하고 자바의 장황함을 줄이고자 노력하고 있습니다. 예를 들어, 자바 8에서 ‘람다 표현식’을 도입함에 따라 새로운 스레드를 생성하기 위한 코드가 아래와 같이 간결해졌습니다.

- 재미있는 점은 위의 코드 대신 for (i = 0; i 〈=9; i++)로 써도 동작은 동일하게 돌아가지만 이렇게는 잘 쓰지 않는다는 점입니다. 사람들은 이미 전자의 패턴에 익숙해져 있는 상태에서 0~9가 아닌 0~8까지 도는 반복문이라고 잘못 인식할 가능성이 있기 때문입니다.

- 이와 같이 Go의 특징을 통해 설계 철학을 엿보다 보면 Go의 목적이 가장 뛰어난 프로그래밍 언어를 만들기 위한 연구의 성격이 아닌 동료의 작업 환경을 개선하고 생산성을 향상시키기 위한 시도였다는 것을 알 수 있습니다. 대학을 갓 졸업하고 구글에 입사한 주니어 개발자들도 새로운 언어를 쉽게 익혀 안전한 코드를 작성할 수 있도록 말입니다.

- 개발자들이 자주 하는 변명에 대해 순위를 매겨본다면 아마 다음의 말이 1위를 차지하지 않을까 싶습니다. 제 컴퓨터에선 잘 되는데요?

- json 같은 텍스트 형태의 데이터는 저장할 때 파일 전체를 처음부터 끝까지 다시 기록해야 합니다. 수천 명의 회원 목록 중 단 한 명의 데이터만 변경되었다고 하더라도 수천 명의 회원 목록 전부 다시 기록해야 한다는 이야기입니다