TIL 7장. 코딩하는 동안

책이 개정판이 아니라 차례가 좀 다른 것 같습니다.
스케줄을 맞추기 위해 지난 6장(코딩하는 동안 해야 할 일들)의 내용을 다시 올립니다.

오늘 TIL 3줄 요약

• 우연에 맡기지 말고 의도적으로 프로그래밍 하라.

• 성능을 측정하고, 코드를 리팩토링하고, 테스트 하라.

• 자신이 이해하지 못하는, 마법사가 만들어 준 코드는 사용하지 말라.

TIL (Today I Learned) 날짜

2022.03.30

오늘 읽은 범위

6장. 코딩하는 동안 해야 할 일들

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

• 다른 사람들이 호출할 코드를 작성할 때는 모듈화를 잘하거나 문서화가 잘된 작은 규모의 인터페이스 아래에 구현을 숨기는 것과 같은 기본 원칙들이 모두 도움이 된다.(p.276)

• 확실한 것이 아닌데도 의존하고 있는 다른 것들은 어떤 것이 있을까?(p.276)

• 가정하지 말라. 증명하라.(p.276)

• 의도적으로 프로그래밍 하기(p.277)

  • 완전하게 이해하지 못한 애플리케이션을 빌드하려 하거나 익숙하지 않은 기술을 사용하려고 시도하는 행동은 하지 말라

  • 계획을 세우고 그것을 바탕으로 진행하라.

  • 신뢰할 수 있는 것에만 기대라

  • 여러분의 가정을 문서로 남겨라

  • 노력을 기울일 대상의 우선순위를 정하라.

  • 과거의 노예가 되지 말라.

• 소프트웨어는 건축보다 오히려 정원일에 더 가깝다. 딱딱하기보다는 유기적인 존재다.(p.291)

• 리팩터링은 언제해야하는가?(p.292)

  • 중복 발견

  • 직교성이 좋지 않은 설계

  • 유효기간이 끝난 지식

  • 성능

• 일찍 리팩터링하고, 자주 리팩터링하라.(p.294)

• 리팩터링해야 할 것들의 명단을 만들고 유지하라.(p.294)

• 마틴 파울러 리팩토링 조언(p.296)

  • 리팩터링과 새로운 기능 추가를 동시에 하지 말라.

  • 리팩터링을 시작하기 전 든든한 테스트 집합이 있는지 먼저 확인한다.

  • 단계를 작게 나누어 신중하게 작업한다.

• 모듈을 설계할 때는, 심지어 루틴 하나를 설계할 때도, 그것이 지켜야 할 계약과 계약을 지키는지 테스트하는 코드도 함께 설계해야 한다.(p.304)

• 어떤 방식을 쓰든 간에 찾기 편한 위치가 아니면 쓰지 않게 될 것이라는 점을 기억하라.(p.305)

  • 여러분 모듈의 모든 기능을 어떻게 이용해야 하는지 보여주는 예제

  • 후일코드 변경시 검증하기 위한 회귀 테스트를 구축할 수 있는 수단

• 테스트 윈도우를 만들기(p.311)

  • 추적 메시지를 담아 두는 로그 파일을 만든다.

  • 단축키를 제공한다.

  • 웹서버를 내장시킨다.

• 테스트는 기술적이라기보다는 문화적인 것이다.(p.311)

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

• 지금껏 나는 우연에 맡기는 코드를 짜고 있지는 않았나? 테스트가 준비되지 않은 코드는 사실상 우연에 맡긴 코드라고 할 수 있는 것 같다.

• 테스트는 기술적이라기 보다는 문화적이라는 말이 가장 인상이 깊었다. ’테스트에 대해 더 이해하면 써야지’라고만 생각하고 지금까지 미뤄왔었다. 이 행동이 생각보다 위험한 생각이었다. 문화적으로 자리 잡지 않으면 아마도 내년에도 같은 생각을 하지 않을까

오늘 읽은 다른사람의 TIL

• https://jiyoungyim100.notion.site/TIL-2022-04-01-02-7-ba22d042133c45a88cd53727c0206366