TIL (Today I Learned) 날짜

2022. 05. 28

오늘 읽은 범위

7장. 코딩하는 동안

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

- 우리는 우연에 맡기는 프로그래밍, 곧 행운과 어쩌다 오는 성공에 의존하는 프로그래밍을 하지 말아야 한다.

- 가정하지 말라. 증명하라.

- Tip> 우연에 맡기는 프로그래밍을 하지 말라.

- 의도적으로 프로그래밍하기: 언제나 자기가 지금 무엇을 하고 있는지 알아야 한다. / 맹목적으로 코딩하지 말라. / 계획을 세우고 그것을 바탕으로 진행하라. / 신뢰할 수 있는 것에만 기대라. / 여러분의 가정을 문서로 남겨라. / 코드만 테스트할 것이 아니라 여러분이 세운 가정도 테스트해 보아야 한다. / 노력을 기울일 대상의 우선순위를 정하라. / 과거의 노예가 되지 말라.

- Tip> 여러분 알고리즘의 차수를 추정하라.

- 코드의 실행시간이 얼마나 될지 또는 메모리를 얼마나 사용할지 확실하지 않다면, 입력 레코드의 수나 혹은 런타임에 영향을 줄 것 이라고 생각되는 어떤 요소든 바꾸어 가면서 직접 실행해보라. 그런 다음 결과를 그래프로 그려본다. 얼마 후면 그래프 선이 어떤 모양인지 감을 잡을 수 있을 것이다. 위로 솟아올라가는 커브인가, 직선인가, 아니면 입력의 규모가 커질수록 기울기가 작아지는가? 점을 세 번이나 네 번 정도만 찍어 보면 대략적인 답이 나올 것이다.

- Tip> 여러분의 추정을 테스트하라.

- 프로그램이 발전해가면, 초기에 내린 결정을 다시 고려하고 코드의 일부분을 다시 작성하는 일이 점점 더 필요해진다. 이것은 지극히 자연스러운 과정이다. 코드는 발전해야 한다. 코드는 정적인 존재가 아니다.

- 코드를 다시 작성하기, 다시 작업하기, 다시 설계하기는 총괄해서 '리팩터링(refactoring)' 이라고 알려져 있다.

- 리팩터링은 언제 해야 하는가? 중복 / 직교성이 좋지 않은 설계 / 유효기간이 끝난 지식 / 성능

- 코드가 더 이상 잘 맞지 않아서 장애물에 부딪혔을 때, 사실은 하나로 합쳐져 있어야 할 두 개를 발견했을 때, 어떤 것이든 '잘못' 되었다고 생각될 때, 그것을 변경하는 일을 주저하면 안 된다. 언제나 바로 지금이 최적기다. 어떤 것이라도 코드를 리팩터링해야 할 이유가 될 수 있다.

- Tip> 일찍 리팩터링하고 자주 리팩터링하라.

- 리팩터링해야 할 것들의 명단을 만들고 유지하라.

- 리팩터링의 본질은 재설계다.

- 분명히 리팩터링은 천천히, 신중하게, 조심스럽게 진행해야 하는 작업이다.

- 리팩터링과 새로운 기능 추가를 동시에 하지 말라. / 리팩터링을 시작하기 전 든든한 테스트 집합이 있는지 먼저 확인한다. / 단계를 작게 나누어서 신중하게 작업한다.

- 소프트웨어 단위 테스트란 어떤 모듈에게 이것저것을 시켜보는 코드를 가리킨다.

- 계약을 잘 지키는지 테스트 하는 것을 강조함으로써, 우리는 프로젝트 후반부에 벌어질 수 있는 이런 종류의 재앙들을 피하기 위한 노력을 할 수 있다.

- Tip> 테스트를 염두에 두고 설계하라.

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

- Tip> 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다.

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

- 누구도 자신이 완전히 이해하지 못하는 코드를 내놓아서는 안 된다.

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

- 이번 챕터를 읽으면서 느낀 점은, 과연 나는 지금껏 코딩을 하면서 무엇을 했을까? 이다.

- 그저 일정에 쫓겨 테스트를 등한시 하고, 화면만 결과만 나오면 빌드 후 배포하지 않았을까?

- 그리고 그저 완성했다는 만족과 함께, 끝내지 않았을까 한다.

- 이번 챕터를 완벽히 이해하지는 못했지만, 유저에게 테스트를 전과하지 않는 최소한 내가 짠 소스는 내가 테스트를 마무리 하자는 마인드를 가져야 겠다.