[실용주의 프로그래머] 개발 은하수를 여행하는 히치하이커를 위한 안내서
🎖읽게 된 이유
최근 이런 고민이 있었습니다. '구현에만 초점을 맞추고 일하는 것 같다. 더 나은 코드에 대한 고민이 부족하다. 개발자로서 이게 맞나?' 그런 차에, 트친이 '실용주의 프로그래머' 독서 스터디를 제안했습니다. 워낙 유명한 책이고, 지금 고민하는 문제의 답을 구할 수 있을까 싶어 함께 읽기 시작했습니다.
📗이 책을 읽는 법
솔직히 쉬운 책은 아니었습니다.
문장도 쉽지 않고, 한자 + 영어 + 개발용어 콜라보레이션이 머릿속을 어지럽힙니다. 거기다 예시 코드도 해석해야 합니다.
이해가 잘 가지 않는 챕터도 꽤 있습니다. 그저 책을 덮어버리고 라면이나 먹으러 가고 싶어집니다.
그럴 때는 그냥 넘기고 다음 챕터를 읽는 것을 추천합니다.
나중에 또 보면 이해될 수도 있잖아요.
그리고 모든 문장 하나하나를 다 이해할 필요는 없다고 생각합니다.
결국 저자가 말하고자 하는 핵심 내용만 이해하면 됩니다.
챕터마다 저자가 강조하고자 하는 내용을 한 줄 요약하는 것도 좋은 방법이었습니다.
📖독서스터디를 진행한 방법
책을 읽어온 뒤, 각 챕터에서 가장 인상깊었던 부분과 함께 이야기나누고 싶은 점을 공유합니다.
👍인상깊었던 점 + 요약 + 함께 나눈 이야기
1️⃣장 :실용주의 철학
- 자신의 실수를 회피하지 마라. 상관에게 보고할 때는 대안도 함께 제시하라.
- 깨진 창문을 내버려두지 마라.
➡ 귀찮다고 나쁜 코드를 방치하면, 더 큰 재앙으로 돌아온다는 이야기였습니다. 단순히 코드가 나빠진다는 그런 문제가 아닙니다. 태도 나쁜 직원 한 명이 구린 코드를 작성하고, 팀이 그것을 계속 방치하면, 다른 직원들도 '저래도 되나 보다'라고 생각하고, 결국 모두가 구린 코드를 쓰는 문화가 형성된다는 이야기였습니다. 모골이 송연해졌습니다. 나는 그런 적이 없었나... 되돌아보았습니다.(사실 있었습니다...) - 개발 공부도 주식 포트폴리오처럼
➡ 저도 주식을 하는 사람으로서... 참신한 비유로 다가왔습니다. 계란을 한 바구니에 담지 말라는 주식 격언처럼 하나에만 매몰되지 않고 지식을 여러 곳에 분산하는 것이 좋다네요. 한 기술에만 매몰되면 도태될 수 있으니까. 또한 꾸준히 포트폴리오를 점검해야 하는 것도 주식과 비슷합니다. 내가 사용하는 언어나 생태계가 망할 수도 있으니까요 껄껄. 특히 React는 언젠가 사라질 수도 있다고 생각합니다. 프론트엔드는 너무 빨리 바뀌니까요. 아직 알려지지 않은 신기술을 미리 공부하는 걸 성장주에 빗댄 점도 흥미로웠습니다.
이 챕터를 읽고 나눈 이야기
- 실수는 빠르게 인정하고 보고하는 게 맞다. 대신에 어떤 현상이 일어났는지, 원인은 무엇으로 추정되는지, 무엇을 했는데 안 됐는지까지 생각하고 보고해야 한다.
- 깨진 창문을 내버려두면 안 되는 것도 맞는데, 너무 완벽함을 추구하는 태도는 오히려 효율성을 해칠 수 있다. 적당히 만들어서 피드백을 받고 고쳐나가는 게 맞는 방법인 것 같다.
- 깨진 창문을 발견했을 때 적극적으로 보고하는 게 좋다. 이런 적극적인 태도는 좋은 평가를 받는다.
2️⃣장 : 실용주의 접근법
- 직교성을 추구하자
➡모듈 간 서로의 영향력을 낮춰야 한다는 것. 모듈 A를 고치는데, 모듈 B, C, D까지 고친다고 생각하면 끔찍합니다. 이 책은 이렇게 제안합니다. '독립적이며 단일하고 잘 정의된 목적을 가진 컴포넌트로 구성하라.' 직교성이 높으면 재사용성 높아지고, 변화가 국소화돼 개발/테스트 시간이 줄어듭니다. 잘못된 코드가 있으면 걔만 고치면 됩니다. 전체적인 시스템이 잘 깨지지 않게 됩니다. - 가역성을 고려하자
➡ 말은 어려운데, 상황이 계속 바뀐다는 것을 의미합니다. MySQL에서 Oracle로 바꿀 수도 있고, 서버를 파이썬에서 고로 바꿀 수도 있고. 결정은 영원하지 않고 기획은 계속 바뀌니 유연하게 설계해야 한다네요. - 예광탄을 만들어보자
➡ 모든 기능을 기획한 뒤에 개발에 착수하지 말고, 할 수 있는 기능부터 빠르게 만들어보고 테스트하면서 살을 붙여나가자는 이야기.
3️⃣장 : 기본적인 도구
- 에디터를 하나 마스터하자. 자기가 마음에 드는 걸로!
➡에디터를 하나 마스터하면, 원하는 기능을 빠르게 실행할 수 있으니까요. 저는 이클립스와 VSCode를 쓰는데요, 이클립스 사용 초창기 discard를 못해서 20분을 헤맨 적이 있었습니다... - 디버깅을 하는 자세
➡버그 발생 시 “어 그럴리가 없는데” 라는 생각에 시간을 낭비하지 말고, 버그를 잡는 데 써야 한다네요. 표면에 보이는 증상만 고치려는 욕구에 저항하기! 또다른 문제와 연관돼 있을 가능성이 높으니, 문제의 근본적 원인을 발견하려 노력해야 합니다. - 버그 발생을 막는 법
➡사용자의 모든 사용법을 생각하기. 사용자는 기상천외하게 사용하니까, 여러 방식을 생각하고, 테스터와 많은 대화를 나눌 필요성이 있습니다. - 디버깅 전략
➡ 여러 방식이 있었지만 '고무오리'가 인상적이었습니다. ㅋㅋ 고무오리를 하나 두고 하나하나 설명하면서 따라가 보면, 언젠가는 답을 찾을수도요. 늘 그랬듯이... 때때로 제가 팀원에게 고무오리가 되는 것도 좋은 것 같습니다. 내가 고무오리일 경우, 별말 없이 고개를 그저 끄덕이는 게 중요한 거 같습니다. 여기서 괜히 말 얹으면 시간만 더 지나가요... ㅠㅠ 상호 성장 방법으로 강추하는 고무오리!
이 챕터를 읽고 나눈 이야기
- 가장 무서운 건, 에러메시지가 없는 버그다.
- 쿼리를 디버깅할 때는, WHERE, JOIN, SELECT를 하나씩 지워가면서 원인을 찾는다.
- INPUT과 OUTPUT이 제대로 나오는지 보는 게 보통 첫 번째 하는 일.
4️⃣장 : 실용주의 편집증 / 한 마디 요약 : 방어적으로 프로그래밍하라
- DBC(Designed By Contract)
➡읽으면서 훔냐 뭔소리지~ 했는데 스터디원분이 한 마디로 정리해주셨습니다. "회사가 정한 정책(요구사항)에 기반해서 개발하란 얘기예요." 그리고 뒤에 붙은 섬뜩한 또 다른 문장.
"물론 정책이 바뀔 수도 있지만...." - 단정적 프로그래밍을 역이용하기
➡ 이런 일은 절대로 일어날 리 없어 → 일어납니다. 2000년이 올거라 생각하지 못하고 프로그래밍한 결과 1999년에 난리가 났었다죠... ~한 일은 일어나지 않을거야, 라고 생각하면, 그걸 확인하는 코드를 추가해야 합니다. 단정이 실패할 경우 예외를 생성하는 등의 처리를 해줘야 하죠. 이런 검사 코드가 어플리케이션에 과부하를 줄 수도 있다고 여겨지지만, 세상에는 어떤 일이 일어날지 모르므로 방어적으로 최대한 작성할 필요가 있다고 합니다.
➡ 이 책은 있을 리 없다고 여겨지지만 일어난 일들의 예시를 보여주는데, '한 달이 28일보다 적은 것', '60초가 아닌 1분', '내각의 합이 180도가 아닌 삼각형'... 등이라고 합니다.. 그냥 아찔합니다. - 언제 예외를 사용할까?
➡ 스스로에게 질문 : 모든 예외 처리기를 제거해도 이 코드가 정상적으로 실행될까? 답이 ‘No’라면 예외처리를 다시 점검해야 한다네요. (에러 처리기 : 에러가 감지됐을 때 호출되는 루틴)
생각나는 대사 : 있을 수 없는 일이라는 건 있을 수 없어(ありえないなんてことはありえない)
이 챕터를 읽고 나눈 이야기
- 통상적으로 어떻게 예외처리 하는가? API 통신할 때 기본적으로 해주기 / HTTP 코드에 따른 예외처리 / DB 조회 결과가 없을 때 / 권한 없을 때 처리
- 공통 예외처리를 하는 컴포넌트를 만드는 것도 좋은 방법
- 악성 유저 때문에 HTTP 상태 코드를 클라이언트에 노출하지 않는 곳도 있음!
- 완벽한 예외 처리는 없으므로, 예외 상황이 나타날 때마다 충실하게 처리를 해주는 것이 중요.
- 홍콩에서는 전화번호를 - 로 구분하지 않고 스페이스로 구분한다고. 글로벌한 문화차이로 예외가 발생하는 경우도 있겠다.. 개발자는 사회를 잘 알아야 하는구먼!
👩🏫1차 총평
- 개발에 처음 입문한 사람도, 개발을 오래 한 사람도 읽으면 좋을 것 같습니다. 어떤 언어를 쓰든, 프론트든 백이든, 공통적으로 적용할 수 있는 이야기가 많더라구요.
- 특히 '개발문화', '더 나은 코드', '효율적인 프로그래밍' 등에 고민이 있는 사람이라면 추천. 어떤 자세로, 어떤 방식으로 개발하면 좋은지 한 가이드라인을 제시하고 있습니다.
- 앞에서도 말했듯이 쉬운 책은 아니었습니다! 정독하려고 애쓰지 말고, 핵심을 파악하는 방식으로 읽어나가는 게 좋을 거 같습니다.
- 사수가 있다고 해서 개발의 모든 걸 깨우칠 수 있는 건 아닙니다만, 사수가 없어서 고통받는 주니어분들에게 길라잡이가 될 수 있는 책이라고 생각합니다. 개발 은하수를 여행하는 히치하이커를 위한 안내서!
❤뽀나스 - 독서 스터디를 해서 좋은 점❤
1) 다른 회사 사람들은 어떻게 일하는지 들을 수 있습니다.
2) 우리는 만나서 책을 읽는데, 책을 읽어와야 한다는 부담 없이 할 수 있어서 좋습니다!
3) 혼자 읽는 것보다 같이 읽으니까 더 재밌어요.
4) 좋은 분들을 만날 수 있어요!
독서 스터디 강추!