[TIL] 실용주의 프로그래머 || 7장 코딩하는 동안

준리·2022년 5월 28일
0
post-thumbnail

오늘 TIL 3줄 요약

  • 본능에 귀를 기울이고 문제가 여러분 앞에 튀어나오기 전에 미리 대처하라.
  • 우리는 우연에 맡기는 프로그래밍, 곧 행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다. 대신 의도적으로 프로그래밍해야한다.
  • "테스트 먼저"가 대부분의 상황에서 최상의 선택일 것이다.

TIL (Today I Learned) 날짜

2022.05.28(토)

오늘 읽은 범위

7장. 코딩하는 동안

책에서 기억하고 싶은 내용을 써보세요.

  • 적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍을 하는 것이다. -p274
  • 운전을 안전하게 잘하는 사람은 언제나 자기 상황을 검토하고, 잠재적인 문제들을 점검하며, 예상하지 못한 일이 생길 때에도 잘 대처한다. 코딩도 똑같다. 대부분은 반복적인 일이지만 정신을 늘 기민하게 유지하면 재앙을 막을 수 있다. -p275
  • 어떤 작업을 앞두로 마음 속에 의심이 계속 남아 있거나 왠지 꺼림칙하다면, 여러분의 경험이 여러분에게 말을 거는 중일지도 모른다. 그 느낌을 따라라. 직감이 여러분의 역량에 일조하도록 하라.
  • 여러분 내면의 파충류에게 귀 기울여라.
    • 일단, 하고 있는 일을 멈춰라. 여러분의 뇌가 정리를 좀 할 수 있도록 약간의 시간과 공간을 확보하라. 코드에 대해 생각하지 말고 키보드에서 떨어져서 잠깐 머리를 비운 채로 할 수 있는 일을 하라. 산책을 하고 점심을 먹고 다른 사람과 수다를 떨어라. 아예 하룻밤 자면서 생각해 봐도 된다. 생각이 저절로 여러분의 뇌 층층이 스며들도록 놔둬라. 억지로 쑤셔넣을 수는 없다. 언젠가는 다시 생각이 의식의 영역으로 올라와서 '아하!'하는 순간이 찾아올 것이다.
  • 잘 작동하는데 괜히 건드려서 일을 만들 필요가 있을까? 우리가 보기에는 그래야할 이유가 몇 가지 있다.
  • 과거에 노예가 되지 말라. 기존 코드가 앞으로 짤 코드를 지배하도록 놓아 두지 말라.
  • 소프트웨어 개발은 건축보다 정원 가꾸기에 더 가깝다. 계획한 대로 잘 되지 않는 것들은 잡초 제거하듯 뽑아내거나 가지치기를 해야 한다.
  • 리팩터링의 정의
    1. 이 활동은 체계적이다. 아무렇게나 하는 것이 아니다.
    2. 밖으로 드러나는 동작은 바뀌지 않는다. 기능을 추가하는 작업이 아니다.
      정확한 목적을 가지고 정밀하게 접근하는 활동이다. 그래서 코드를 바꾸기 쉽게 유지하는 것이다.
  • 리팩터링의 이유
    • 중복
    • 직교적이지 않은 설계
    • 더이상 유효하지 않은 지식
    • 사용 사례
    • 성능
    • 테스트 통과
  • 리팩터링의 방법
    • 리팩터링과 기능 추가를 동시에 하지 말라.
    • 리팩터링을 시작하기 전 든든한 테스트가 있는지 먼저 확인하라. 할 수 있는 한 자주 테스트를 돌려 보라. 이렇게 하면 여러분이 바꾼 것 때문에 무언가 망가졌을 경우 그 사실을 재빨리 알 수 있다.
    • 단계를 작게 나누어서 신중하게 작업하라. 클래스의 필드 하나를 다른 클래스로 옮기기, 메서드 하나 쪼개기, 변수명 하나 바꾸기 같ㅇ느 작은 단위로 작업해야 한다. 리팩터링에서는 국지적인 변경들이 많이 모여서 커다란 규모의 변화를 낳는 일이 자주 발생한다. 단계를 작게 나누고, 한 단계가 끝날 때마다 테스트를 돌린다면 기나긴 디버깅 작업을 피할 수 있다.
  • 리팩터링이 필요한 코드를 일종의 '종양'이라고 하자. 종양을 제거하려면 수술이 필요하다. 지금 바로 수술해서 아직 종양이 작을 때 제거할 수 있다. 아니면 종양이 자라고 다른 곳으로 전이할 때까지 놓아둘 수도 있다. 하지만 그때가 되면 제거하는 데 드는 비용도 더 늘어날뿐더러 위험도 훨씬 커진다. 시간을 더 끌면 환자는 생명을 잃을지도 모른다.
  • 여러분이 작성하는 모든 소프트웨어는 언젠가는 테스트된다. 여러분이나 여러분의 팀이 테스트하지 않으면 결과적으로 사용자들이 테스트하게 된다.
  • 여러분에게 있는 선택지는 그리 많지 않다. "테스트 먼저", "코드와 테스트를 함께", "테스트하지 않음" 셋 중 하나다. "테스트 먼저"가 대부분의 상황에서 최상의 선택일 것이다.

오늘의 책 다시보기

어? 왜 되는거지? 프로젝트를 할 때 가장 많이 나왔던 말이었던 것 같다. 나는 우연에 힘을 빌려 코딩을 했다. 이제는 증명해야 할 때다.

profile
트렌디 풀스택 개발자

0개의 댓글