[실용주의 프로그래머] 관성적으로 코딩하고 있다면, 이 책을 들춰보세요

실용주의 프로그래머를 완독 했습니다!

완독 !== 완벽 이해 지만, 사수 없는 SI에서 개발 중인 저에게 '어떻게 개발해야 하는가'를 생각하게 해주는 책이었습니다. 

최근 관성적으로 개발하고 계신다면, 사수가 없는 곳에서 일하고 있다면, 이 책을 추천합니다. 

 

핵심은 이겁니다.

실용주의 프로그래머들은 책임을 회피하지 않는다.

 

1차 후기는 여기서 ! 참고로 저는 구판을 읽어서, 신판과 구성이 조금 다릅니다. 

https://dev-dev-dev-dev.tistory.com/33

[실용주의 프로그래머] 개발 은하수를 여행하는 히치하이커를 위한 안내서

 

 

👍인상 깊었던 점 + 요약 + 함께 나눈 이야기

5장, 6장 스터디 날에는 주말출근 때문에 불참해, 함께 나눈 이야기가 없습니다. ㅠㅠ

 

5️⃣장 : 구부러지거나, 부러지거나

• 사실 5장은 내용이 어려워서 완전히 읽지 못했어요. 코드의 결합도를 낮추는 방식, 한정된 개발 시간을 효율적으로 나누는 법 등을 기술했는데 무슨 소린지 잘 모르겠습니다! 잘못된 정보 확산을 막기 위해 주니어에게 적용 가능한 핵심 내용만 남겨둘게요.
  
  
• 삶이 멈추지 않듯, 프로그램도 (사용을 다하지 않는 한) 멈추지 않으므로 유연하게 코드를 작성하도록 노력해야 합니다. 유연함을 유지하는 가장 좋은 방법 ➡적은 양의 코드를 쓴다! 😮😮 많은 양의 코드는 그만큼 많은 양의 버그를 만들어낼 수 있습니다. 또한 코드를 수정하면 또 다른 버그가 나타날 수도 있는 거죠.
  

6️⃣장 : 코딩하는 동안 해야 할 일들 

• 주니어들에게 귀감이 될 만한 내용이 많습니다! 사수한테 혼나는 느낌으로 읽었습니다. ಥ_ಥ 찔리는 부분도 많고, 제가 개선해야 할 점도 많이 보였습니다. 코딩할 때 필요한 자세를 상세하게 알려주는 챕터였습니다. 권고사항이 많아서 뭔가 요약도 명령조로 하게 됩니다. ㅋㅋ 
  
  
• 네가 무슨 코드를 쓰고 있는지 제발 알고 써! 
   ➡ 코드를 조금 작성합니다. 잘 돌아갑니다. 더 씁니다. 다시 테스트합니다. 잘 되네요! 코드를 더 추가합니다. 어! 갑자기 안 됩니다. 왜 안 되지? 어디서부터 잘못된 거지? (그렇게 n시간 동안 디버깅한다...) 
  아주 흔한 일입니다. 작가는 말합니다. 문제가 발생했을 때, 당신이 그 원인을 모르는 이유는 '처음부터 왜 코드가 잘 돌아가는지도 몰랐기 때문'입니다. 네가 뭘 하는지 알고 작업해! 
  
  
• 알고리즘을 개선하기 전, 이 알고리즘이 병목인지 먼저 생각해보세요. 가장 빠른 알고리즘이 늘 좋은 알고리즘인 건 아닙니다.

자신의 코드에 심취한 개발자

• 리팩토링을 자주 하세요. 
   ➡그런데... 지금 잘 작동하는데 괜히 건드렸다가 일을 만들 필요가 있을까나? 라는 생각이 듭니다. 작가의 답 : YES!!!!! 그렇다고 하네요. 강력하게 yes라고 합니다. 솔직히 눈물이 납니다. 갑자기 스쳐 지나가는 API가 있습니다. 돌아는 가는데 로직이 좀... 똥입니다. 돌아가게는 만들어놨는데, 다른 사람이 읽었을 때 이게 뭐야.. 싶을 거 같아서 찔립니다. 솔직히 어제도 그 코드를 다시 봤습니다. 잘 돌아가는데... 돌아는.. 가는데 ^^.. 고치겠습니다. (숙연) 
  
  
• why : 리팩토링, 왜 해야 하는가? 
   ➡ 제대로 돌아가는 것처럼 보이지만, 우리한테만 그렇게 보이는 거일 수도?
   ➡ 현재 조건이 우연히 맞아떨어져서 잘 돌아가는 것일 수도. 다른 상황(EX. 화면 해상도가 다를 때)에서는 안 될 수도?
   ➡ 불필요한 추가 호출이 있을 수도? 불필요한 추가 호출로 새로운 버그 발생할 수도? 
   ➡ 특히 다른 사람들이 호출할 코드를 작성할 때는 모듈화를 잘 해야 합니다. 또, API 명세화를 통해 API를 사용하는 사람들이 입출력 데이터, 호출방식 등을 명확하게 알도록 해야 합니다.
  
  
• when : 리팩토링은 언제 해야 하는가?
  ➡ 코드가 잘못된 결과를 불러일으켰을 때
  ➡ 하나로 합쳐야 할 코드 2개를 발견했을 때
  ➡ 현실을 피하지 마세요. 일정 때문에 리팩토링을 못 한다 하겠지만 못된 코드는 종양과 같습니다. 치료하지 않고 그냥 놔두면 문제가 커져 더 큰 불행으로 돌아옵니다. (라고 작가님이 말하네요.. 네 일겠습니다 ㅠㅠ 알겠다구요!)
  ➡ 일찍 리팩토링하고, 자주 리팩토링하세요!!!!
  
  
• how : 리팩토링은 어떻게 해야 하는가?
  ➡ 새 기능 추가할 때 리팩토링하지 마세요. 코드가 꼬일 수 있습니다. 
  ➡ 테스트 목록을 준비하세요. 
  ➡ 단계를 작게 잘라서, 한 단계가 끝날 때까지 디버깅하세요.
  
  
• 테스트하세요. 안 그러면 유저가 테스트하게 됩니다.
  ➡ 모듈을 설계할 때부터 테스트를 염두에 두고 하세요. 에러를 고치는 것보다, 에러를 나지 않게 설계하는 것이 더 중요합니다. 
  ➡ 단위 테스트를 작성하세요. 그리고 찾기 쉬운 곳에 두세요!
  ➡ 테스트는 로그 남기거나, 예상 결괏값에 비추어 출력을 분석하거나 등으로 진행할 수 있습니다.
  ➡ 테스트는 기술적이라기보다는 문화적인 것!

 

7️⃣장 : 프로젝트 전에 

• 방법론을 비판적으로 바라보기
  ➡왜 MSA를 쓰는가.. MSA는 정말 좋은 것인가... 함수형 프로그래밍은 정말 좋은 것인가... TDD는 정말 좋은 것인가... 계속 생각해서 가장 좋은 방법을 도입하세요.
  
  
• 기획을 받자마자 구현하지 마세요.
  ➡ 문제 발생 매우 높음! 실제 사용자의 입장에서 기획이 뭐가 문제가 있는지 생각하고, 필요한 요청인지 스스로 판단해서 아닌 건 아니라고 얘기해야 한다고. 그래야 변경이 줄어든다고 합니다. 
  
  
• 고객도 고객의 마음을 몰라요.
  ➡ 요구사항이 고객의 머릿속에 있을 수도 있고, 아예 땅 속에 묻혀 있을 수도 있습니다. 그 요구사항을 파내는 일도 때때로 필요합니다. 엇, 이 기능이 필요하지 않을까요? 같은 거죠. 이처럼 의뢰인의 시선으로 바라보고, 요구사항의 여파를 깨우쳐줘야 한다네요. 그래서 의뢰인과 피드백을 주고받으면서 서비스를 만들어야 합니다. 저의 짧은 경험을 복기해 보니 맞는 말인 거 같아요. 왜냐하면 고객 말 그대로 다 하면, 또 다른 문제가 생깁니다. 개발자도 한번 다시 생각해보며 영향도를 분석하고 코딩하기. 
  
  
• 머리가 안 돌아갈 때 잠깐 딴짓하기!
  ➡ 유레카!가 찾아오길 기도합시다.
  

이 챕터를 읽고 함께 나눈 이야기 

• 이 책을 읽을 때 기획을 하고 있어서 공감 가는 부분이 많았다. 요구사항이 땅 위에 놓여있는 경우가 별로 없고, 요구사항이 아예 존재하지 않을 때도 있다. 마치 뭘 먹고 싶은지 스스로도 모르는 고객님의 입맛을 맞춰야 하는 요리사가 된 느낌. 또한 애자일이라 해도, 요구사항 문서가 있는 게 나은 거 같다. 요구사항을 비즈니스 레벨로 끌어내려야 한다.
• 짝 프로그래밍을 해보는 것도 좋다. 경험  규칙을 정해놓는 게 중요하다. 1시간은 네가 하고, 1시간은 내가 하고. 그리고 남과  프로그래밍하면 코딩 방법을 논의할 수 있어서 좋다. 누가 같이 보고 있으니 더 집중이 잘 됨.

8️⃣실용주의 프로젝트 

• 테스트를 피해 다니지 마세요
  ➡ 팩트폭력 : 프로그램의 약한 부분을 알고 계시더라도, 살살 피해 다니세요! 다른 사람이 님 버그를 발견하는 수치를 느끼고 싶다면...  여러분들은 프로젝트 구덩이에서 헤엄쳐 다니는 미끌미끌한 결함들을 잡아내야 합니다.
  
  
• 모든 테스트를 통과하기 전엔 코딩이 다 된 게 아닙니다. 개발 조금, 테스트 조금! 조금씩 개발하고 조금씩 테스트하세요! 실제 제품에 들어갈 모든 코드는 나오자마자 테스트해야 합니다!
  
  
• 테스트 목록
  ➡ 단위테스트 : 하나의 모듈을 테스트하는 코드. 이거 하나가 잘 돼야 다른 것도 잘 됨. 다 합친 후에 통합테스트 진행!➡ 통합테스트
  ➡ 유효성 평가 / 검증
  ➡ 자원 고갈, 에러, 복구 : 메모리/디스크공간/cpu대역폭/벽시계시간/디스크/네트워크/ 등 점검
  ➡ 성능테스트
  ➡ 사용편의성 테스트
  
  
• 버그는 한 번만 잡아라  
  ➡ 인간 테스터가 버그를 찾아내면, 그때가 인간 테스터가 그 버그를 찾는 마지막 순간이 돼야 합니다. 해당 버그를 확인할 수 있게 자동화 테스트 코드를 추가해야 합니다.
  
  
• 결국은 모두 글쓰기
  ➡내부 문서 : 소스코드, 주석, 설계, 테스트 문서
  ➡외부 문서 : 사용자 매뉴얼
  ➡주석: 단순한 헤더 주석(양식) , 자료형 선언, 데이터에 대한 주석, 클래스 및 메서드 별 간략한 주석, 함수 용도. 소스에 대한 책임자.

이 챕터를 읽고 나서 드는 생각 

• 요즘 하루 종일 남의 코드를 읽는데, 주석이 없는 코드를 읽을 때마다 더 많은 공수가 들어갑니다. 모든 코드에 주석이 있을 필요는 없지만, 함수 용도, 사용되는 곳, 주의해야 할 점 정도는 적어줬으면 좋겠습니다. ㅠㅠ 결국 개발은 협업이라는 사실을 다시 한번 깨닫네요. 개발자는..... 다른 사람을 생각할 줄 알아야 한다! 다른 사람이 겪을 어려움을 이해해야, 더 이해하기 쉬운 코드를 작성할 수 있고, 결국 더 나은 개발자가 될 수 있는 것 같습니다. 
• 저는 테스트 목록을 만들고 테스트를 하는데, 잘하고 있다는 생각이 듭니다. 다만 유효성 평가, 사용편의성 테스트를 좀 더 공부해야 할 거 같습니다.  한번 버그를 잡으면 같은 실수를 반복하지 않게 자동화 코드를 만들라는 게 인상적이었습니다. 테스트 자동화 코드도 한번 작성해보면 좋을 거 같다는 생각이 드네요.

💫총평💫

한 달에 걸쳐 실용주의 프로그래머를 완독했습니다. 스터디를 통해 읽으니 끝까지 책을 읽을 수 있어서 좋네요. ㅎㅎ 

이 책을 읽으며, 사수에게 케어받는 느낌이 들었습니다! 이렇게 하면 안돼요. 테스트하면서 코딩하세요. 고객이 요구했다고 그냥 코딩하지 마세요. 테스트하세요. 유저가 어떻게 치고 들어올지 생각하세요. 왜 리액트를 쓰나요? 주석을 쓰세요. 당신의 코드는 당신의 것만이 아닙니다! 라고 우다다다다다 조언을 해주는 느낌입니다.

 

그리고 테스트, 테스트, 테스트.... 테스트의 중요성을 뼈저리게 느낍니다. 요즘도 매일매일 테스트 업무를 하고 있거든요. ㅋㅋ 많은 공감이 갑니다. 

 

특히, 문제를 인지하고 있으면 회피하지 말고 내 코드에 책임을 지라는 부분이 정말 뼈를 때립니다. 솔직히 누구나 하나쯤은 있지 않나요. 외면하고 있는 망한 코드를.... 도망치지 말고, 회피하지 말고, 보수적으로 코딩해야겠다는 ... 그런 다짐을. 해보게 되는. 책이었습니다. 실천 하도록 노력해야죠..ㅎㅎ.... !!! 

실용주의 프로그래머들은 책임을 회피하지 않는다.

 

저는 이 책을 종종 꺼내볼 거 같습니다. 관성적으로 코딩하고 있을 때, 내가 이렇게 코딩을  하는 게 맞나 싶을 때, 방향성을 제시해줄 수 있는 좋은 책이라고 생각합니다. 실용주의 프로그래머 추천합니다!