Pragmatic TIL - 8 (2022-04-06)

오늘 TIL 3줄 요약

 

• 프로그래머가 코딩하는 동안 더 적극적으로 행동하는 방법
• 여러분의 본능과 무의식적인 생각을 더 잘 활용해라
• 테스트를 수행함에 있어서 나타나는 긍정적인 효과

 

TIL (Today I Learned) 날짜

 

2022. 04. 06

 

오늘 읽은 범위

 

7장. 코딩하는 동안

 

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

 

 

여러분의 본능과 무의식적인 생각을 더 잘 활용해라

 

• 직감이 여러분의 역량에 일조하도록 하라.
• 여러분 내면의 파충류에게 귀 기울여라.
• 일단, 하고 있는 일을 멈춰라. 여러분의 뇌가 정리를 좀 할 수 있도록 약간의 시간과 공간을 확보해라. 코드에 대해 생각하지 말고 키보드에서 떨어져서 잠깐 머리를 비운 채로 할 수 있는 일을 하라. 산책을 하고 점심을 먹고 다른 사람과 수다를 떨어라. 아예 하룻밤 자면서 생각을 해봐도 된다. 생각이 저절로 여러분의 뇌 층층이 스며들도록 놔둬라.
• 여러분이 이런 방법들을 시도해 보았는데도 여전히 막혀 있을 수도 있다. 여러분의 뇌에게 여러분이 하려는 일은 별 문제가 없다고 알려줘야 한다. 바로 프로토타이핑을 하면 된다.
• 프로토 타이핑하는 방법
  
  1. 포스트잇에 "프로토타이핑 중"이라고 써서 모니터 옆에 붙여라.
  2. 프로토타이핑은 원래 실패한다고 자신에게 상기시켜라. 실패하지 않더라도 프로토타입은 버리는 것이라는 점도 함께 상기시켜야 한다. 프로토 타이핑으로 손해 볼 일은 없다.
  3. 텅 빈 에디터 화면에 여러분이 배우고 싶은 것 혹은 하고 싶은 것을 한 문장의 주석으로 표현해 보라.
  4. 코딩을 시작하라.
  
  의심이 들기 시작하면 포스트잇을 보라
• 직감에 귀 기울이는 방법은 계속 갈고닦아야 할 중요한 기술이다. 가끔은 설계가 왠지 이상하게 느껴질 수 있고, 어떤 요구 사항이 마음을 불편하게 할 수도 있다. 하던 일을 멈추고 그 느낌을 분석하라.

 

프로그래머가 코딩하는 동안 더 적극적으로 행동하는 방법

 

• 우리는 우연에 맡기는 프로그래밍, 곧 행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다. 대신 '의도적으로 프로그래밍해야 한다.'
• 다른 사람이 호출할 코드를 작성하고 있다면 모듈화를 잘하는 것, 그리고 잘 문서화한 적은 수의 인터페이스 아래에 구현을 숨기는 것 같은 기본 원칙들이 모두 도움이 된다.
• 잘 되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르다.
• 우연에 맡기는 프로그래밍을 하지 말라.
• 우리는 코드를 마구 찍어 내는 데에 드는 시간을 줄이고 싶고, 또 가능한 한 개발 주기 초기에 오류를 잡아서 고치고 싶고, 애초부터 오류를 더 적게 만들고 싶어 한다. 그러려면 의도적으로 프로그래밍해야 한다.
• 필요한 변경을 하지 않을 경우의 비용보다 일정이 늦어져서 발생하는 비용이 적어야 한다는 것을 염두에 두어라.
• 앞으로는 어떤 것이 잘 돌아가는 듯이 보이기는 하는데 여러분이 그 이유를 모를 경우, 그것이 우연은 아닌지 반드시 확인하라.

 

성능 문제가 발생하기 전 미리 잠재적인 문제점을 찾아내는 방법

 

 

• 사용하는 알고리즘의 차수를 추정하라.
• O(n2) 알고리즘이 있다면 분할 정복을 사용하여 O(n log n)으로 줄일 수 없는지 시도해 보라.
• 코드의 실행 시간이 얼마나 될지 또는 메모리를 얼마나 사용할지 확실하지 않다면 직접 실행해 보라.
• 성급한 최적화를 조심하라. 언제나 어떤 알고리즘을 개선하느라 여러분의 귀중한 시간을 투자하기 전에 그 알고리즘이 정말로 병목인지 먼저 확인하는 것이 좋다.

프로젝트를 진행하면서도 끊임없이 기존 코드를 개선할 수 있는 방법

 

• 코드는 정적인 존재가 아니다. 코드는 발전해야 한다.
• 코드 고쳐쓰기, 다시 작업하기, 다시 아키텍처 만들기는 모두 아울러서 '재구성(리팩터링)'이라고 부른다.
  
  이 정의에서 핵심적인 부분은 다음 두 가지다.
  
  1. 이 활동은 체계적이다. 아무렇게나 하는 것이 아니다.
  2. 밖으로 드러나는 동작은 바뀌지 않는다. 기능을 추가하는 작업이 아니다.
  
  정리하자면 정확한 목적을 가지고 정밀하게 접근하는 활동이다. 그래서 코드를 바꾸기 쉽게 유지하는 것이다.
• 리팩터링은 언제 하는가? 여러분이 작년이나 어제, 심지어 10분 전과 비교해서 더 많이 알게 되었다면, 리팩터링을 한다. 주저하지 말고 변경하라. 언제나 바로 지금이 최적기다. 리팩터링을 할 이유는 아주 많다.
  
  언제 해야 할까?
  
  중복 - DRY 원칙 위반을 발견했다.
  
  직교적이지 않은 설계 - 더 직교적으로 바꿀 수 있는 무언가를 발견했다.
  
  더 이상 유효하지 않은 지식 등이 있겠다.
• 일찍 리팩터링 하고, 자주 리팩터링 하라.
• 코드 한 부분 때문에 '리팩터링만 하는 일주일'이 필요해서는 안 된다. 그건 완전 재작성이다. 만약 이 정도로 시간이 많이 필요하다면 즉시 해치울 수 없는 것도 당연하다. 그 대신 일정에 리팩터링 할 시간을 확실히 포함시켜 두도록 하라. 그 코드를 사용하는 사람들이 코드가 조만간 재작성될 것이라는 사실과 재작성이 그들의 코드에 미칠 영향을 인지하도록 해야 한다.
• 리팩터링은 천천히, 신중하게, 조심스럽게 진행해야 하는 작업이다.
  
  1. 리팩터링과 기능 추가를 동시에 하지 말라.
  2. 리팩터링을 시작하기 전 든든한 테스트가 있는지 먼저 확인하라.
  3. 단계를 작게 나누어서 신중하게 작업하라.

 

테스트를 수행함에 있어서 나타나는 긍정적인 효과

 

• 테스트는 버그를 찾기 위한 것이 아니다. 우리는 테스트의 주요한 이득이 테스트를 실행할 때가 아니라 테스트에 대해 생각하고, 테스트를 작성할 때 생긴다고 믿는다.
• 테스트가 코드의 첫 번째 사용자다. 이것이 테스트가 주는 가장 큰 이득일지 모른다. 테스트는 우리의 코딩을 인도하는 필수 피드백이다.
• 테스트 주도 개발(test driven development, TDD)의 기본 주기는 다음과 같다.
  
  1. 추가하고 싶은 작은 기능 하나를 결정한다.
  2. 그 기능이 구현되었을 때 통과하게 될 테스트를 하나 작성한다.
  3. 테스트를 실행한다. 다른 테스트는 통과하고 방금 추가한 테스트 딱 하나만 실패해야 한다.
  4. 실패하는 테스트를 통과시킬 수 있는 최소한의 코드만 작성한다.
  5. 코드를 리팩터링 한다.
• 어떻게는 TDD를 실천하라. 하지만 도중에 이따금 멈추어 큰 그림을 살피는 것을 잊지 말라.
• 소프트웨어 단위 테스트란 어떤 모듈에게 이것저것을 시켜보는 코드를 가리킨다. 일반적으로 단위 테스는 일종의 인위적인 환경을 구축한 다음, 테스트할 모듈의 루틴들을 호출한다.
• 우리는 단위 테스트를 계약을 잘 지키는지 보는 테스트라고 여긴다.
• 테스트할 수 있도록 설계하라.
• 여러분의 소프트웨어를 테스트하라. 그러지 않으면 사용자가 테스트하게 된다.
• 테스트, 설계, 코딩, 이 모든 것이 프로그래밍이다.

 

버그가 일어났을 때 어떻게 대처해야 하는지

 

• 코드에 존재하는 계약과 불변식을 뭉뚱그려서 '속성'이라고 부른다. 코드에서 속성을 찾아내서 테스트 자동화에 사용할 수 있는데, 이것을 '속성 기반 테스트'라 한다.
• 속성 기반 테스트로 가정을 검증하라.
• 우리는 속성 기반 테스트가 단위 테스트를 보완한다고 믿는다. 둘은 서로 다른 문제를 해결하고 각각의 장점이 있다.

 

읽고 분석하기 쉬운 코드를 쓰는 방법 , 보안에 관하여

 

• 코드 복잡성은 공격 매개채를 유발한다.
• 입력 데이터는 공격 매개체다.
• 단순함을 유지하고 공격 표면을 최소화하라.
• 최소환의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여하라는 게 또 다른 핵심 원칙이다.
• 보안 패치를 신속히 적용하라.
• 특별한 조합 규칙을 도입하지 말라. 예를 들어 대문자와 소문자 , 숫자와 특수문자를 반드시 섞어서 써야 한다거나 반복되는 문자는 쓰면 안 된다거나 하는 식으로 강제하지 말라. (조합을 강제하는 경우 사람들은 맨 끝에 특수문자를 붙이는 등("1!@") 예측이 쉬운 형태로 비밀번호를 만들거나, 아니면 외우기 힘든 복잡한 비밀번호를 만든 후 종이 등에 적어서 보관함으로써 오히려 보안에 취약해지는 경우가 더 많다고 한다.

 

우리는 많은 것들의 이름을 지어야 하는데 코딩하는 동안 이름의 의미가 변하지 않는지 감시해야 한다.

 

• 이름을 명확하게 짓는 작업이 여러분의 코드를 작성할 때 코드를 더 잘 이해할 수 있도록 도울 것이다.
• 잘못된 이름을 바꿔라. 이름을 바꾸기 쉽게 만들고, 자주 이름을 바꿔라.

 

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

 

• 7장의 분량이 되게 많았는데 그 이유는 책의 제목처럼 실용주의 프로그래머가 되는 방법을 많이 소개했기 때문인 것 같습니다. 각 파트별로 배운 점이 많았고 코드를 작성할 때나 문제 해결을 할 때 책에서 소개해준 방법을 사용해보고자 합니다.

 

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

 

• 속성 기반 테스트가 아직 테스트가 익숙하지 않다 보니 어려웠습니다.

 

오늘 읽은 다른 사람의 TIL

 

• sss003366님의 TIL (url 링크)